Open/Closed principle is never 100% closed

At the outset, I used to write programs that just work because, I had to complete and deliver the project on time.</p>

I remember, when was assigned a task to create web application that will create New Enrollment request on a given account number. After slogging the whole day, writing code and proper testing, I created one small application that was allowing user to upload an Excel Sheet consisting of list of Account Number. This application iterates through each account number validates and creates one New Enrollment Request on each account. If it fails then moves to create request on next account number without breaking the execution. Application worked splendidly and my manager became happy that I did the job on time and application was working fine... J

As software programmer, you might know that software project never becomes perfect and client requirement never ends. Same thing happened to me and on the next day, my Manager again came and asked to update the application so that it will also create Account Maintenance Request. I worked for that, done changes throughout the application, put everywhere if else condition needed to check the new account maintenance request type, and finally gave him the application. It worked good... But my manager’s expectations never stopped...

In my project work story the pain part was…, for every new requirement in project, I had to change each and every page, class and doing that repetitively made my code much confusing and disordering.

Then I read about the Open/Closed Principle (OCP) of Object oriented programming. This principle states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. What I understood from this principle that software application should be designed such that, if eventually new requirements comes up then project should not allow any changes and it can only be extended.

I planned to re-create my application in such a way that it fits with the idea of Open/Closed Principle. Therefore, implemented Factory Pattern to make project more object-oriented. Converted each request as an object, created one base abstract class (BaseRequest)having one abstract method like CreateRequest inherited by an Interface (IRequest) hence followed Template pattern as well. Created New Enrollment and Account Maintenance classes inherited form the BaseRequest class and implemented the CreateRequest method in each request class. Created one Factory class that returns the required request Object based on the request type and made its return type the interface IRequest that was pointing to the real request concrete object hence maintained the loose coupling architecture.

After doing all above mentioned stuffs, project became more object-oriented and loosely coupled architecture by adhering to the precepts of OCP and factory design pattern. Now, life became little easy, say if some new requirement comes up in future for adding one new request type say "withdrawal request" in project then I just have to introduce one new "withdrawal" request class inheriting with the BaseRequest class, implanting the create request method. Changed the Factory class to return withdrawal request object based on some logical condition. That’s it, my work is done and project is ready. Project became more extendable and less changeable, that is very close to the precepts of Open/Close principle.

After redesigning project, comparatively it required fewer changes and efforts to implement new requirements. However, you can see although after implementing the open closed principle and factory design pattern, I had to change the code in Factory class to handle the new Request added in application. That code modification in factory class was compulsory and it could not be avoided.

I read all design patterns, analyzed my project requirement and made best attempts to make an architecture that will never allow any changes in project under any circumstances for implementing new requirement but, failed.

In order to implement new requirements in existing software project, changes have to be done. However, software architecture should be such that it should allow fewer changes and more flexible to extend.

The moral of the story is obvious that there exist no software program that is 100 % closed for changes and 100% adheres to the Open/Closed Principle.</font>