7 bad smells, 11 principles, 23 patterns every programmer should keep in mind
Detailed explanation of 23 design patterns:
http://www.runoob.com/design-pattern/design-pattern-tutorial.html
(1) 7 bad design smells
1. Rigidity: It is difficult to make changes to the system, because each change will force many other changes to other parts of the system.
2. Vulnerability: Changes to the system can cause problems in many places in the system that are conceptually unrelated to the place where the change was made.
3. Robustness: It is difficult to untangle a system into some components that can be reused in other systems.
4. Stickiness: Doing the right thing is harder than doing the wrong thing.
5. Complexity (unnecessary): The design contains infrastructure that does not provide any immediate benefit.
6. Repetitive (unnecessary): The design contains repetitive structures that could have been unified using a single abstraction.
7. Obscure: Difficult to read and understand. Not a good indication of intent.
(2) 11 Principles - Principle
---- Class Principle
1. Single Responsibility Principle - Single Responsibility Principle (SRP)
As far as a class is concerned, there should be only one reason for its change.
(Responsibility is the "reason for change".)
2. Open-Closed Principle - Open Close Principle (OCP)
Software entities (classes, modules, functions, etc.) should be extensible, but not modifiable.
(Open for extension, closed for change. The
key is abstraction. Clear separation of the general part of a function from the implementation details.
Developers should only abstract those parts of the program that exhibit frequent changes.
Rejecting immature abstractions is as important as the abstraction itself. )
3. Liskov Substitution Principle (LSP)
Subclasses must be able to replace their base types (superclass).
4. Dependence Inversion Principle (IoCP) or Dependency Injection Principle - Dependence Inversion Principle (DIP)
abstraction should not depend on details. Details should depend on abstraction.
(Hollywood principle: "Don't call us, we'll call you".
All dependencies in a program should terminate in abstract classes and interfaces.
Program against interfaces, not implementations.
No variable should hold a pointer to a concrete A pointer or reference to a class.
No class should be derived from a concrete class.
No method should override an already implemented method in any of his base classes.)
5. The Interface Segregation Principle (ISP)
should not force clients to rely on for methods they do not use.
An interface belongs to the client, not to the class hierarchy in which it resides.
(Multiple user-oriented interfaces are better than a general interface.)
----Package Cohesion Principle
6. Reuse Release Equivalence Principle (REP)
The granularity of reuse is the granularity of release.
7.
All classes in the Common Closure Principle (CCP) package should be common closed to changes in properties of the same class.
If a change affects a package, it
will affect all classes in
the package, and will not have any effect on other packages.
8. Common Reuse Principle (CRP)
All classes in a package should be reusable together.
If you reuse a class in a package,
Then all the classes in the package are reused.
(Classes that are not closely related to each other should not be in the same package.)
----Package Coupling Principle
9. Acyclic Dependency Principle (ADP) No cycles
are allowed in a package's dependency graph.
10. The Stable Dependency Principle (SDP)
makes dependencies in the direction of stability.
The software that encapsulates the high-level design of the system (such as abstract classes) should be put into stable packages, and the
unstable packages should only contain software that is likely to change (such as concrete classes).
11. The Principle of Stable Abstraction (SAP)
The level of abstraction of a package should be consistent with its level of stability.
(A stable package should also be abstract, and an unstable package should be abstract.)
----Other extension principles----
12.BBP (Black Box Principle) The black box principle
uses more class aggregation and less use Inheritance of classes.
13.DAP (Default Abstraction Principle) The default abstraction principle
introduces an abstract class between the interface and the class that implements the interface. This class implements most of the operations of the interface.
14.IDP (Interface Design Principle) The interface design principle
plans an interface rather than implementing an interface.
15.DCSP (Don't Concrete Supperclass Principle) Do not construct specific superclass principles
to avoid maintaining specific superclasses.
16. Demeter's Law
A class depends only on the classes at its fingertips.
(3) 23 design patterns - Pattern.
Creation
Abstract Factory -> (Simple Factory Mode)
Factory Method
Builder (Generator Mode)
Singleton (Singleton Mode) -> (Multiple Instance Mode)
Prototype (Prototype Mode)
Structural
Adapter ( Adapter Mode)
Bridge (Bridge Mode)
Composite (Composition Mode)
Decorator (Decoration Mode)
Facade (Appearance Mode, Facade Mode)
Flyweight (Flyweight Mode) -> (Invariant Mode)
Proxy (Proxy Mode)
Behavioral
Chain of Responsibility ( Chain of Responsibility Mode
Command (Command Mode)
Interpreter (Interpreter Mode)
Iteartor (Iterator Mode)
Mediator (Mediator Mode)
Memento (Memento Mode)
Observer (Observer Mode)
State (State Mode)
Strategy (Strategy Mode)
TemplateMethod ( Template method pattern)
Visitor (visitor pattern)
Reprinted from: http://javatar.iteye.com/blog/41096