Introduction
SOLID principles design mode, respectively, a single principle, the principle of opening and closing, Richter substitution principle, the interface segregation principle, Dependency Inversion Principle. Predecessors summed up, follow the five principles of the program can be resolved tightly coupled, more robust.
| SICKLE | Single Responsibility Principle |
| OCP | Open Closed Principle |
| LSP | Richter substitution principle |
| ISP | Interface Segregation Principle |
| DIP | Dependency Inversion Principle |
Single Responsibility Principle
It refers to a class or a method of only one thing. If too many responsibilities under a class, equal to couple these functions together, it is possible to change a duty inhibit or reduce the ability of this class perform other duties. Such as a restaurant waiter in charge of the order to the cook to do, rather than have to order the waiter and also cooking.
Open Closed Principle
Open for extension, but closed for modification. After independence means a class should not have to modify it, but in a scalable way to adapt to the new demands. For example, a calculator program started ordinary, suddenly add new requirements, calculator to do a programmer, then should not modify the internal ordinary calculator, interface-oriented programming extensions should be used in combination.
Richter substitution principle
Where all the base class can occur without an error replace the program with a derived class. Subclass can extend the functionality of the parent class, but can not change the parent class of the original function. For example, a motor vehicle must have tires and engine, BMW and Mercedes subclasses should not rewrite did not tire or engine.
Interface Segregation Principle
Class should not rely on unwanted interfaces, know better. For example telephone interface is only binding to answer the phone and hang up, you do not need to let addicts know that there are contacts.
Dependency Inversion Principle
It refers to the high-level modules should not depend on low-level module, instead relying abstract. Abstract can not depend on the details, the details should depend on the abstract. Such as the Class A Class B has an object, called Class B Class A dependent, but should not do so, choosing instead to rely on the abstract class A. For example, the garbage collector garbage no matter what type, if garbage on the line.
