Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: RE: [platform-swt-dev] org.eclipse.swt.SWT

Hi Scott!

It basically boils down to the question "What is a Point"? Is it a
Windowing System Point (your Mac example fits here). Or is it a geometrical
point (which guarentees only that there is a x-coordinate and
y-coordinate). If we consider the first definition of a Point, then we
definitely need to have checks whether the x and y coordinates are in sync
with the underlying windowing system. But, I think, here we think of a
Point only in terms of a geometrical point. Here, the point does not make
any assumptions about windowing system. It says 'I contain a x-coordinate
and a y-coordinate in a graphical system.' And I tend to the design of
Point as it is at present. It is the responsibilty of the windowing system
that uses the point to translate its meaning and to check whether it fits
to its culture.

Now the question about being notified when the Point changes. Where do you
percieve a need for this?
Suppose a Widget contains a Point as its location. How would you design it?
Would you expose the Point that the Widget contains so that user can change
its location or would you let the user set a new Point. As example, which
design you percieve as being superior?

Sol: A
public class SomeWdiget {

Point myStartLocation;

...
...

public void getStartLocation() {
return myStartLocation; // An internal data being exposed.
}

}

User calls it as
someWidget.getStartLocation().setX(10);

-----------------

Sol B:

public class SomeWidget {

Point myStartLocation;

...
...

public void getStartLocation() {
return new Point(myStartLocation);
}

public void setStartLocation(Point newStartLocation) {
myStartLocation = newStartLocation;
}

}

User calls it as
myStartLocation.set(new Point(10, 0));

-------------------

Do you really need to know when startLocation's x-coordinate is changed?
Doesn't getting notified when the startLocation as a whole changes satisfy
your need?

Thanks and Regards
Indukumar


                                                                                                                  
                              Scott Stanchfield                                                                   
                           <scott@xxxxxxxxxxxx>           To:  platform-swt-dev@xxxxxxxxxxx                       
                        Sent by:                          cc:                                                     
                        platform-swt-dev-admin@           Subject:   RE: RE: [platform-swt-dev]                   
                        eclipse.org                         org.eclipse.swt.SWT                                   
                                                                                                                  
                                                                                                                  
                                                                                                                  
                            02/28/2003 03:01 PM                                                                   
                              Please respond to                                                                   
                               platform-swt-dev                                                                   
                                                                                                                  
                                                                                                                  


> 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


_______________________________________________
platform-swt-dev mailing list
platform-swt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-swt-dev









Back to the top