Ah, yes. Maybe it's a violation of the "I" you're looking for in the case of Stream?
If there was an IReadableStream, IWritableStream, and IStream : IReadableStream, IWritableStream would you even need the Stream abstract base class? The subtypes don't share implementation code at that low level. Even if it did turn out there was some protected code in common between, for example, a FileStream, SocketStream, and EncryptionStream you would be better off favoring composition over inheritance. Other classes, for example, whose only concern was an efficient write-bytes-buffer... Or winapi io handle wrapper... On Fri, Mar 11, 2011 at 10:42 AM, Justin Bozonier <[email protected]>wrote: > I think it is technically ok by the Liskov Principle (I researched > some more about the original intent) since the actual contract > stipulates that you check that property. > > The fact that you need to care about the implementation is suboptimal > though. I typically think of LSP meaning that if I have a method on an > interface then ideally I should be able to use it. > > The advent of CQRS supports this point (though not definitively). > > I'm also not saying Microsoft did a piss poor job just that for my > use, avoiding the property check would have resulted in an API design > that was cleaner and simpler for my use. > > -- You received this message because you are subscribed to the Google Groups "Seattle area Alt.Net" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/altnetseattle?hl=en.
