Tired of 100s of stupid Getter/Setter methods

[Timo Nentwig]

Hi!

IDE like eclipse have methods to autmatically generate Getter/Setter but
they bloat the code and make it more hard to read. I wonder why this isn't
something the compiler could do at compile-time. Why not simply invent a
new keyword, e.g. bean. Every bean is known to the compiler to have a
Getter/Setter which can be overrided:

public Test
{
// will generate:
// String getBlah();
// void setBlah(String s) { this.blah = s; }
public bean String blah;

// and can be overridden:

public void setBlah(String s)
{
whatever();
super.setBlah(s);
}
}

Regards
Timo

 

[Silvio Bierman]

Hi!

IDE like eclipse have methods to autmatically generate Getter/Setter but
they bloat the code and make it more hard to read. I wonder why this isn't
something the compiler could do at compile-time. Why not simply invent a
new keyword, e.g. bean. Every bean is known to the compiler to have a
Getter/Setter which can be overrided:

public Test
{
// will generate:
// String getBlah();
// void setBlah(String s) { this.blah = s; }
public bean String blah;

// and can be overridden:

public void setBlah(String s)
{
whatever();
super.setBlah(s);
}
}

Regards
Timo

The need for many getter/setter method is usually an indication of bad
design. A language feature like you describe would only stimulate such
designs.

Silvio Bierman

 

[Timo Nentwig]

method is usually an indication of bad
design. A language feature like you

Ok, I went over the top, it aren't 100s of lines but it are enough. It just
superflues code that bloats the code and deflects from the essential.

Timo

 

[Joseph Dionne]

Silvio Bierman wrote:




Ok, I went over the top, it aren't 100s of lines but it are enough. It just
superflues code that bloats the code and deflects from the essential.

Timo

Forgive my intrusion into this discussion, I am new to OO being an a
long time assembly and 'c' developer, in general a linear programmer.
But, I the "feeling" I get from reading "experts" on OO is that "good"
OO programming is to use getters/setters. Am I mistaken?

 

[Michael Borgwardt]

Forgive my intrusion into this discussion, I am new to OO being an a
long time assembly and 'c' developer, in general a linear programmer.
But, I the "feeling" I get from reading "experts" on OO is that "good"
OO programming is to use getters/setters. Am I mistaken?

One should certainly use get/set methods instead of allowing direct
access to member variables.

What Silvio meant is that *lots* of get/set methods in the same class are
a sign of bad design - a class with 5 data fields is fine, but if there
are more than 10, they can probably grouped more naturally into two or
three different classes.

 

[Joseph Dionne]

One should certainly use get/set methods instead of allowing direct
access to member variables.

What Silvio meant is that *lots* of get/set methods in the same class are
a sign of bad design - a class with 5 data fields is fine, but if there
are more than 10, they can probably grouped more naturally into two or
three different classes.

Ah, thanks for the clarification. In summary, reduce large classes to
more atomic ones, and extend/inherit from them.

 

[Dave Glasser]

One should certainly use get/set methods instead of allowing direct
access to member variables.

What Silvio meant is that *lots* of get/set methods in the same class are
a sign of bad design - a class with 5 data fields is fine, but if there
are more than 10, they can probably grouped more naturally into two or
three different classes.

Why is that? If a particular type of entity happens to have more than
10 attributes, and you're modeling it with a Java class, why is it
"more natural" to split it into two more more classes?

 

[Michael Borgwardt]

Ah, thanks for the clarification. In summary, reduce large classes to
more atomic ones, and extend/inherit from them.

Actually, one should use composition instead of inheritance most
of the time. For example, to represent a physical object,
instead of:

class PhysicalObject(){
private double mass;
private double posX;
private double posY;
private double posZ;
private double speedX;
private double speedY;
private double speedZ;
(insert getters/setters)
}

you use

class PhysicalObject(){
private double mass;
private Value3D position;
private Value3D speed;
(insert getters/setters)
}

class value3D(){
private double valueX;
private double valueY;
private double valueZ;
(insert getters/setters)
}

Of course, using arrays would probably be more appropriate in this case.
Another example: a Customer class would have a field name pointing to an
instance of class Name with String fields firstName, lastName, title and
a field address pointing to an instance of class Address with String fields
street, number, city, zip code, state, country.

 

[Timo Nentwig]

Michael Borgwardt wrote:

What Silvio meant is that *lots* of get/set methods in the same class are
a sign of bad design - a class with 5 data fields is fine, but if there
are more than 10, they can probably grouped more naturally into two or
three different classes.

And here's my I mean:

I currently implement the DNS protocol, I even split the message into its
sections (header, question and 3 remaining ResourceRecords). Hell, there
are more than 5 information in the header. Shall I write a HeaderPart1 and
HeaderPart2 class???

And even 5 getter/setter are superflues. I only messes the source.

 

[Michael Borgwardt]

Why is that? If a particular type of entity happens to have more than
10 attributes, and you're modeling it with a Java class, why is it
"more natural" to split it into two more more classes?

In most cases, a large number of attributes can be naturally split into
groups which can then be "sub-entities" of which your entity is composed.
This is maybe not always true, but I think you'd have to look pretty hard
to come up with a good example where no such grouping is logical.

 

[Dimitri Maziuk]

Timo Nentwig sez:

Michael Borgwardt wrote:



And here's my I mean:

I currently implement the DNS protocol, I even split the message into its
sections (header, question and 3 remaining ResourceRecords). Hell, there
are more than 5 information in the header. Shall I write a HeaderPart1 and
HeaderPart2 class???

And even 5 getter/setter are superflues. I only messes the source.

I miss Delphi's property keyword. It allows you to specify read and/or
write access directly to private variable or via a (private) get/setter
method. You can even have write-only properties. It's just syntactic
sugar, of course, but it's sweeet.

Dima

 

[nos]

Hi!

IDE like eclipse have methods to autmatically generate Getter/Setter but
they bloat the code and make it more hard to read. I wonder why this isn't
something the compiler could do at compile-time. Why not simply invent a
new keyword, e.g. bean. Every bean is known to the compiler to have a
Getter/Setter which can be overrided:

public Test
{
// will generate:
// String getBlah();
// void setBlah(String s) { this.blah = s; }
public bean String blah;

// and can be overridden:

public void setBlah(String s)
{
whatever();
super.setBlah(s);
}
}

Regards
Timo

Either the data are needed outside the class or they are not.
If there are so many that are needed, perhaps the design
is not so good. If it is needed then get/set should be used.

 

[Dave Glasser]

In most cases, a large number of attributes can be naturally split into
groups which can then be "sub-entities" of which your entity is composed.
This is maybe not always true, but I think you'd have to look pretty hard
to come up with a good example where no such grouping is logical.

It may often be the case that, given a large number of attributes of a
single entity type, that indivdual attributes will tend to fall into
one of several logical groupings. But it doesn't automatically follow
that those groupings should be split into their own classes from which
objects of the original class can be composed. That, to me, is a
recipe for code bloat, which is what the original poster was
complaining about.

You can come up with examples to support any position in this
discussion, but I disagree with the implication that having large
numbers of getters and setters in a single class is inherently bad
design. I would argue that there's no relationship between the number
of setters/getters in a class and the quality of that class's design.
A class with a large number of getters/setters can be part of a
well-designed OO system just as one with few getters/setters can be
part of a poorly designed one.

 

[Joseph Dane]

A class with a large number of getters/setters can be part of a
well-designed OO system just as one with few getters/setters can be
part of a poorly designed one.

I'm with you. More to the point, even if you separated the related
properties into component classes, you're still left with the same
number of properties, each of which requires an explicit get/set
pair.

The desire of the OP to avoid the overhead of explicit property
accessors is reasonable, and other languages (notably C#) provide
what he wants in this respect at least, apparently w/o any
catastrophic effects on the language.

 

[Tor Iver Wilhelmsen]

The desire of the OP to avoid the overhead of explicit property
accessors is reasonable, and other languages (notably C#) provide
what he wants in this respect at least, apparently w/o any
catastrophic effects on the language.

It provides a syntactic shortcut for *using* them: You still have to
write the getter and setter methods:

private int _foo;

// Property
public int Foo {

// Compiler turns this into int get_Foo()
get {
return _foo;
}

// Compiler turns this into void set_Foo(int value)
set {
_foo = value;
}
};

// ...

Foo = 42; // Compiler turns this into set_Foo(42);

 

[Mark 'Kamikaze' Hughes]

Actually, one should use composition instead of inheritance most
of the time.

If one is a procedural programmer forced to use OOP against his will,
perhaps. Those who actually use OOP languages correctly will do it the
other way.

 

[Dimitri Maziuk]

Mark 'Kamikaze' Hughes sez:

If one is a procedural programmer forced to use OOP against his will,
perhaps. Those who actually use OOP languages correctly will do it the
other way.

s/OOP langages/Java/

With languages that don't force you to subclass Object every
time and allow multiple inheritance, there are compelling
arguments for using composition instead.

Dima

 

[Roedy Green]

. Why not simply invent a
new keyword, e.g. bean.

You really want skeletons that can be fleshed out with real code that
does something useful, e.g. only allow good data in.

I wrote some "stompers" to produce the code. Basically you just feed
in the names and types of the variables and it generates the
declarations, gets and sets, and you can then flesh them out.

If you want the source I would be happy to email it.

 

[Roedy Green]

I get from reading "experts" on OO is that "good"
OO programming is to use getters/setters. Am I mistaken?

It is considered poor form to expose instance variables as public
because you can't later insert get/set code.

The problem with Java is you have to make that decision when you
start. You can't change your mind without ripping up all the client
code.

Other languages such as Delphi and Eiffel let you change your mind
without changing client code. They also lets you use the tidier
variable syntax instead of the clumsy get/set syntax in the client
code.

This is something I have been pushing for Java for a long time.
See http://mindprod.com/jgloss/bali.html

 

[Mark 'Kamikaze' Hughes]

Mark 'Kamikaze' Hughes sez:
s/OOP langages/Java/
With languages that don't force you to subclass Object every
time and allow multiple inheritance, there are compelling
arguments for using composition instead.

Hmn. My other main OOP experience was with Objective C, which has a
somewhat Java-like inheritance system, but I just can't see the value of
creating things by composition that aren't composite. Java does, of
course, allow multiple inheritance in the only way that's safe: through
interfaces.

A good example of a class that's too large for its own good is
java.awt.Component. In a more practical and well-designed GUI toolkit,
you'd start with Widgets with just a bounding box, some way to paint
themselves, and primitive event listeners. You'd then extend that to
make more complex components. I'd probably put foreground, background,
text, and a few more attributes in interfaces, because they're found on
only a subset of the subclasses. A leaf class like Button would still
be fairly complex, but it could be understood in step-by-step
increments.