Recommened design pattern to handle multiple compression algorithms for a class hierarchy
Posted
by
sgorozco
on Programmers
See other posts from Programmers
or by sgorozco
Published on 2013-06-25T19:19:49Z
Indexed on
2013/06/25
22:28 UTC
Read the original article
Hit count: 295
For all you OOD experts. What would be the recommended way to model the following scenario?
I have a certain class hierarchy similar to the following one:
class Base {
...
}
class Derived1 : Base {
...
}
class Derived2 : Base {
...
}
...
Next, I would like to implement different compression/decompression engines for this hierarchy. (I already have code for several strategies that best handle different cases, like file compression, network stream compression, legacy system compression, etc.)
I would like the compression strategy to be pluggable and chosen at runtime, however I'm not sure how to handle the class hierarchy. Currently I have a tighly-coupled design that looks like this:
interface ICompressor {
byte[] Compress(Base instance);
}
class Strategy1Compressor : ICompressor {
byte[] Compress(Base instance) {
// Common compression guts for Base class
...
//
if( instance is Derived1 ) {
// Compression guts for Derived1 class
}
if( instance is Derived2 ) {
// Compression guts for Derived2 class
}
// Additional compression logic to handle other class derivations
...
}
}
As it is, whenever I add a new derived class inheriting from Base, I would have to modify all compression strategies to take into account this new class. Is there a design pattern that allows me to decouple this, and allow me to easily introduce more classes to the Base hierarchy and/or additional compression strategies?
© Programmers or respective owner