Plus you'd need IAsyncReadableStream, IAsyncWritableStream, IAsyncSeekableStream, etc. Composition of types in a static type system only gets you so far.
Design concerns in a framework are a little different than those concerns for an application. You not only have to worry about maintenance, you also have serious binary compatibility concerns around code that you didn't write, never see, and know is out there somewhere but know nothing about. I again point to the .NET Framework design guidelines, particularly the annotations. There's a discussion in there (my copy's currently packed in a box or I'd give a page #) when talking about preferring abstract base classes over interfaces about the streams library and why it's built the way it is. You may not agree with the conclusions, but it's definitely worth reading and thinking about. -Chris -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Frank Schwieterman Sent: Friday, March 11, 2011 12:15 PM To: [email protected] Subject: Re: Your Favorite Liskov Violations Examples in .NET You'd also need an ISeekableReadyStream and ISeekableWriteStrream, as not all streams support seek. Its awkward, maybe in the same way the System.Net.WebRequest.CreateWebRequest() was built to support multiple protocols, making the only protocol I care about (HTTP) require more legwork. I don't know if its a Liskov violation. This whole Liskov threads has made me think there is some "In Soviet Russia, ..." joke I could make but I haven't thought of it yet. On Fri, Mar 11, 2011 at 11:35 AM, Louis DeJardin <[email protected]> wrote: > 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. > -- 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. -- 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.
