Definition<\/strong><\/p>\n\n\n\n The Open\/Closed Principle (OCP)<\/strong> states that software entities (such as classes, modules, or functions) should be open for extension but closed for modification<\/strong>.<\/p>\n\n\n\n In other words:<\/p>\n\n\n\n Simply put:<\/p>\n\n\n\n Want to add a new feature? Write new code instead of changing code that already works and has been tested.<\/strong><\/p>\n\n\n\n This means that the behavior of a class can be extended (new capabilities can be added) without having to open it up and modify its existing implementation.<\/p>\n\n\n\n Imagine a multifunctional kitchen appliance.<\/p>\n\n\n\n When you buy it, you get a base unit with a motor and a set of attachments designed for different tasks (a chopping blade, a whisk, etc.).<\/p>\n\n\n\n After some time, you decide that you would like to use the same appliance to juice fruits. You notice that you do not have the appropriate attachment, so you consider grabbing a screwdriver, opening the housing, accessing the motor, removing some screws, and installing new components yourself.<\/p>\n\n\n\n Is this approach safe?<\/p>\n\n\n\n Definitely not. In fact, it is unlikely to work because you could damage the motor and cause the appliance to stop functioning altogether.<\/p>\n\n\n\n If we want to make juice using the same appliance, we simply go to the store and buy the correct attachment that is designed for that purpose and compatible with the appliance’s base unit.<\/p>\n\n\n\n The base of the kitchen appliance is closed for modification<\/strong> (we do not tamper with the motor), but the overall system is open for extension<\/strong> (we can purchase many attachments for different purposes).<\/p>\n\n\n\n Software should work in exactly the same way.<\/p>\n\n\n\n The core mechanism of our application should be like the base of the kitchen appliance\u2014stable and untouched\u2014while new features should be like interchangeable attachments.<\/p>\n\n\n\n Suppose we are building a payment processing system for an online store.<\/p>\n\n\n\n Initially, we support only traditional bank transfers and credit\/debit card payments.<\/p>\n\n\n\n The The problem appears when the business asks us to add a new payment method, such as BLIK or PayPal.<\/p>\n\n\n\n To do that, we must:<\/p>\n\n\n\n Why Is This Bad?<\/strong><\/p>\n\n\n\n The class is open for modification.<\/p>\n\n\n\n Every time we add a new payment method, we modify the same file. While adding BLIK support, we could accidentally introduce a typo or bug that breaks card payments that have been working perfectly for months.<\/p>\n\n\n\n To fix this code, we need to create a universal socket<\/strong> (an interface) and interchangeable attachments<\/strong> (classes implementing specific payment methods).<\/p>\n\n\n\n Create a Universal Socket (Interface)<\/strong><\/p>\n\n\n Create Interchangeable Attachments (Implementations)<\/strong><\/p>\n\n\n Create a Managing Class \u2014 Closed for Modification<\/strong><\/p>\n\n\n Now, if we want to add BLIK payments, we do not touch a single line of code in We simply create a brand-new class:<\/p>\n\n\n The system has been extended, yet no existing code has been modified.<\/p>\n\n\n\n The Open\/Closed Principle has been satisfied.<\/p>\n\n\n\n We do not touch code that is already running in production and generating business value.<\/p>\n\n\n\n This significantly reduces the risk of breaking existing functionality when adding new features.<\/p>\n\n\n\n Testers do not have to re-test the entire payment system.<\/p>\n\n\n\n They only need to test the newly added class (for example, If five developers need to add five different payment methods, each developer can work on their own file.<\/p>\n\n\n\n They do not interfere with one another and create fewer merge conflicts in version control systems such as Git.<\/p>\n\n\n\n Instead of having one enormous method filled with dozens of Apply OCP when:<\/p>\n\n\n\n Design your code as if tomorrow a client might ask for a feature that nobody has thought about today.<\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" Open for Extension, Closed for Modification Definition The Open\/Closed Principle (OCP) states that software entities (such as classes, modules, or functions) should be open for extension but closed for modification. In other words: Simply put: Want to add a new feature? Write new code instead of changing code that already works and has been tested. […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"saved_in_kubio":false,"footnotes":""},"categories":[12],"tags":[],"class_list":["post-410","post","type-post","status-publish","format-standard","hentry","category-solid"],"_links":{"self":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/410","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/comments?post=410"}],"version-history":[{"count":2,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/410\/revisions"}],"predecessor-version":[{"id":413,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/posts\/410\/revisions\/413"}],"wp:attachment":[{"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/media?parent=410"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/categories?post=410"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/patryk-sobilo.profesjonalnyprogramista.pl\/index.php\/wp-json\/wp\/v2\/tags?post=410"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
Real-Life Example: How to Understand It?<\/h4>\n\n\n\n
Example \u2014 OCP Violation<\/h4>\n\n\n\n
PaymentProcessor<\/code> class below violates OCP:<\/p>\n\n\n<\/pre>\n
\u00a0<\/pre>\n
\u00a0<\/pre>\n
\n
PaymentProcessor<\/code> class.<\/li>\n\n\n\nelse if<\/code> block.<\/li>\n<\/ol>\n\n\n\nExample \u2014 OCP-Compliant Design<\/h4>\n\n\n\n
<\/pre>\n
<\/pre>\n
\u00a0<\/pre>\n
\u00a0<\/pre>\n
\u00a0<\/pre>\n
<\/pre>\n
\u00a0<\/pre>\n
What Do We Gain?<\/h4>\n\n\n\n
PaymentProcessor<\/code>.<\/p>\n\n\n\n<\/pre>\n
\u00a0<\/pre>\n
Why Is OCP Important?<\/h4>\n\n\n\n
Peace of Mind and Safety<\/h5>\n\n\n\n
Less Regression Testing<\/h5>\n\n\n\n
BlikPayment<\/code>).<\/p>\n\n\n\nBetter Team Collaboration<\/h5>\n\n\n\n
Cleaner and More Readable Code<\/h5>\n\n\n\n
if-else<\/code> statements, we end up with small, focused, and easy-to-understand classes.<\/p>\n\n\n\nWhen Should You Apply OCP?<\/h4>\n\n\n\n
\n
if-else<\/code> or switch<\/code> statements that check an object’s “type” and make decisions based on it;<\/li>\n\n\n\n