On 11/2/2010 8:44 AM, Göran Krampe wrote:
>> One of the reasons to make it subclass is to reuse behavior inherited
>> from Stream.
>> But if subclass needs to override 90%+ of inherited methods, then it
>> makes not much sense.
>> I didn't measured how much methods need to be overridden by
>> SocketStream, but i suspect it is the case, since sockets are quite
>> special.
>
> Yes, that is my guess too. And yes, just going by the "is a" test may
> create brittle classes which break when changes are made because they
> really are too different.

Huh? What is the conceptual difference between a ReadWriteStream and a 
SocketStream? The main difference is that the former is an internal 
stream, the latter an external stream. But in terms of behavior they are 
more similar than different as expressed by having to a large number of 
methods with the same name and behavior (i.e., Stream methods). As a 
consequence, there is good reason to be wanting to define some 
additional methods in terms of these protocols, in my case I was 
actually looking at promoting some methods up to class Stream to have 
them accessible to all kinds of streams, including SocketStream. I can 
of course keep duplicating these methods but it seems completely 
pointless given that they're all streams and as a result should share a 
common heritage.

As for brittleness, in my experience brittleness is generally the result 
of accessing state directly (i.e., the superclass accesses state 
directly and that can break an invariant introduced by a subclass). But 
as it happens, Stream is stateless, so I really don't see where any 
brittleness would be introduced. I'd be curious about where you think 
brittleness would come into play and why.

Cheers,
   - Andreas