{"id":1060,"date":"2015-05-24T11:09:36","date_gmt":"2015-05-24T15:09:36","guid":{"rendered":"http:\/\/springframework.guru\/?p=1060"},"modified":"2019-06-02T12:30:15","modified_gmt":"2019-06-02T16:30:15","slug":"open-closed-principle","status":"publish","type":"page","link":"https:\/\/springframework.guru\/principles-of-object-oriented-design\/open-closed-principle\/","title":{"rendered":"Open Closed Principle"},"content":{"rendered":"

Open Closed Principle<\/h1>\n

As applications evolve, changes are required. Changes are required when new functionality is added or existing functionality is updated in the application. Often in both situations, you need to modify the existing code, and that carries the risk of breaking the application’s functionality. For good application design and the code writing part, you should avoid change in the existing code when requirements change. Instead, you should extend the existing functionality by adding new code to meet the new requirements. You can achieve this by following the Open Closed Principle.<\/p>\n

The Open Closed Principle represents the “O” of the five SOLID<\/a> software engineering principles to write well-designed code that is more readable, maintainable, and easier to upgrade and modify. Bertrand Meyer<\/a> coined the term Open Closed Principle, which first appeared in his book Object-Oriented Software Construction<\/a>, release in 1988. This was about eight years before the initial release of Java.<\/p>\n

This principle states: “software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification<\/em> “. Let\u2019s zero in on the two key phrases of the statement:<\/p>\n

    \n
  1. “Open for extension<\/em> “: This means that the behavior of a software module, say a class can be extended to make it behave in new and different ways. It is important to note here that the term “extended<\/em> ” is not limited to inheritance using the Java extend<\/code> keyword. As mentioned earlier, Java did not exist at that time. What it means here is that a module should provide extension points to alter its behavior. One way is to make use of polymorphism<\/a> to invoke extended behaviors of an object at run time.<\/li>\n
  2. “Closed for modification<\/em> “: This means that the source code of such a module remains unchanged.<\/li>\n<\/ol>\n

    It might initially appear that the phrases are conflicting- How can we change the behavior of a module without making changes to it? The answer in Java is abstraction. You can create abstractions (Java interfaces and abstract classes) that are fixed and yet represent an unbounded group of possible behaviors through concrete subclasses.<\/p>\n

    Before we write code which\u00a0follows the Open\u00a0Closed Principle, let\u2019s look at\u00a0the consequences of violating the Open Closed principle.<\/p>\n

    Open Closed Principle Violation (Bad Example)<\/h2>\n

    Consider an insurance system that validates health insurance claims before approving one. We can follow the complementary Single Responsibility Principle<\/a> to model this requirement by creating two separate classes. A HealthInsuranceSurveyor<\/code> class responsible to validate claims and a ClaimApprovalManager<\/code> class responsible to approve claims.<\/p>\n

    HealthInsuranceSurveyor.java<\/h4>\n
    package guru.springframework.blog.openclosedprinciple;\r\n\r\npublic class HealthInsuranceSurveyor{\r\n\r\n    public boolean isValidClaim(){\r\n        System.out.println(\"HealthInsuranceSurveyor: Validating health insurance claim...\");\r\n        \/*Logic to validate health insurance claims*\/\r\n        return true;\r\n    }\r\n}\r\n<\/pre>\n
    ClaimApprovalManager.java<\/h4>\n
    package guru.springframework.blog.openclosedprinciple;\r\n\r\npublic class ClaimApprovalManager {\r\n\r\n    public void processHealthClaim (HealthInsuranceSurveyor surveyor)\r\n    {\r\n        if(surveyor.isValidClaim()){\r\n            System.out.println(\"ClaimApprovalManager: Valid claim. Currently processing claim for approval....\");\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
    Both the HealthInsuranceSurveyor<\/code> and ClaimApprovalManager<\/code> classes work fine and the design for the insurance system appears perfect until a new requirement to process vehicle insurance claims arises. We now need to include a new VehicleInsuranceSurveyor<\/code> class, and this should not create any problems. But, what we also need is to modify the ClaimApprovalManager<\/code> class to process vehicle insurance claims. This is how the modified ClaimApprovalManager<\/code> will be:<\/p>\n
    Modified ClaimApprovalManager.java<\/h4>\n
    package guru.springframework.blog.openclosedprinciple;\r\n\r\npublic class ClaimApprovalManager {\r\n\r\n    public void processHealthClaim (HealthInsuranceSurveyor surveyor)\r\n    {\r\n        if(surveyor.isValidClaim()){\r\n            System.out.println(\"ClaimApprovalManager: Valid claim. Currently processing claim for approval....\");\r\n        }\r\n    }\r\n\r\n    public void processVehicleClaim (VehicleInsuranceSurveyor surveyor)\r\n    {\r\n        if(surveyor.isValidClaim()){\r\n            System.out.println(\"ClaimApprovalManager: Valid claim. Currently processing claim for approval....\");\r\n        }\r\n    }\r\n}\r\n<\/pre>\n
    In the example above, we modified the ClaimApprovalManager<\/code> class by adding a new processVehicleClaim()<\/code> method to incorporate a new functionality (claim approval of vehicle insurance).<\/p>\n
    As apparent, this is a clear violation of the Open\u00a0Closed Principle. We need to modify the class to add support for a new functionality. In fact, we violated the Open Closed Principle at the very first instance we wrote the ClaimApprovalManager<\/code> class. This may appear innocuous in the current example, but consider the consequences in an enterprise application that needs to keep pace with fast changing business demands. For each change, you need to modify, test, and deploy the entire application. That not only makes the application fragile and expensive to extend but also makes it prone to software bugs.<\/p>\n
    Coding to the Open\u00a0Closed Principle<\/h2>\n
    The ideal approach for the insurance claim example would have been to design the ClaimApprovalManager<\/code> class in a way that it remains:<\/p>\n