Strong bounds, and a lot of inter-dependency make the construction
fragile indeed.
I'll add that the worst thing with subclassing is whenever you want to
extend the behavior of superclass.
You'll then have to care of all the specific hacks of subclasses, some
ignoring some states, the others changing the meaning of them.
A good example I had recently was trying to implement a
Stream>>readStream subclassResponsibility which would either respond
self for a readStream or transparently transform the contents of a
WriteStream.
Simple enough you might think without reading code, but you should
really try just to understand how subclassing can turn evil.
Also it's a good exercize to reread WriteStream and explain why the
hell we need those three states, readLimit, writeLimit, position, why
we find so many 'readLimit := readLimit max: position.' snippets, and
how we can possibly change anything when more than 50 references each
raise the barrier that high.
Stream is a very good counter example of subclassing, I'd say the
shortest way to freeze code up to the point of un-maintainability.
As long as the good reasons for subclassing are put in balance with
the good reasons for not subclassing, I'm OK.
Nicolas
2013/3/5 Bert Freudenberg <
[hidden email]>:
> On 2013-03-05, at 23:06, tim Rowledge <
[hidden email]> wrote:
>
>> On 05-03-2013, at 2:01 PM, Chris Muller <
[hidden email]> wrote:
>>
>>>> P.S.: If XMLOrderedList is a subclass of OrderedCollection, then it's just
>>>> plain wrong IMHO. Creating subclasses of collections in external packages is
>>>> bad practice.
>>>
>>> Hi Levente, I was just curious why that is bad practice.
>>
>> I am also curious why you think that. Making subclasses is pretty much the essence of programming.
>
> I'm curious why you would feel the need to subclass OrderedCollection, have to agree with Levente.
>
> It's bad practice to subclass for no good reason, because you're much more likely to depend on the implementation details of your superclass, and not just its external interface. One shortcoming of Smalltalk in particular is that all the implementation details are visible, so they tend to get made use of. Which is perfectly fine for a personal computing system in one image, but not for a collaboratively maintained one, where we have to worry about breaking subclasses that are not in the image.
>
> So feel free to subclass away, but be prepared for dealing with the consequences later. Strong coupling is bad, and subclassing creates a pretty strong bound.
>
> - Bert -
>
>
Locked
