[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: OO should break when broken
I've snipped large parts of Vesa's post, mostly because he objects to
the simplifications I made in order to keep my argument short, but does
not explicitly disagree with my conclusion. Again, I think shapes are
not a good example to use in discussions of object modeling, because
the mathematical classification of shapes that everyone is familiar
with does not map to a class hierarchy that models those shapes well.
Vesa, do you disagree with this conclusion, or just my argument in
support of it?
On Monday, September 1, 2003, at 04:01 PM, email@example.com
> Stated in another way, the essense of a subclass is to constrain the
> of states of the superclass.
Interesting. Would you care to give an example, or explain why you
> 2. One just can not generally ignore behaviour (= functions and
> when dealing with software. Representational (data) hierarchies are
> unless they satisfy useful invariants that can be exploited by
> entities (= functions and procedures).
Sure. But it's not terribly useful to talk about behaviour unless you
have an idea of the function the software is to perform. So basically,
the whole discussion boils down to "it depends on your application."
For sake of argument, assume that all the shape classes have to
implement a simple interface: #width, #height and #draw.