+972 52-548-6969
Ranting About Design: System.IO.Compression.GZipStream vs. ICSharpCode.SharpZipLib.GZip.GZip*Stream
I had a change today to look at the implementation of both
classes, and I really don’t get what went through the minds of the
developers in Microsoft when they wrote this class.
To be (brutally) short, GZip is a derivative of the Deflate
algorithm with some additional headers tucks on it. This seems like an ideal
case for inheritance, put the Deflate algorithm in its own class, and then put
the GZip handling in a derived class.
On the surface, this is what both Microsoft and #ZipLib did,
but I took a look inside today with Reflector and found that
System.IO.Compression.GZipStream is nothing but an empty shell around DeflateStream.
I mostly expected that, but I was very surprised to see that no where in
GZipStream there was handling of the GZip headers.
Looking a little deeper, I found this constructor:
internal DeflateStream(Stream stream, CompressionMode mode, bool leaveOpen, bool usingGZip)
It makes the OO developer in me cringe in pain. Why would
they do that? This means that the DeflateStream needs to knows about its
children, that it has specialized behavior for one specific child, etc. This is
just wrong.
The #ZipLib got classes that actually have behavior, by the way. That is, the child
class extend the functionality of
the base class. This sounds familiar, I wonder where I heard those before…
Comments
Comment preview