The Open Closed Principle of SOLID Principle
SOLID principles are like the backbone of OOP, I've gone through with this and obtained a good understanding of this and I thought to share it so that anyone can understand this principle at MAX.
Here is the list of SOLID principles.
SRP
The Single Responsibility Principle
A class should have one, and only one, reason to change.
OCP
You should be able to extend a classes behavior, without modifying it.
LSP
The Liskov Substitution Principle
Derived classes must be substitutable for their base classes.
ISP
The Interface Segregation Principle
Make fine grained interfaces that are client specific.
DIP
The Dependency Inversion Principle
Depend on abstractions, not on concretions.
Today I am hilighting the Open Closed Principle of SOLID.
Software entities should be open for extension, but closed for modification: Robert Martin
The preceding statement may be a bit confusiing to understand for those who are not very familiar with these principles.
Open for Extension: A class should be open for extension only (for example a derived class or subclasses).
Closed for modification: A class shouldn't be open of modification (for example we should not add code on demand whenever required).
One thing is sure in all software development, most software changes during its life cycle. So, it requires assurance that developers design software that is stable.
For example, let's say you are creating a class to represent an Export. The Export class will export the information/dataset to the desired format like a list of employees and related information to a CSV and text format on behalf of the specified provider. The following sample example is for illustrative purposes only:
Now everything looks great. Suppose we come up with one more desired export format. Then at development time it will look like this that is connected with an OLEDB connection:1: public enum ProviderName2: {3: SQlServer4: }5: class Export6: {7: public bool ExportFileToDesiredFormat(Provider objProvider)8: {9: if (objProvider == ProviderName.SQlServer)10: {11: //Export to CSV,text,.pdf format code segment which depands on provider12: return true;13: }14: return true;15: }16: }
Here if you can see from the code above, we are modifying the class Export rather than extending, in other words whenever we add a new export format then we are modifying the existing class that violates the OCP.1: public enum ProviderName2: {3: SQlServer,4: OLEDB,5: Oracle6: }7:8: class Export9: {10: public bool ExportFileToDesiredFormat(string objProvider)11: {12: if (objProvider == ProviderName.SQlServer.ToString())13: {14: //Export to CSV,text,.pdf format code segment which depands on provider15: return true;16: }17: else if (objProvider == ProviderName.OLEDB.ToString())18: {19: //Export to CSV,text,.pdf format code segment which depands on provider20: return true;21: }22: else if (objProvider == ProviderName.Oracle.ToString())23: {24: //Export to CSV,text,.pdf format code segment which depands on provider25: return true;26: }27: else28: { }29: return true;30: }31: }
It's time to remember OCP: entities should be open for extension and closed for modification.
Here is the code segment after considering OCP in mind. The sample example is for illustrative purposes only.
The main method will look like:1: interface IProvider2: {3: bool connect(string objProviderName);4: }5:6: class ExportFileFromSQLProvider : IProvider7: {8: public bool connect(string objProviderName)9: {10: //write code on behalf of provider to get connect with SQLProvider and export dataset to desired format such as .csv,.pdf,.text11: return true;12: }13: }14:15: class ExportFileFromOLEDBProvider : IProvider16: {17: public bool connect(string objProviderName)18: {19: //write code on behalf of provide to get connect with OLEDBProvider and export dataset to desired format such as .csv,.pdf,.text20: return true;21: }22: }23:24: class ExportFileFromOracleProvider : IProvider25: {26: public bool connect(string objProviderName)27: {28: //write code on behalf of provide to get connect with OracleProvider and export dataset to desired format such as .csv,.pdf,.text29: return true;30: }31: }32:33:
1: class Program2: {3: static void Main(string[] args)4: {5: IProvider objSQLIProvider = new ExportFileFromSQLProvider();6: bool sucess = objSQLIProvider.connect("sqlprovider");7: IProvider objOLEDBIProvider = new ExportFileFromOLEDBProvider();8: bool result = objOLEDBIProvider.connect("OLEDBProvider");9: }10: }
Using this approach we can add as many ProviderName to export a file as needed. Thus the IProvider interface implements the idea of open for extension but closed for modifications.
It's very easy to understand, especially for those who are not familiar with this principle. Hope you enjoyed this demonstration.
Enjoy Coding and Have wonderful day ahead
To know more MVC and WebApi Kindly go through with these links
MVC Articles & WCF and WebApi
Thanks.
Enjoy coding and reading.