Hello Jody
This is a pleasure to fully agree :) Less subclassing and more aggregation is
one of the "good practices" recommanded in Joshua's Blosh "Effective Java" book
(a kind of bible for Java developpers).
In the particular case of Circle/Ellipse however, the subclassing would still
appropr
Hi Martin? A discussion on OO Design ... here?
Let me offer a complementary view. The development of deep class
hierarchies (as with your Ellipse/Circle example) is one of the
unintended consequences of using subclassing for everything. Especially
in the case where you are going after code reus
Justin Deoliveira a écrit :
> Anyways, not trying to come across as negative Martin. I am +1 on
> introducing some sensible guidelines for subclassing. But lets do it for
> the right reasons.
Actually my intend was not to introduce any policy. The only purpose of my
email
was to provide a back
Then let me hit you back with a point of "practical" programming:
Only introduce abstractions when its necessary as with abstractions you
sacrifice simplicity and readability. :)
While I agree with you that too often subclassing can be miss used, i am
not sure it makes sense to adopt a specific
I feel that I should remind a point of object oriented programming:
There is many way to see subclassing. The vision adopted by ISO specification
(which is also the vision that I suggest to adopt) is in the sense of
"specialization", not necessarly "having more attributes". Thinks verb "to be",
