• Post Reply Bookmark Topic Watch Topic
  • New Topic

Using Getters in Java  RSS feed

 
Hank Emery
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I was reading this article on why getter and setters are evil. The article doesn't say not to use them ever, but, it's telling you to think in a way that limits the use of those methods, or to quote the article:

Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.


I understand that. However, what happens when you need to display data in a GUI, but don't have getter methods? The article covers this briefly, but not fully (It only mentions the problem, but only shows how NOT to solve it).

Take for example, you have a Book class(making this example limited to keep it readable).



If I have a GUI that has a JTextField to display the book title and a JTable to display the list of authors, how would I write my method to "do the work" for me and display the result? Is this one of those times where a getter is necessary?
 
Hank Emery
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I should note this is not a homework question. I understand that I'm supposed to try when I have homework and when I encounter a problem then ask, but don't have the forum do the homework for me. I get it, but this questions comes from the psat two days of using this forum, I get the idea that having getters should be avoided.
 
Paul Clapham
Sheriff
Posts: 22823
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This reminds me of back in the last century when I was learning about object-oriented design. I read advice which went something like "An object should know how to display itself". So since my objects were being used in a web app I wrote a toHTML() method for them. And then I designed another page which only needed a subset of the data -- the customer name, but not the address. So I wrote a nameToHTML() method. And then I designed another page which needed a different subset of the data -- the customer name and just the city. So I said to myself "This is stupid". I went back and tore out all of those methods which allowed the object to "display itself" and replaced them by code which got data from the customer and displayed it in whatever way was necessary.

Flash forward to the 21st century where we have the MVC (model-view-controller) design pattern. The model stores the data. The view displays data and interacts with the user. The controller mediates between the model and the view. So you'd expect the controller to have code which gets data from the model and displays it in the view, and code which gets data from the view and updates the model.

Now in a Swing application it isn't easy to recognize the controller. The view is easy, that's all of the GUI components. And the model is easy if you designed your application right and you have separate classes which store the data. But the controller? It's little bits of code all over the place. For example if you're listening to an action event, the code which the event triggers is part of the controller.

Anyway that's my roundabout way of saying "Yes you can haz getters". Does that help?
 
Hank Emery
Ranch Hand
Posts: 47
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Paul Clapham wrote:This reminds me of back in the last century when I was learning about object-oriented design. I read advice which went something like "An object should know how to display itself". So since my objects were being used in a web app I wrote a toHTML() method for them. And then I designed another page which only needed a subset of the data -- the customer name, but not the address. So I wrote a nameToHTML() method. And then I designed another page which needed a different subset of the data -- the customer name and just the city. So I said to myself "This is stupid". I went back and tore out all of those methods which allowed the object to "display itself" and replaced them by code which got data from the customer and displayed it in whatever way was necessary.

Flash forward to the 21st century where we have the MVC (model-view-controller) design pattern. The model stores the data. The view displays data and interacts with the user. The controller mediates between the model and the view. So you'd expect the controller to have code which gets data from the model and displays it in the view, and code which gets data from the view and updates the model.

Now in a Swing application it isn't easy to recognize the controller. The view is easy, that's all of the GUI components. And the model is easy if you designed your application right and you have separate classes which store the data. But the controller? It's little bits of code all over the place. For example if you're listening to an action event, the code which the event triggers is part of the controller.

Anyway that's my roundabout way of saying "Yes you can haz getters". Does that help?


Yes it does!

If you're interested I also asked the same question of SO, and one of the answers showed how to display the book without getter, I then asked how would I remove an author if I can't get the index(authors were displayed in a JList) the author is stored in. It was then suggested I make the object mutable. I'm sticking with getter as long as it makes sense to. I didn't want to make the Book mutable, I maked it immutable for a reason, I wanted to leave it that way.

 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!