This is the second part of a five-part series about SOLID as Rock design principle. The SOLID design principles, when combined together, make it easy for a programmer to craft software that is easy to maintain, reuse & extend. pen- losed rinciple(OCP) is the second principle in this series which I will discuss here with minimalistic example in along with its benefits & generic guideline. O C P Modern C++ /!\: Originally published @ . www.vishalchovatiya.com By the way, If you haven't gone through my previous articles on design principles, then below is the quick links: RP -- Single Responsibility Principle S CP -- Open/Closed Principle O SP -- Liskov Substitution Principle L SP -- Interface Segregation Principle I IP -- Dependency Inversion Principle D The code snippets you see throughout this series of articles are simplified not sophisticated. So you often see me not using keywords like override, final, public(while inheritance) just to make code compact & consumable(most of the time) in single standard screen size. I also prefer struct instead of class just to save line by not writing "public:" sometimes and also miss , constructor, , prefix std::, deleting dynamic memory, intentionally. I also consider myself a pragmatic person who wants to convey an idea in the simplest way possible rather than the standard way or using Jargons. virtual destructor copy constructor Note: If you stumbled here directly, then I would suggest you go through first, even if it is trivial. I believe it will encourage you to explore more on this topic. What is design pattern? All of this code you encounter in this series of articles are compiled using C++20(though I have used features up to C++17 in most cases). So if you don't have access to the latest compiler you can use which has preinstalled boost library as well. Modern C++ https://wandbox.org/ Intent classes should be open for extension, closed for modification This literally means you should be able to extend a classes behaviour, without modifying it. This might seems weird to you & may raise a question that how can you change the behaviour of a class without modifying it? But there are many answers to this in like , , template, etc. object-oriented design dynamic polymorphism static polymorphism Violating the Open Closed Principle RED, GREEN, BLUE }; SMALL, MEDIUM, LARGE }; m_name;
    COLOR   m_color;
    SIZE    m_size;
}; Items = <Product*>; {
        Items result; ( &i : items) (i->m_color == e_color)
                result.push_back(i); result;
    } {
        Items result; ( &i : items) (i->m_size == e_size)
                result.push_back(i); result;
    } {
        Items result; ( &i : items) (i->m_size == e_size && i->m_color == e_color)
                result.push_back(i); result;
    }
}; { Items all{ Product{ , COLOR::GREEN, SIZE::SMALL}, Product{ , COLOR::GREEN, SIZE::LARGE}, Product{ , COLOR::BLUE, SIZE::LARGE},
    }; ( &p : ProductFilter::by_color(all, COLOR::GREEN)) << p->m_name << ; ( &p : ProductFilter::by_size_and_color(all, SIZE::LARGE, COLOR::GREEN)) << p->m_name << ; EXIT_SUCCESS;
} enum { class COLOR enum { class SIZE { struct Product string using vector # ALL(C)  begin(C), end(C) define { struct ProductFilter Items static by_color (Items items, COLOR e_color) const for auto if return Items static by_size (Items items, SIZE e_size) const for auto if return Items static by_size_and_color (Items items, SIZE e_size, COLOR e_color) const const for auto if return int main () const new "Apple" new "Tree" new "House" for auto cout " is green\n" for auto cout " is green & large\n" return /*
Apple is green
Tree is green
Tree is green & large
*/ So we have a bunch of products & we filtered it by some of its attributes. There is nothing wrong with the above code as far as the requirement is fixed(which will never be the case in software engineering). But just imagine the situations: You already shipped the code to the client. Later on, requirement changes & some new filters are required. In this case, you again need to modify the class & add new filter methods. This is a problematic approach because we have 2 attributes(i.e. color & size) & need to implement 3 function(i.e. color, size & its combination), one more attributes & need to implement 8 functions. You see where this is going.You need to go again & again in the existing implemented code & have to modify it which may break other parts of code as well. This is not a scalable solution. The open-closed principle states that your system should be open to extension but should be closed for modification. Unfortunately what we are doing here is modifying the existing code which is a violation of OCP. Open Closed Principle Example There is more than one way to achieve OCP. Here I am demonstrating the popular one i.e. interface design or abstraction level. So here is our scalable solution: Adding the level of abstraction for extensibility < T> ~Specification() = ; = ;
}; Specification<Product> {
    COLOR e_color;
    ColorSpecification(COLOR e_color) : e_color(e_color) {} { item->m_color == e_color; }
}; Specification<Product> {
    SIZE e_size;
    SizeSpecification(SIZE e_size) : e_size(e_size) {} { item->m_size == e_size; }
}; < T> <T *> filter( <T *> items, Specification<T> &spec) = ;
}; Filter<Product> { <Product *> filter( <Product *> items, Specification<Product> &spec) { <Product *> result; ( &p : items) (spec.is_satisfied(p))
                result.push_back(p); result;
    }
}; BetterFilter bf; ( &x : bf.filter(all, ColorSpecification(COLOR::GREEN))) << x->m_name << ; template typename { struct Specification virtual default virtual bool is_satisfied (T *item) const 0 : struct ColorSpecification bool is_satisfied (Product *item) const return : struct SizeSpecification bool is_satisfied (Product *item) const return template typename { struct Filter virtual vector vector const 0 : struct BetterFilter vector vector const vector for auto if return // ------------------------------------------------------------------------------------------------ for auto cout " is green\n" As you can see we do not have to modify filter method of BetterFilter. It can work with all kind of specification now. For two or more combined specifications < T> Specification<T> { Specification<T> &first; Specification<T> &second;

    AndSpecification( Specification<T> &first, Specification<T> &second)
    : first(first), second(second) {} { first.is_satisfied(item) && second.is_satisfied(item); 
    }
}; < T>
AndSpecification<T> &&( Specification<T> &first, Specification<T> &second) { {first, second};
} green_things = ColorSpecification{COLOR::GREEN}; large_things = SizeSpecification{SIZE::LARGE};

BetterFilter bf; ( &x : bf.filter(all, green_things &&large_things)) << x->m_name << ; template typename : struct AndSpecification const const const const bool is_satisfied (T *item) const return template typename operator const const return // ----------------------------------------------------------------------------------------------------- auto auto for auto cout " is green and large\n" // warning: the following will compile but will NOT work // auto spec2 = SizeSpecification{SIZE::LARGE} && //              ColorSpecification{COLOR::BLUE}; SizeSpecification{SIZE::LARGE} && ColorSpecification{COLOR::BLUE} will not work. Experienced C++ eyes can easily recognize the reason. Though temporary object creation is a hint here.  If you do so, you may get the error of as follows: pure virtual function pure method called
terminate called without an active exception
The terminal process terminated with code: virtual exit 3 For more than two specifications, you can use a variadic template. Benefits of Open Closed Principle => Extensibility "When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with 'bad' design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way. It says that you should design modules that never change. When requirements change, you extend the behaviour of such modules by adding new code, not by changing old code that already works." — Robert Martin => Maintainability The main benefit of this approach is that an interface introduces an additional level of abstraction which enables loose coupling. The implementations of an interface are independent of each other and don’t need to share any code. Thus, you can easily cope-up with client's keep changing requirements. Very useful in agile methodologies. => Flexibility The open-closed principle also applies to plugin and middleware architecture. In that case, your base software entity is your application core functionality. In the case of plugins, you have a base or core module that can be plugged with new features & functionality through a common gateway interface. A good example of this is web browser extensions. Binary compatibility will also be in-tact in subsequent releases. Yardstick to Craft Open Closed Principle Friendly Software In the SRP, you make a judgement about decomposition and where to draw encapsulation boundaries in your code. In the OCP, you make a judgement about what in your module you will make abstract and leave to your module’s consumers to make concrete, and what concrete functionality to provide yourself. There are many design patterns that help us to extend code without changing it. For instance, the helps us to follow Open Close principle. Also, the , or the might be used to design an application easy to change with minimum changes in the existing code. Decorator pattern Factory Method Strategy pattern Observer pattern Conclusion Keep in mind that classes can never be completely closed. There will always be unforeseen changes which require a class to be modified. However, if changes can be foreseen, such as seen above i.e. filters, then you have a perfect opportunity to apply the OCP to be future-ready when those change requests come rolling in. Have Any Suggestions, Query or Wants to Say Hi? 🖱️ Take the Pressure Off, You Are Just a Click Away. Previously published at http://www.vishalchovatiya.com/open-closed-principle-in-cpp-solid-as-a-rock/

Open Closed Principle: SOLID as a Rock

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

7 Advanced C++ Concepts You Should Know

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

10 Expert Tips for Improving Code Reviews: A Guide for Developers

10 Coding Hacks to Remember in 2023

7 Advanced C++ Concepts You Should Know

100 Pieces of Programming Advice from the Book Clean Code by Robert Martin

10 Ways to Prevent and Manage Technical Debt—Tips from Developers

10 Expert Tips for Improving Code Reviews: A Guide for Developers

10 Coding Hacks to Remember in 2023

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps