Managing Change in
CodeThe OCP (Open-Close
Principle) states that we should keep our objects open for extensibility and
closed for modification. We'll be looking at just the first part of this
principle, keeping the code open for extensibility. It's a pretty simple
rule but it is often ignored making code brittle
and difficult to maintain. It's also one of those things that requires
keeping in mind the future maintenance of our code during the coding process
which is easy to let slide. If we follow the OCP as we are writing code then
our projects and classes will have much more potential for reuse and can
grow and change with shifting requirements much easier than if we are
"sleep-coding" (similar to the more commonly known "sleep-walking") and
don't keep extensibility in mind.
Violation I.
The Dreaded Switch
One of the primary "red flags" I have
found for finding violations of the OCP is the use of the "switch"
statement. I usually have to think long an hard
about using the "switch" in my code, especially when it is implemented along
with enums. Sometimes it is actually the best (or only) way, but more often
than not, there is a better construct to use. Let's look at and example of
an architecture using the "switch" statement that is not open for
extension and will cause us to have to go back and change our code in
multiple places as our software matures. The "ClosedAnimal.Noise()"
method in the following example is closed to extensibility.
public
enum
AnimalType
{
Cat, Dog, Wolf, Bear
}
public class
ClosedAnimal
{
public ClosedAnimal(AnimalType
pType)
{
m_type = pType;
}
private
AnimalType m_type;
public
AnimalType AnimalType
{
get {
return m_type; }
}
public
String Noise()
{
switch (m_type)
{
case
AnimalType.Cat:
return
"Meow";
case
AnimalType.Dog:
return
"Bark";
case
AnimalType.Wolf:
return
"Howl";
case
AnimalType.Bear:
return
"Growl";
default:
throw
new
InvalidOperationException("Unrecognized
AnimalType: ", m_type);
}
}
}
And the calling code...
static
void Main(string[]
args)
{
ClosedAnimal a =
new
ClosedAnimal(AnimalType.Dog);
Console.WriteLine(a.Noise());
Console.ReadLine();
}
The problem we are going to run into is
when we want to add a new AnimalType, we'll have to "break into" our
Noise() method and change it to accommodate the
change every time we have a new enum value. Also, if this is the
architecture of our solution, there will most likely be multiple methods
similar to "Noise()" that will need changing. If
we miss one, our software is essentially "broken". This approach is
definitely not open for extension and as a result will be a lot of headache
to maintain.
The lesson here?
We have to be really careful and double (and triple) check ourselves when we
want to use enums and/or the "switch" statement to be sure we are not
backing ourselves in a corner and building code that will break with a small
change or be difficult to maintain. As you can see, the
ClosedAnimal.Noise() method is not open for extension and it
is this kind of use of enums and switches we have to be careful of when
coding.
Alternative to
Violation I
Let's look at a different way to achieve
the same functionality in a way that is open for extension using OOP (Object
Oriented Programming) inheritance.
public
abstract class
OpenAnimal
{
public
abstract String
Noise();
}
public class
Cat :
OpenAnimal
{
public
override string Noise()
{
return
"Meow";
}
}
public class
Dog :
OpenAnimal
{
public
override string Noise()
{
return
"Bark";
}
}
And the calling code....
static
void Main(string[]
args)
{
OpenAnimal b =
new
Dog();
Console.WriteLine(b.Noise());
Console.ReadLine();
}
Now, whenever we want a new OpenAnimal we
just derive from the base class and provide an implementation for the
abstract "Noise()" method. This way the change
happens in one place (possible in a OpenAnimal factory) and our code is now
open for extensibility because as we build new classes derived from
OpenAnimal, the "Noise()" method is no longer dependent on the state of our
animal object and does not break like in the fist example.
Violation II.
Runtime Type Checking
Another more subtle situation that should
start the "red-flag" bells ringing is when we see logical branching based on
run-time type checking. This is a very similar structure to the
switch statement but instead implemented with a
"if-else" chain.
public
class
Dinosaur :
OpenAnimal
{
public
String Eat(OpenAnimal
animal)
{
if (animal
is
Dog ||
animal is
Wolf ||
animal is
Bear)
return
"Yummy";
else if
(animal is
Cat)
// everyone knows dinosaurs don't like to eat
cats
return
"Not worth it";
else
return String.Empty;
// what happens if a dinosaur tries to eat a
dinosaur or another animal?
}
public
override string Noise()
{
return
"Screech";
// not really sure what noise dinosaurs make....
}
}
As you can see, every time we have a new
animal we may have to go update our dinosaur which is not good (we are not
open for extensibility here).
Alternative to
Violation II
One possible solution (very similar to our
first alternative) would to be to expose a property for each OpenAnimal that
will indicate whether or not Dinosaurs will eat the animal. This way, with
each new class deriving from OpenAnimal, we know that we have to implement
this property. This way our Dinosaur object is now open
for extensibility. Keep in mind finding an alternative to runtime
type checking is much more app-specific and there may have to be a
better approach to use for your solution.
public
abstract class
OpenAnimal
{
public
abstract String
Noise();
public
abstract Boolean
IsTastyToLargeLizzards { get; }
}
public class
Cat :
OpenAnimal
{
public
override string Noise()
{
return
"Meow";
}
public
override bool
IsTastyToLargeLizzards
{
get {
return false; }
}
}
public class
OpenDinosaur :
OpenAnimal
{
public
string Eat(OpenAnimal
animal)
{
if (animal.IsTastyToLargeLizzards)
return
"Yummy";
else
return
"Not worth it";
}
public
override string Noise()
{
return
"Screech";
// not really sure what noise dinosaurs make....
}
public
override bool
IsTastyToLargeLizzards
{
get {
return false; }
}
}
Hopefully these
example give you an idea of where we can back ourselves into a corner
in terms of extensibility and will help you make choices that will make the
code you write easier to maintain.
Until next time,
Happy coding
References: