{"id":1519,"date":"2021-03-06T06:54:48","date_gmt":"2021-03-06T05:54:48","guid":{"rendered":"http:\/\/mateuszglowinski.pl\/?p=1519"},"modified":"2021-03-06T15:46:50","modified_gmt":"2021-03-06T14:46:50","slug":"open-closed-principle","status":"publish","type":"post","link":"https:\/\/mateuszglowinski.pl\/index.php\/2021\/03\/06\/open-closed-principle\/","title":{"rendered":"Open\/Closed Principle"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

What is „Open\/Closed Principle” (OCP) ?<\/h4>

It is the second rule of the SOLID design rules (it stands for O in SOLID acronym).<\/span><\/span><\/p>

Definition<\/h4>
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.<\/div><\/div>
\u00a0<\/div>
\u00a0\u00a0\u00a0\u00a0 Mayer Bertrand<\/div><\/div><\/blockquote>

It means that if user would ask for a change in the program, you as a programmer should not modify already existing classes, but you should extend existing application only by adding a new classes and functionalities.<\/p>

This goal is often achieved by dividing the system into components and preparing a hierarchy of their dependencies that would protect high-level components from changes made to low-level components.<\/span><\/span><\/p>

Real-life example<\/h4>

Let’s say we have an vet application that check health of animals.<\/p>

public class Launcher {\n\n    public static void main(String[] args){\n        Vet vet = new Vet();\n\n        Object[] animals = {new Dog(), new Cat()};\n\n        vet.checkPetsHealth(animals);\n    }\n\n}\n<\/pre>
public class Dog {\n    public void checkHealth() {\n        System.out.println(\"Checking dog health\");\n    }\n}\n<\/pre>
public class Cat {\n    public void checkHealth() {\n        System.out.println(\"Checking cat health\");\n    }\n}\n<\/pre>
public class Vet {\n    public void checkPetsHealth(Object[] animals) {\n        for (Object animal : animals) {\n            if (animal instanceof Dog) {\n                Dog dog = (Dog) animal;\n                dog.checkHealth();\n            } else if (animal instanceof Cat) {\n                Cat cat = (Cat) animal;\n                cat.checkHealth();\n            }\n        }\n    }\n}\n<\/pre>
UML diagram of our application:<\/p>
\"\"<\/p>
After some time out vet decided to expand business and check the health of hamsters as well.<\/span><\/span><\/p>
public class Hamster {\n    public void checkHealth() {\n        System.out.println(\"Checking hamster health\");\n    }\n}\n<\/pre>
public class Vet {\n    public void checkPetsHealth(Object[] animals) {\n        for (Object animal : animals) {\n            if (animal instanceof Dog) {\n                Dog dog = (Dog) animal;\n                dog.checkHealth();\n            } else if (animal instanceof Cat) {\n                Cat cat = (Cat) animal;\n                cat.checkHealth();\n            } else if (animal instanceof Hamster) {\n                Hamster hamster = (Hamster) animal;\n                hamster.checkHealth();\n            }\n        }\n    }\n}\n<\/pre>
It became clear, that it is impossible to extend functionality without modifying Vet<\/em> class, due to that application at this moment does not meet OCP<\/em> rule.<\/p>
Let’s refactor the code according to OCP rule. In this case, polymorphism<\/a> might be helpful. We should start with adding interface for all animal „clients”.<\/p>
public interface Animal {\n    void checkHealth();\n}\n<\/pre>
public class Dog implements Animal {\n    public void checkHealth() {\n        System.out.println(\"Checking dog health\");\n    }\n}\n<\/pre>
public class Cat implements Animal {\n    public void checkHealth() {\n        System.out.println(\"Checking cat health\");\n    }\n}\n<\/pre>
public class Hamster implements Animal {\n    public void checkHealth() {\n        System.out.println(\"Checking hamster health\");\n    }\n}\n<\/pre>
Thanks to that, we don’t need to check for a instance type in Vet class and therefore no modification is needed anymore in case of extending functionality.<\/p>
public class Vet {\n    public void checkPetsHealth(Animal[] animals) {\n        for (Animal animal : animals) {\n            animal.checkHealth();\n        }\n    }\n}\n<\/pre>
UML diagram of our application after refactoring:<\/p>
\"\"<\/p>
Why should I follow „Open\/Closed Principle” ?<\/h4>
This rule helps to maintain the code, which is easy to extend and friendly for new features.<\/p><\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"
What is „Open\/Closed Principle” (OCP) ? It is the second rule of the SOLID design rules (it stands for O in SOLID acronym). Definition Software…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[34],"tags":[35],"_links":{"self":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1519"}],"collection":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/comments?post=1519"}],"version-history":[{"count":73,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1519\/revisions"}],"predecessor-version":[{"id":1778,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1519\/revisions\/1778"}],"wp:attachment":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/media?parent=1519"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/categories?post=1519"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/tags?post=1519"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}