[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
