Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Writing 20 or 30 get/set methods is bad' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Writing 20 or 30 get/set methods is bad
Authored by: a1291762 on Aug 05, '02 07:24:51PM
I find it a pain when writing java code to type out 20 or 30 get set methods (since you sould use get and set in java instead of referring straight to the variable) so i wrote a perl scrpt that does this for me.

If you have classes with 20-30 get/set methods then your design is clearly wrong. There's no reason for other classes to need access to all the internal variables of a class. You should do an actual design and only allow access to things that external classes need access too. Remeber the point of abstraction is that the external interface does not have to resemble the internal structure of a class.

/me thinks you are using the C-struct mentality, in which case you would be better off just using public variables. Making all the varables private and creating get/set methods doesn't make your code any better. Data Flow Diagrams (DFD) and Class Reponsibility Cards (CRC) are a great way to find out just what needs to be shared between classes.

Remember, the goal of OO programming is to increase cohesion in classes and decrease coupling between classes

[ Reply to This | # ]

Writing 20 or 30 get/set methods is bad
Authored by: Accura on Aug 06, '02 12:01:32AM

I do understand this, all the script does is do the basic get/set method i usually have a couple of extra lines of code that converts or changes the data in some way so i don't have to remember to do this every time. also i use them mostly for internal class' and set as private or protected. as i said, this just does the grunt work.

When i learn i was told to allways use get or set instead of going stright to the veriable, i always questioned this but did it any way because i read it in a few books. do you know if i should or shouldn't do this and why?



[ Reply to This | # ]
Writing 20 or 30 get/set methods is bad
Authored by: Anonymous on Aug 06, '02 07:56:31AM

Encapsulation (or -for others who perhaps don't know-preventing access to the internals of a class from outside and requiring accessor functions) is a good thing.
However you should think carefully before immediately implementing a large number of accessor functions. Do you really need access to all of the functions of the class? Could you perhaps bundle related values into objects of some kind?
For example
int box_height;
int box_width;
int box_length;
int box_color;
into a class called box which is itself accessed from your main class
and accessed with product.box().height()
You still have each accessor function but now you can reuse the box class elsewhere. Perhaps you have a function volume() which might compute the volume of a box. And you could use the box class in another program altogether.

removals.storageCrate().volume()

Though color() would probably always be brown in this case(?)

It isn't that good an example. :-)

If you can break up the program into smaller units they are more likely to be resuseable. Which of course is one of these goals of OO programming :-)

I once took a lecture series at university called Software Engineering-objects and components where the lecturer recommended no more than 4 main responsibilities for any class. If you had more then you were supposed to refactor the application and seperate stuff out more.
I couldn't say whether I manage this in the code that I write. :-)

However regardless of all of this, this tool might come in handy. I'm not writing so much java at the moment.More demand for other things.
Thanks for thinking it up.

Angus



[ Reply to This | # ]
Writing 20 or 30 get/set methods is bad
Authored by: buzzlabs on Sep 01, '02 04:52:45AM

Yawn.

One thing I've found in the 10 years I've been programming professionally (been programming for 20 total) is that you should ignore a lot of what people tell you, and you should not look to those with degrees and all sorts of "OO expertise" for the answers.

Especially with Java... But anyway... The Java Beans notion is that you have "getter" and "setter" methods for the attributes which are to be publically-exposed in your class, rather than setting them directly and marking them public or otherwise accessible by other classes in your package. Therefore, it is wise to have "get" and "set" methods.

The project that I wrote Beano for was an ATG Dynamo project. The way to do things there was definitely to have "getter" and "setter" methods for your bean classes, as that's how their lovey (gag) "Relational View" abstraction atop JDBC handled things when it was moving data from SQL query ResultSets into your beans, therefore...

-S



[ Reply to This | # ]