RE: RE: [platform-swt-dev] org.eclipse.swt.SWT

[Scott Stanchfield <scott@xxxxxxxxxxxx>]

> I do not think that OO should be applied all the time. Take
> the example of
> SWT's Point class. It does not require those features of OO.
> There is no
> need to check whether the value is valid or not (as in case
> of a point, any
> integer value is a valid value; even negative ones!).

I'll take issue with that one ;)

[See http://javadude.com/articles, article "Rules of Reuse" for details
on my POV]

In my mind, the main point of getters/setters is the ability to change
where/how the actual data is dealt with.

Point is actually good example here.

[Note: I'm not trying to redesign Point here, but present an example of
how getters/setters give you a ton of flexibility in implementation]

Think about the Mac for a second. (0,0) is the bottom left corner (or
was last time I touched a Mac a while back), as opposed to top-left
where most graphics engines assign it.

Currently, the translation is being done at a lower level than point;
something deep inside the SWT Mac implementation translates the point
for us.

What if during refactoring we decide that the translation would make
more sense inside Point itself? Unfortunately, that's impossible, as the
fields are exposed.

Had Point used getters/setters, the implementation of the getters and
setters could be refactored into a Bridge pattern, using different
implementation details for different graphics engines. The client of
Point doesn't know or care how the data is stored, as long as he sees it
as being relative to upper-left.


*** Not to mention, what if I, a user of Point, am interested in knowing
when the data changes? With public fields, I cannot possibly setup any
event notification for changes. If Point had defined getters/setters
(and made the fields public), a later version of Point could easily have
change notification added to its setter(s).


Private getters/setters are also quite useful (aka "Self
Encapsulation"). In my code I restrict access to instance variables to
methods that need to read/write them (like getters/setters). This makes
it easy to apply new rules on how those data are used, in a single
place, and be sure that all uses have those rules.
Firing change notification or updating dependent internal state is a
good example of what might be done.


Finally, note that it would have been great for Java to have a
"property" keyword, defining data with automatic getters/setters (which
would be overridden). (Not a new concept, of course...) Then 90% of
getters/setters could be defined automatically and not take up any room
in the classfile. For example ("bound" would be another keyword
describing properties that fire change notification; "read" and "write"
would describe properties that expose getters/setters):

  class Chef {
    property String name: read write bound;
    property String address : read write bound;
    property String uniqueId: read;

    public String getName() {
      return "Chef " + name;
    }
  }

Of course using this could have the syntactic sugar of

  Chef c = new Chef();
  c.name = "Scott";
  System.out.println(c.name);

which would automatically call the get/set methods...

Ahhh, hindsight...

-- Scott