0
public final class Book {

    private final String title;
    private final List<Author> listofAuthors;

    public Book(String title, List<Author> listofAuthors)
    {
        this.title = title;
        this. listofAuthors = listofAuthors;
    }

    public JComponent display() {
        JPanel bookPanel = new JPanel();
        bookPanel.add(new JLabel(title));
        JList authorsList = new JList(); // Or similar
        for (Author author: authors) {
            authorsList.add(author.display());
        }
        bookPanel.add(authorsList);
        return bookPanel;
    }
}

Author class:

public final class Author 
{
  private final String firstname;
  private final String lastname;

  public Author(String firstname, String lastname)
  {
    this.firstname = firstname;
    this.lastname = lastname;
  }
    //other methods
 }

Question:

  1. I'm following up on this post where I asked how to display data in a GUI without getters. My problem is, if I wanted to change an attribute, for example, remove an author from the list and display the change, how would I do it?

  2. To know which author was selected from the JList I need to know what index the user selected. How would I get that if the JList is buried in the display method?

  3. If I had a button, and used it to trigger an event after making a selection in the JList, where would that go?

Community
  • 1
  • 1
  • The question I have is "why" do not want to use "getters", without them, you can't inspect the properties of the object without exposing as `public`, which would break encapsulation. A "setter" won't break encapsulation, getters and setters are part of how encapsulation is managed – MadProgrammer May 01 '17 at 22:14
  • *"To know which author was selected from the JList I need to know what index the user selected"* - Oddly enough, `JList` provides a getter for this - [`JList#getSelectedIndex`](https://docs.oracle.com/javase/8/docs/api/javax/swing/JList.html#getSelectedIndex--). *"How would I get that if the JList is buried in the display method?"* - You could provide a proxy method in your class which returns the value from the `JList` – MadProgrammer May 01 '17 at 22:15
  • @MadProgrammer - I have no problem using getters and setters, however, I've been reading several different forums and threads about encapsulation, they all over different theories about what's best. I'm just trying to understand how developers who don't use getters/setter work –  May 01 '17 at 22:18
  • I think you're getting a little confused. In this case, `Author` can't add or remove itself from anything, that's not it's responsibility. In this case, the class is nothing more than a container of information - it doesn't have any real functionality. The `List` which holds all the `Author`s has functionality which can add, remove and find a `Author`. You could create your own or just us a `List` of some kind, that's up to you. In this case, `Author` needs to provide getters to allow other aspects of the API to operate – MadProgrammer May 01 '17 at 22:18
  • @MadProgrammer - I'm aware that JList has getselectedindex, but, does that mean I have to have the event handler in the Book class? What happens if I have a button that triggers an event after an author was selected from the list, does that go in there too? –  May 01 '17 at 22:20
  • It's not that they "don't" use them, they are trying to reduce the "over" use of them in case where it doesn't make sense. Some developers might suggest using `toString` to generate formatted output, for example, personally, I think that's wrong, you should have a "formatter" class which takes a `Author` and generates different formats based on your needs - you'll be surprised to find that an `Author` doesn't always want to be represented the same way. In this case, the formatter doesn't need to have any "getters" per say, it just returns a `String` representation of the supplied object – MadProgrammer May 01 '17 at 22:21
  • Then I would suggest that `Book` is trying to do too much work. What happens if you want to display `Book` on a web page or use JavaFX? You'd need individual classes for each of these scenarios. In this case, I'd suggest looking towards model-view-controller, where the model (`Book`) is separated from the way it is displayed (view) and the way it's managed/interacted with (controller) – MadProgrammer May 01 '17 at 22:23
  • I'm also sorry to say, I don't agree with Robert's answer in this context. It's not to say that an object isn't a container of data and functionality, it is, but you should also provide a destination at what responsibility the object really has. I don't agree with the fact that an object should be deciding how it should be displayed, because that doesn't take into account the countless numbers of ways it can be displayed and greatly couples your code to a specific implementation – MadProgrammer May 01 '17 at 22:26
  • @MadProgrammer - If I wanted to keep this class for a GUI(desktop app) that I'm building, in your opinion, getters would be ideal in my book class, correct? This way I can call the getter for author, loop and display them, correct? –  May 01 '17 at 22:27
  • To my mind, yes - your "display" code gains the flexibility to make the decisions about "how" the object is to be displayed - your `Book` class would then (as required) provide mutable methods to add and remove `Author`s (if that's what you want to do), so it's the "views" responsibility to facilitate the "how" (select object, button action, key action), but it's the `Book`'s (model) responsibility to physical manage it. The `Book` shouldn't care "how" you got to the point of asking it to add/remove an `Author` only that it can do so when requested – MadProgrammer May 01 '17 at 22:30
  • I've come from a long background of working with APIs which are required to be presented at different layers, consoles, web, guis, mobile devices and I can tell you, objects which know only how to manage themselves are reusable, yes, you may need to put some boilerplate in to support observer patterns and things to allow notifications when things change, but it's far simpler then having to write every possible scenario of how the object "might" be displayed in to the object itself. I don't think there's any right or wrong answer, except what's going to make it easier for you to develop – MadProgrammer May 01 '17 at 22:44
  • I'd also do some research into "code to interface not implementation" which may also support the "getters are evil" ;) camp – MadProgrammer May 01 '17 at 22:45
  • First, getters and setters are part of how encapsulation works. So they won't break encapsulation. Always be specific and make your best effort before asking, and don't treat Stack Overflow as a repository of tutorials. Stack Overflow is a question and answer site, not a code-writing service. Please [see here](https://stackoverflow.com/help/how-to-ask) to learn how to write effective questions. – Teocci May 01 '17 at 23:59
  • @Teocci - I did make my best effort before asking, problem is I get a various answers, none of which are definite. For example, both you and MadProgrammer state setter/getters are part of encapsulation, I can show you an entire thread of people stating the opposite. –  May 02 '17 at 00:05
  • @Teocci - This is the reason I'm confused as MadProgrammer pointed out, who am I supposed to believe in this case? All of this brings up more questions not suitable for comments. It's perhaps best to try and when I encounter a problem then ask. –  May 02 '17 at 00:12
  • @Nexusfactor You don't need an entire thread to solve this. First buy a book or download some from internet about the specific language. (In this case, JAVA) In another language probably a setter or getter may be considered as a "encapsulation breaker" so it's ok if other people say that. Also, read this [Wikipedia article about encapsulation](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)) if that is not clear for you, [then try with this](http://stackoverflow.com/a/19044735/5372008) – Teocci May 02 '17 at 00:13
  • @Teocci - They're saying it about Java, this is my problem. I see a thread saying it's okay, and another saying it isn't. –  May 02 '17 at 00:21
  • @Teocci - Many thanks :) –  May 02 '17 at 00:29
  • @Nexusfactor, I send you two links. After reading then, you can get into a conclusion. Look an engineer or a tech can define anything and base on that start to work. For example your company says only classes that implement interfaces can have setter and getter to not break the encapsulation, they probably mean to a business encapsulation. So don't worry just try to have the basic concept. Then you can get your own conclusions. Good luck. – Teocci May 02 '17 at 00:35
  • Obviously I think both links (the Wikipedia and SO) article given by @Teocci are misguided. I agree that most people interpret encapsulation that way, that doesn't mean that is the only or even the correct one. The original question came from the article from Alen Holub, who is obviously not a fan of the "usual" interpretation. – Robert Bräutigam May 02 '17 at 08:05
  • @RobertBräutigam Define *misguided*, you didn't read what I wrote? I didn't said that this is the only or even the correct way to understand. Also you contradict yourself. Saying that the article was written by a person who is not a fan of the "usual" interpretation. If you want to create or use another interpretation is because you now the "usual" interpretation very well (pros, cons, good, bad, ugly, optimizations, and so on) Then based on that understanding you can develop new interpretations. So try to be more accurate when you comment. – Teocci May 02 '17 at 08:15

0 Answers0