Post
Ask Question

Writing Better Code - Keepin' it Extensible

Managing Change in Code

The 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:


Similar Articles