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

[Scott Stanchfield <scott@xxxxxxxxxxxx>]

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
>
>
>