Source: http: //dev.9cbs.net/develop/article/41/Article/39/39779.shtm
Excerpt from "Agile Software Development - Principle, Method and Practice" - Robert C. Martin
(1) The SRP single responsibility principle is in a case, there should be only one reason why it causes it. The responsibility is "Causes". (2) OCP open closure principles software entities (class, modules, functions, etc.) should be extended, but cannot be modified. For the extension is open, it is closed for changes to the change. The key is abstraction. The universal part of a function is clearly separated. Developers should only make abstractions on those parts that have changed frequently in the program. Reject Unscrupulous abstraction and abstract itself are as important. (3) LSP Liskov replacement principles must be able to replace their basic type (4) DIP-dependent inverted principle abstraction should not depend on the details. Details should depend on abstraction. Hollywood Principles: "Don't call us, we'll call you". All dependencies in the program should terminate from abstract classes and interfaces. Programming for interfaces rather than implementation. Any variable should not hold a pointer or reference to a specific class. Any class should not be derived from the specific class. Any method should not override the already implemented method in any of his base classes. (5) ISP interface isolation principles should not force customers to rely on how they don't need. The interface belongs to the customer and does not belong to the class hierarchy where he is. A plurality of interfaces facing a specific user are better than a universal interface. (6) The granularity of the REP reuse is the particle size of the reuse is the particle size of the release. (7) CCP commonly reusing principles All classes in a package should be commonly reused. If you reuse a class in the package, you have to reusable all classes in the package. Classs that are not close to each other should not be in the same package. (8) All classes in the CRP jointly closed principle package should be commonly closed. If a change is an impact on a package, it will affect all classes in the package, and other packets do not have any effects. (9) ADP does not allow the existence ring in the dependency of the package. Details should not Dependent. (10) SDP stability dependence is dependent on a stable direction. The software (such as abstract class) of the encapsulation system (such as abstract class) should be placed in a stable package, and the unstable package should only contain those possibilities. Changed software (such as a specific class). (11) SAP stable abstract principles abstraction should be consistent with other stability. A stable package should be abstract, an unstable package should be abstract. (12) DAP (Default Abstract Princi) default abstract principle An abstract class is introduced between the classes of the interface and the implementation interface, which implements most of the interface. (13) IDP (Interface Design Princi) interface design principle Plan an interface instead of implementing an interface. (14) BBP (Black Box Principle) Black Box Principle Multi-purpose aggregation, less inheritance of the class. (15) DCSP (DON't Concrete Supperclass Princi) Do not construct specific superclass principles to avoid maintaining specific superclaments.
