AspectJ: solution to Java's repetitiveness?

[Daniel Pitts]

They violate encapsulation, reduce maintainability, and in most cases
indicate a designer that didn't understand the problem domain. An
excellent article on their problems is here:

Thats too broad of a generalization...
Getters/Setters help with the uniform access principal.
<http://en.wikipedia.org/wiki/Uniform_access_principle>
You don't want to know if the property is just a field, or a calculated
property, or even if getting/setting them has other side-effects.
Encapsulating the access to "fields" view property getters/setters is
generally a good thing...

What can be bad is when people expose EVERY field as getters and
setters. The only properties that should have getters and setters are
the ones that should be probed or affected.

Conversely, the principal of Tell, Don't Ask, should be observed where
appropriate.
<http://c2.com/cgi/wiki?TellDontAsk>

The true moral is "Don't Blindly Apply Patterns Or Rules Without
Understanding Why."

 

[Arved Sandstrom]

They violate encapsulation, reduce maintainability, and in most cases
indicate a designer that didn't understand the problem domain. An
excellent article on their problems is here:

Allen Holub hit on some good points and got overly zealous. Return
interfaces when possible, yes. Strive to have classes do work that is
properly their responsibility, yes. Strive not to have unnecessary
accessors, yes.

I can't take his page 2 example (getX() returning long instead of int) too
seriously. I'm sorry, but if you don't have enough of a handle on your
problem to figure out what primitive types you need to use, you're likely
also having problems deciding how to design your classes. The decision as
to what integer type or floating point type to use should get as much
attention as your class design.

As far as encapsulation goes, a better term to use is "information hiding"
(see Wikipedia). Given that latter phrase, using getters & setters is only
problematic insofar as it ties one to implementation. To allude to
http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html (a
link in the Wiki article on information hiding), let's assume we have a
Position class that describes a position in 3D space. Now, internally this
may be stored as 3 doubles for x, y and z, or a 3-element array of doubles,
or in spherical coordinates (radius, zenith angle, azimuth angle, all in
double). Now, for calculations involving two or more Positions (like
distance) ideally you'd have methods that work with Positions, not the
specific coordinates. But for a situation where another class may actually
need the coordinates, and you supply getX(), getY() and getZ(), and
possibly even corresponding setters, this is *not* violating information
hiding, for several reasons. One, (z,y,z) has real physical meaning in the
problem domain. Two, just because you are returning (or setting) x,y and z
doesn't mean that the internal storage is 3 doubles.

Maintainability? Non-issue. Getters & setters should be for visible
attributes of the class. In the above example x, y and z are indisputably
visible (real) attributes of a 3D position. Provided that the getX/setX etc
accessors are properly translating between (z,y,z) and the actual
implementation (something only done in one class), any client class can
very easily work with (x,y,z). Provided that you follow this principle you
ought not to have problems with accessors.

AHS

 

[Arne Vajhøj]

They violate encapsulation, reduce maintainability,

Actually getter and setter provides encapsulation and thereby
increases maintainability.

and in most cases
indicate a designer that didn't understand the problem domain. An
excellent article on their problems is here:

<http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1>

Some people think it is funny to write articles like that.

And some readers take them far too serious.

His logic is rather flawed. He "proves" that it breaks encapsulation
arguing that if an int is changed to a long then it will break
calling code. Guess what - it is impossible no matter how you do
it to get information now in long reliable over to something that
expects an int. He suggests callback and returning an interface.
Neither of those solves the problem.

Arne

 

[Joshua Cranmer]

They violate encapsulation, reduce maintainability, and in most cases
indicate a designer that didn't understand the problem domain. An
excellent article on their problems is here:

Not necessarily. Suppose we have a point:

class Point {
private float x, y;
public float getX() {return x;}
// etc.
}

Later on, we decide that we need to use polar coordinates, so we add
some polar coordinates to our class:

class Point {
// as before, but:
public float getR() {return Math.sqrt(x*x+y*y);}
// and etc.
}

Even later on, we decide that we should be storing data in polar
coordinates because we use polar coordinates almost exclusively, so we
can just change a few lines:

class Point {
private float r, theta;
public float getX() {return r*Math.cos(theta);}
public float getR() {return r;}
// and etc.
}

Using a struct-like definition would have made this change hard to make.
So even though it seems to be bad design, we've increased
maintainability by letting us choose how these variables x, y, r, and
theta are actually stored.

Certainly, however, they can be bad if used heavily. But we're assuming
the best in people, since any concept can be bad if abused.