{"id":4948,"date":"2018-11-19T22:24:34","date_gmt":"2018-11-19T21:24:34","guid":{"rendered":"https:\/\/monodes.com\/predaelli\/?p=4948"},"modified":"2018-11-19T13:26:48","modified_gmt":"2018-11-19T12:26:48","slug":"maintainable-code-and-the-open-closed-principle-severin-perez-medium","status":"publish","type":"post","link":"https:\/\/monodes.com\/predaelli\/2018\/11\/19\/maintainable-code-and-the-open-closed-principle-severin-perez-medium\/","title":{"rendered":"Maintainable Code and the Open-Closed Principle \u2013 Severin Perez \u2013 Medium"},"content":{"rendered":"

\"\"<\/a><\/p>\n

A Look at the Open-Closed Principle in JavaScript<\/p><\/blockquote>\n

Maintainable Code and the Open-Closed Principle \u2013 Severin Perez \u2013 Medium<\/a><\/em><\/p>\n

Oh, another interesting article that tries to educate the “unliterate” JavaScript masses about the basic principle behind Eiffel…..<\/p>\n

<\/p>\n

\n
\n

Maintainable Code and the Open-Closed Principle<\/h1>\n

Abstraction and the Open-Closed Principle in JavaScript<\/h2>\n<\/div>\n
\n
\n
\n
<\/div>\n
<\/div>\n<\/div>\n<\/figure>\n<\/div>\n
\n
\n
\n
\n
\n
<\/div>\n<\/div>
Photo by Alex Holyoake<\/a> on\u00a0Unsplash<\/a><\/figcaption><\/figure>\n<\/div>\n
\n

In<\/span> part 1<\/a> of the SOLID series, we learned about how to write more flexible code with the Single Responsibility Principle (SRP). By isolating pieces of functionality in individual classes\/modules the SRP helps us guard against unnecessarily coupling responsibilities. If the implementation of one responsibility changes, SRP-adherent design prevents the change from affecting other responsibilities. However, decoupling responsibilities does not necessarily mean a complete decoupling of classes\/modules, functions, objects, etc. In most object-oriented code, different objects must deal with one another in some fashion. What then happens when a particular object needs to be changed? As with responsibility changes, this poses a challenge for the maintenance of downstream objects that could inadvertently be affected by the change. One way to reduce the impact of this challenge is to adhere to the second of the SOLID principles: the Open-Closed Principle (OCP)<\/em>.<\/p>\n

In this post, we\u2019re going to explore the OCP and how to put it into practice. In a slight departure from many discussions on the OCP, we\u2019re going to conduct our exploration in JavaScript\u200a\u2014\u200aa language not often associated with classical OCP tools such as interfaces. However, JavaScript code is as deserving of SOLID adherence as any other code, so let\u2019s give it a shot!<\/p>\n<\/div>\n<\/div>\n<\/section>\n

\n
\n
\n<\/div>\n
\n
\n

A Quick Refresher on\u00a0SOLID<\/strong><\/h4>\n

SOLID is an acronym for a set of five software development principles, which if followed, are intended to help developers create flexible and clean code. The five principles are:<\/p>\n

    \n
  1. \n
      \n
    1. The S<\/strong>ingle Responsibility Principle<\/a>\u200a\u2014\u200aClasses should have a single responsibility and thus only a single reason to change.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
        \n
      1. \n
          \n
        1. The O<\/strong>pen\/Closed Principle\u200a\u2014\u200aClasses and other entities should be open for extension but closed for modification.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
            \n
          1. \n
              \n
            1. The L<\/strong>iskov Substitution Principle<\/a>\u200a\u2014\u200aObjects should be replaceable by their subtypes.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                \n
              1. \n
                  \n
                1. The I<\/strong>nterface Segregation Principle<\/a>\u200a\u2014\u200aInterfaces should be client specific rather than general.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
                    \n
                  1. The D<\/strong>ependency Inversion Principle<\/a>\u200a\u2014\u200aDepend on abstractions rather than concretions.<\/li>\n<\/ol>\n<\/div>\n<\/div>\n<\/section>\n
                    \n
                    \n
                    \n<\/div>\n
                    \n
                    \n

                    The Open Closed Principle<\/strong><\/h4>\n

                    Robert C. Martin, creator and chief evangelist of SOLID, credits Bertrand Meyer as the originator of the OCP. In his 1988 book Object Oriented Software Construction<\/em>, Meyer describes the need to develop flexible systems that can adapt to change without breaking. To do this, Meyer advocates the design of systems where entities (classes, modules, functions, etc) are \u201copen for extension, but closed for modification\u201d. In his development of the SOLID principles, Martin runs with this idea, describing it as a \u201cstraightforward\u201d attack against the threat of \u201cfragile, rigid, unpredictable and un-reusable\u201d code [1]. For his part, Martin breaks down the OCP into its two constituent parts, defining code that is \u201copen for extension\u201d as code to which you can add new behavior, and code that is \u201cclosed for modification\u201d as code that is \u201cinviolate\u201d in that it\u2019s design should never be changed once implemented. In other words, the OCP says that you can always add new code<\/em> to an object, but should never change the design of old code<\/em>.<\/p>\n

                    The chief benefit of the OCP is maintainability. If you adhere to the OCP you can greatly decrease future maintenance costs. The opposite applies as well\u200a\u2014\u200awhen you don\u2019t adhere to the OCP, future maintenance costs will be greater. Consider how the coupling of two entities affects their respective maintainability. The more a given entity knows about how another one is implemented, the more we can say that they are coupled. Therefore, if one of the two entities is changed, then the other must be changed too. Here is a simple example:<\/p>\n

                    \n
                    \n
                    <\/div>\n
                    <\/div>\n<\/div>\n<\/figure>\n<\/div>\n<\/div>\n<\/section>\n
                    \n
                    \n
                    \n