Interesting.
Marty
Marty
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
get and set functions are evil ? 3
- Thread starter cappmgr
- Start date
-
1
- #2
Hmmm.
Without a way to input and output data from a class, it's all "doing" and no "on what?". So I'll have to disagree with his stand against getters/setters.
I mean, without them, the only way to get anything in or out of a class is via methods. And since Java doesn't have ref or out parameters, the only way to get something out of a class is via a method return value. One..per..method. Ouch.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
Without a way to input and output data from a class, it's all "doing" and no "on what?". So I'll have to disagree with his stand against getters/setters.
I mean, without them, the only way to get anything in or out of a class is via methods. And since Java doesn't have ref or out parameters, the only way to get something out of a class is via a method return value. One..per..method. Ouch.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
-
1
- #3
You can use the constructor to pass stuff in for initialization.
It truly is a bad way of doing things. Struts is a huge offender. When you want to add another field you have to change three different classes (forms, dto, update) and you should only have to change it in one place.
FOR MOST CASES: I create a model that is dynamic. if i need to adda new field i can go to a database table or xml file to do it. My objects use reflection and constructors to deal with the new data. Then I don't have to worry about discrete functionality that would normally and incorrectly be in getters/setters. It makes maintenance SO much easier.
It truly is a bad way of doing things. Struts is a huge offender. When you want to add another field you have to change three different classes (forms, dto, update) and you should only have to change it in one place.
FOR MOST CASES: I create a model that is dynamic. if i need to adda new field i can go to a database table or xml file to do it. My objects use reflection and constructors to deal with the new data. Then I don't have to worry about discrete functionality that would normally and incorrectly be in getters/setters. It makes maintenance SO much easier.
Well I think adding Get/Set methods for each private variable just for the hell of it is definitely a stupid thing. Although, I do think that you need to be able to change data in an object from time to time, so you need some way to get the data into the object. Some helper object also might need to read some of that data.
Sure, if you have a JUnit test that needs to inject data into the class, then create a package-scope getter/setter (or method!)cpjust said:
But I think the original article was arguing against ALL private members being exposed via getters/setters, and it's correct on that -- otherwise the class has no privacy in which to work.
So, taken to one extreme (all privates are public via get/sets) and the other (no private members are shared outside the class), the ideal situation lies somewhere in between. ;-)
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
-
1
- Thread starter
- #6
Sorry I should say those objects should actually be passed as thier interface types. That way you can change the internal implementation of the interface w/o having to change code that calls it.
The other object wouldn't unwrap it. It would ask the object to act on it via a method. Those methods are defined in the interface or class so you're guaranteed to have them work.
As for accessing data, there's nothing wrong with having an accessor here and there - but what typically happens is that become 50-60% of the code (maintaining accessors for all the Value Objects, etc..) When I first started writing java I had MASSIVE classes that had 40-50 private variables and i had a get/set on each one. It was hell! Breaking those out into seperate classes didn't help either. I would still have a large amount of set/get. The problem there is that you lose encapsulation. If you wanted to pass data in you can use different techniques.
For example I have a Customer Object that might contain a customer VO object (which may have getters and setters) but i would never load that VO with
.setXX
.SetKFJSD
.Set234i32
NEVER!
I would say
CustomerVO.Load(File)
CustomerVO.load(Request.customerObj);
Then all the code in side of .load() would do the work.
Now I have a customer object which can be loaded from most anything and i wouldn't have to write .SETXX code that just pulled from a web request, and a nother bunch of .SETXX statements that loaded from a file. Or at least i wouldn't have to see it anywhere - I would be comfortable knowing it was taken care of inside the class. Also others who use your code will be like...
"Oh wow I can just do a Load here! Nice"
instead of
"Oh man.. I have to write 399993 .set Statements.. I wanna be a psychologist"
The other object wouldn't unwrap it. It would ask the object to act on it via a method. Those methods are defined in the interface or class so you're guaranteed to have them work.
As for accessing data, there's nothing wrong with having an accessor here and there - but what typically happens is that become 50-60% of the code (maintaining accessors for all the Value Objects, etc..) When I first started writing java I had MASSIVE classes that had 40-50 private variables and i had a get/set on each one. It was hell! Breaking those out into seperate classes didn't help either. I would still have a large amount of set/get. The problem there is that you lose encapsulation. If you wanted to pass data in you can use different techniques.
For example I have a Customer Object that might contain a customer VO object (which may have getters and setters) but i would never load that VO with
.setXX
.SetKFJSD
.Set234i32
NEVER!
I would say
CustomerVO.Load(File)
CustomerVO.load(Request.customerObj);
Then all the code in side of .load() would do the work.
Now I have a customer object which can be loaded from most anything and i wouldn't have to write .SETXX code that just pulled from a web request, and a nother bunch of .SETXX statements that loaded from a file. Or at least i wouldn't have to see it anywhere - I would be comfortable knowing it was taken care of inside the class. Also others who use your code will be like...
"Oh wow I can just do a Load here! Nice"
instead of
"Oh man.. I have to write 399993 .set Statements.. I wanna be a psychologist"
stefanwagner
Programmer
according to the article, you send to it a message:
employee.display (Graphics g) so it can paint itself.
Well - I guess the author was thinking of
employee.display (JComponent parent) like JPanel - not Graphics, but it could mean he didn't did that very often.
seeking a job as java-programmer in Berlin:
employee.display (Graphics g) so it can paint itself.
Well - I guess the author was thinking of
employee.display (JComponent parent) like JPanel - not Graphics, but it could mean he didn't did that very often.
seeking a job as java-programmer in Berlin:
I suspected the author was going to suggest that. ;-)
My opinion on this design is that it closely ties the model to the view by way of having the model do all the view's work!
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
My opinion on this design is that it closely ties the model to the view by way of having the model do all the view's work!
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
Why not?
The code to display the customer would not be in the customer object. The customer object would not have any reference to a view specific object other than a class youw rite. The customer, who has access to all his data, will pass data from his private variables into the view helper function. The view helper function would then have the reference to the displaycontext.
This is much more maintainable then exposing EVERY variable from the customer and writing.
Display.set(customer.get) in a third class.
If the customer object is changed in some way, then you just need to update the customer code. Otherwise if you have a third class that bridges the two objects together you have to maintain the bridge class.. Therefore less maintenance... Plus having the customer call another object to do the display is much more logical and understandable to the person who maintains it.
The code to display the customer would not be in the customer object. The customer object would not have any reference to a view specific object other than a class youw rite. The customer, who has access to all his data, will pass data from his private variables into the view helper function. The view helper function would then have the reference to the displaycontext.
This is much more maintainable then exposing EVERY variable from the customer and writing.
Display.set(customer.get) in a third class.
If the customer object is changed in some way, then you just need to update the customer code. Otherwise if you have a third class that bridges the two objects together you have to maintain the bridge class.. Therefore less maintenance... Plus having the customer call another object to do the display is much more logical and understandable to the person who maintains it.
That's typically the responsibility of a Controller object in a model-view-controller pattern.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
That doesn't mean that it's cheaper to maintain though.
MVC is a great cookie cutter pattern but most of the time it breaks encapsulation. Encapsulation, one of the benefits of OOP, should be your primary motivation in design - do you not agree?
MVC is a great cookie cutter pattern but most of the time it breaks encapsulation. Encapsulation, one of the benefits of OOP, should be your primary motivation in design - do you not agree?
To a certain extent, yes. Customer objects shouldn't know anything about Invoice objects.
But also, Customer objects probably shouldn't know anything about display devices (screen, printer, etc). They should rely on helper objects to do this.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
But also, Customer objects probably shouldn't know anything about display devices (screen, printer, etc). They should rely on helper objects to do this.
Chip H.
____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Helpful tip
- Locked
- Question