{"id":717,"date":"2021-03-22T12:32:26","date_gmt":"2021-03-22T16:32:26","guid":{"rendered":"https:\/\/www.alpharithms.com\/?p=717"},"modified":"2021-07-27T11:20:38","modified_gmt":"2021-07-27T15:20:38","slug":"open-closed-principle-ocp-solid","status":"publish","type":"post","link":"https:\/\/www.alpharithms.com\/open-closed-principle-ocp-solid-263212\/","title":{"rendered":"Open\/Closed Principle (OCP): Designing for Extensibility Over Modification"},"content":{"rendered":"

The Open\/Closed Principle (OCP) is the second principle of SOLID object-oriented design patterns outlined by Robert C. Martin (a.k.a. Uncle Bob) in his 2002 Agile Software Development, Principles, Patterns, and Practices<\/em>. It states that software entities should be “open for extension but closed for modification.” (1)<\/p>\n

The Open\/Closed Principle<\/strong> provides a conceptual basis for maintaining flexibility as software evolves and grows. This means focusing on extensibility over modification<\/strong>. More concretely,\u00a0extensible<\/em> software entities are designed such that additional functionality can be added without requiring\u00a0modification<\/em> to other interrelated entities.<\/p>\n

Non-Breaking Changes<\/h2>\n

As with many design principles, the OCP has a strong focus on abstraction. Particularly, the OCP is often achieved by using abstract base classes to factor out implementation specifics. Common code smells<\/a> like identically-named methods among multiple classes often signify opportunities where implementing the OCP may be beneficial.<\/p>\n

This approach allows extended<\/em> functionality via concrete implementation classes without necessitating changes to base classes. In other words, a developer can add new functionality without changing the existing code <\/strong>of related functions, classes, and methods!<\/p>\n

Example of OCP Violation<\/h2>\n

To exemplify the OCP, let us again consider a hypothetical stock trading application, continuing from the examples in the article about the Single Responsibility Principle (SRP)<\/a> of SOLID design.<\/p>\n

Previously, this example provided a single Buy and Sell as part of its Transaction class. This time, we’ll incorporate functionality to make a record of Buy<\/code> and Sell<\/code> transactions. After all, one needs something to show come tax season!<\/p>\n

class Transaction {\r\n    \r\n    private void buy(String ticker, int quantity, float price){\r\n        Buy.execute(ticker, quantity, price);\r\n    }\r\n    private void sell(String ticker, int quantity, float price){\r\n        Sell.execute(ticker, quantity, price);\r\n    }\r\n}\r\n\r\nclass Buy{\r\n\r\n    \/\/ Create a record of the Buy transaction\r\n    public static String makeRecord(String ticker, int quantity, float price, String date){\r\n\r\n        \/\/ Create a string containing relevant Buy metadata\r\n        return MessageFormat.format(\"{0}-{1}-{2}-{3}\",\r\n                ticker, String.valueOf(quantity),String.valueOf(price),date);\r\n    }\r\n\r\n    \/\/ Class-specific Buy logic\r\n    static void execute(String stock, int quantity, float price){\r\n        \/\/ Execute buy action here\r\n    }\r\n\r\n}\r\n\r\nclass Sell{\r\n\r\n    \/\/ Create a record of the Buy transaction\r\n    public static String makeRecord(String ticker, int quantity, float price, String date){\r\n\r\n        \/\/ Create a string containing relevant Buy metadata\r\n        return MessageFormat.format(\"{0}-{1}-{2}-{3}\",\r\n                ticker, String.valueOf(quantity),String.valueOf(price),date);\r\n    }\r\n\r\n    \/\/ Class-specific Sell logic\r\n    static void execute(String stock, int quantity, float price){\r\n        \/\/ Execute buy action here\r\n    }\r\n}<\/pre>\n
Notice that the Buy and Sell classes each implement their own version of the makeRecord<\/code> method. My nose recoils when copy\/pasting blocks of code such as this, signifying potential code smell.<\/p>\n
The design of this code violates the Open\/Closed principle because anytime a record format needs to be adjusted it requires a change in both the Buy<\/code> and Sell<\/code> class. In other words, a single\u00a0extension<\/em> requires multiple\u00a0modifications<\/em>.<\/p>\n
Example of OCP Adherence<\/h2>\n
One possible approach to approving the above code, with the Open\/Closed Principle<\/strong> in mind, is to use inheritance<\/em>. This dictates that child classes, inheriting from a parent class, should share similar functionality.<\/p>\n
This approach allows the Buy<\/code> and Sell<\/code> methods to share a common method<\/strong> to create records of transactions. This allows the functionality of making records to be extended without requiring modification of either Buy or Sell. They just call the inherited makeRecord<\/code> method!<\/p>\n
class RecordableTransaction {\r\n\r\n    \/\/ Create a record, in a format used by all inherited classes\r\n    public static String makeRecord(String ticker, int quantity, float price, String date){\r\n\r\n        \/\/ Create a string containing relevant Buy metadata\r\n        return MessageFormat.format(\"{0}-{1}-{2}-{3}\",\r\n                ticker, String.valueOf(quantity),String.valueOf(price),date);\r\n    }\r\n}\r\n\r\nclass Transaction {\r\n    \r\n    \/\/ Still uses Buy class to execute buy transactions\r\n    private void buy(String ticker, int quantity, float price){\r\n        Buy.execute(ticker, quantity, price);\r\n    }\r\n\r\n    \/\/ Still uses the Sell class to execute sell transactions\r\n    private void sell(String ticker, int quantity, float price){\r\n        Sell.execute(ticker, quantity, price);\r\n    }\r\n}\r\n\r\nclass Buy extends RecordableTransaction{\r\n\r\n    \/\/ Class-specific Buy logic still implemented here\r\n    static void execute(String stock, int quantity, float price){\r\n        \/\/ Execute buy action here\r\n    }\r\n\r\n}\r\n\r\nclass Sell extends RecordableTransaction{\r\n\r\n    \/\/ Class-specific Sell logic still implemented here\r\n    static void execute(String stock, int quantity, float price){\r\n        \/\/ Execute sell action here\r\n    }\r\n}<\/pre>\n
This version approaches the design by using a new Parent class named RecordableTransaction<\/code> that defines a makeRecord<\/code> method. The Buy<\/code> and Sell<\/code> classes, now children of the RecordableTransaction<\/code> class, both share the makeRecord<\/code> method and its implementation. The Open\/Closed Principle UML diagram example below provides a visual of what is going on here:<\/p>\n
\"open<\/a>
Inheriting from the RecordableTransaction class allows extension of the makeRecord method without requiring modification among any child classes such as Buy or Sell<\/figcaption><\/figure>\n
This is one of many approaches to abstract common functionality in the hypothetical stock trading application. For another example, check out Joel Abrahamsson’s implementation of the Open\/Closed Principle’s prototypical Shape example<\/a>.<\/p>\n
Final Thoughts<\/h2>\n
The SOLID framework for better object-oriented design has stood apart from other more transient models throughout the years. Its AGILE approach to designing better code helps avoid common mistakes that prevent software from being flexible, easily maintainable, and scalable.<\/p>\n
The Open\/Closed Principle is but one of the five class\/module principles. Its guidance for class-based designs focused on ease-of-extensibility is revered among engineers, programmers, and hobbyist coders alike. Yes\u2014you have to put on your thinking cap initially to understand its conceptual approach. Yes\u2014it takes more time to implement. And Yes\u2014sometimes the extra time is warranted for small-scale applications or rapid-prototyping.<\/p>\n
As a closing thought, I will argue that even when implementing the OCP is not warranted one will still benefit from being aware of its potential<\/em> use in development.<\/p>\n
References<\/h2>\n
    \n
  1. Martin, Robert C.\u00a0Agile Software Development, Principles, Patterns, and Practices<\/i>. 1st ed., Pearson, 2002.<\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
    The Open\/Closed Principle (OCP) is the second principle of SOLID object-oriented design patterns outlined by Robert C. Martin (a.k.a. Uncle Bob) in his 2002 Agile Software Development, Principles, Patterns, and Practices. It states that software entities should be “open for extension but closed for modification.” (1) The Open\/Closed Principle provides a conceptual basis for maintaining […]<\/p>\n","protected":false},"author":2,"featured_media":718,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[246,260],"tags":[169,298,303,272,293,299],"acf":[],"_links":{"self":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/717"}],"collection":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/comments?post=717"}],"version-history":[{"count":4,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/717\/revisions"}],"predecessor-version":[{"id":725,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/posts\/717\/revisions\/725"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media\/718"}],"wp:attachment":[{"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/media?parent=717"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/categories?post=717"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.alpharithms.com\/wp-json\/wp\/v2\/tags?post=717"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}