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

[Steve_Northover@xxxxxxxxxx]

Scott, what is missing in your analysis is the concept of ownership. There is almost no way that
a class, no matter how well written, will be reusable by subclassing unless it has been designed
that way in the first place.  From the point of view of code maintenance, ModelPoint is the correct
answer because "fancy SWT Point" is unlikely to have all the capability that the application needs
and ModelPoint as a subclass of "fancy SWT Point" is subject to breakage when the superclass
changes.  ModelPoint, subclass of Object is stable over time.

Basically, there are two crowds in the world.  Some people believe in subclassing everything and
attempting reuse as much as possible.  The other believe in API and subclassing only those classes
that have been written with the intention of subclassing.

Scott Stanchfield <scott@xxxxxxxxxxxx> Sent by: platform-swt-dev-admin@xxxxxxxxxxx 02/28/2003 11:40 AM Please respond to platform-swt-dev

To:        platform-swt-dev@xxxxxxxxxxx         cc:                 Subject:        RE: RE: [platform-swt-dev] org.eclipse.swt.SWT

I think you missed my point...

The point is that should be no need to reinvent the wheel here.

In a drawing tool, a Point model *is* a set of coordinates. There's no
difference between intended use. I'm using a Point object to keep track
of some location somewhere. Whether it's used for actually drawing on
the screen or keeping track of data that's not currently display, makes
no difference.

Subclasses could tweak the usage for specific scenarios if needed.

-- Scott

> -----Original Message-----
> From: platform-swt-dev-admin@xxxxxxxxxxx
> [mailto:platform-swt-dev-admin@xxxxxxxxxxx]On Behalf Of
> vellapillli_h.indukumar@xxxxxxxxxx
> Sent: Friday, February 28, 2003 10:42 AM
> To: platform-swt-dev@xxxxxxxxxxx
> Subject: RE: RE: [platform-swt-dev] org.eclipse.swt.SWT
>
>
> With respect to SWT or Swing for that matter, I believe that
> Point need not
> have getters and setters. If you are using SWT/Swing to
> create a drawing
> tool, you would be better off using your own custom class to
> represent a
> point. In case of a drawing tool, Point is a model and not
> coordinates. In
> SWT/Swing, a Point represents a coordinate. There are conceptual
> differences between them. So I would suggest you have
> something in the line
> of PointModel with getters, setters etc.
>
>
>
>
>
>                               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 04:27 PM
>
>                               Please respond to
>
>                                platform-swt-dev
>
>
>
>
>
>
>
> > I agree with your points if the Point class is to be used
> > inside a Drawing Tool.
>
> This is the problem, IMHO. When someone designs a class,
> there's no way
> they can know all the possible places that class is truly useful.
>
> Why should there have to be multiple Point classes? The concept should
> be incredibly reusable. If it had been designed
>
>   class Point {
>     private int _x, _y;
>     public int getX() {return _x;}
>     public int getY() {return _y;}
>     public void setX(int x) {_x = x;}
>     public void setY(int y) {_y = y;}
>   }
>
> it could later be modified or subclassed to provide
> additional services
> such as notification, or different implementations such as automatic
> origin translation.
>
> As it currently exists, the only way to have a notifying Point, is to
> create an entirely new class...
> Something that could have been infinitely reusable, isn't...
>
> Bottom line: Three of my "rules of reuse" apply here:
>
> * (rule 1) All data must be private
> * (rule 2) Most (if not all) data should be exposed as JavaBean
> properties (ie getters/setters)
> * (rule 4) The get/set methods should be protected (or
> better, public),
> so subclasses can override and call
>
> (I think I might need to add another rule -- all objects must
> be created
> via factories, so the factory could replace the actual type of object
> returned with a subclass under certain circumstances... hmmm...)
> -- Scott
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
>
>
>
>
>
>
> _______________________________________________
> platform-swt-dev mailing list
> platform-swt-dev@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/platform-swt-dev
>
>
>


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