Hold on!!! Before this please read the common design principle post.
Most of us are bit lazy to read things, so I thought of posting the things that I got form it. This is like the cream of what I got.
I'll start it with the S.O.L.I.D design principles:
The term S.O.L.I.D. comes from the initial letter of each of the five principles that were collected in the book Agile Principles, Patterns, and Practices in C# by Robert C. Martin, or Uncle Bob to his friends. Simply this is a collection of best practices for object-oriented design.
Following will explain all the principles:
Single Responsibility Principle (SRP)
This principle is closely aligned with a common design principle called Separation of Concerns. It says that every object should have one reason to change and single focus of responsibility. By applying this principle, you avoid the problem of monolithic class design. At the same time this principle gives readability and maintenance for a system.
Open-Closed Principle (OCP)
This principle says that classes should be open for extension and closed for modification, in that you should be able to add features and extend a class without it changing its internal behavior. In other words it avoids the possibilities of braking the system.
Liskov Substitution Principe (LSP)
The LSP says that you should be able to use any derived class in place of a base class and have it behave in the same manner without modification. In other words derived classes must be substitutable for their base classes.
Interface Segregation Principle (ISP)
The ISP is all about splitting the methods of a contract into groups of responsibility and assigning
interfaces to these groups to prevent a client from needing to implement one large interface and a host of methods that they do not use. The purpose behind this is so that classes wanting to use the same interfaces only need to implement a specific set of methods as opposed to a monolithic interface of methods.
Dependency Inversion Principle (DIP)
The DIP is all about isolating your classes from concrete implementations and having them depend on abstract classes or interfaces. It promotes the mantra of coding to an interface rather than an implementation, which increases flexibility within a system by ensuring you are not tightly coupled to one implementation.
This is about the S.O.L.I.D design principles. I hope this will you guys on the long way of design someday.
This is the first one of a series of articles. I'll be back with design patterns.
Comments