7 Bad tastes that every programmer should understand, 11 principles, 23 Models

7 Bad tastes that every programmer should understand, 11 principles, 23 Models

(1) 7 Bad Designs

1. rigidity: it is difficult to make changes to the system, because each change forces many other changes to the other part of the system.

2. Vulnerability: changes to the system may cause problems in many areas that are conceptually irrelevant to the system and the changes.

3. Robustness: It is difficult to solve the tangle of the system and make it a component that can be reused in other systems.

4. viscosity: Doing the right thing is more difficult than doing the wrong thing.

5. complexity (unnecessary): The design contains an infrastructure that has no immediate benefits.

6. repeatability (unnecessary): The design contains a duplicate structure, which can be unified using a single abstraction.

7. Obscure: difficult to read and understand. The intent is not shown very well.

(2) 11 principles-Principle

---- Category Principle

1. Single Responsibility Principle-single responsibility principle (SRP)

For a class, there should be only one reason for its change.

(Responsibility is the reason for the change ".)

2. Open-Close principle-Open Close principle (OCP)

Software entities (classes, modules, functions, etc.) should be extensible, but cannot be modified.

(It is open for expansion and closed for changes.

The key is abstraction. The general part of a function and the implementation details are clearly separated.

Developers should only abstract those parts that present frequent changes in the program.

Rejecting immature abstraction is just as important as abstraction itself .)

3. Lean replacement principle-liskov substitution principle (LSP)

Subclass must be able to replace their base type (superclass ).

4. Dependency 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 the program should end with abstract classes and interfaces.

Programming for interfaces rather than implementations.

No variable should hold a pointer or reference pointing to a specific class.

No class should be derived from a specific class.

No method should overwrite the implemented methods in any of its base classes .)

5. Interface isolation principle (ISP)

Customers should not be forced to rely on methods they do not need.

An interface belongs to a customer and does not belong to its class hierarchy.

(Multiple user-oriented interfaces are better than one common interface .)

---- Package cohesion principle

6. Reuse release Equivalence Principle (REP)

The granularity of reuse is the publishing granularity.

7. Principle of joint closure (CCP)

All classes in the package should be closed for changes to the same class nature.

If a change affects a package,

It will affect all classes in the package,

Other packages will not be affected.

8. Principle of joint reuse (CRP)

All classes in a package should be reused together.

If a class in the package is reused,

All classes in the package must be reused.

(Classes that are not closely related to each other should not be in the same package .)

---- Package coupling principle

9. No-ring dependency principle (ADP)

The package dependency graph does not allow loops.

10. Stable dependency principle (SDP)

Dependency in a stable direction.

The software (such as abstract classes) designed to encapsulate high-level systems should be put into a stable package,

The unstable package should only contain software that is likely to change (such as specific classes ).

11. Stable abstraction principles (SAP)

The abstraction level of the package should be consistent with its stability.

(A stable package should also be abstract, and an unstable package should be abstract .)

---- Other expansion principles ----

12. BBP (black box principle) Black Box Principle

Multi-purpose class aggregation, less class inheritance.

13. Default abstraction Action Principle (DAP) default abstraction principle

An abstract class is introduced between the interface and the class that implements the interface.

14. IDP (interface design principle) Interface Design Principles

Plan an interface instead of implementing an interface.

15. dcsp (don't concrete supperclass principle) do not construct a specific superclass Principle

Avoid maintaining specific superclasses.

16. dumit's Law

A class only depends on the class at your fingertips.

(3) 23 design patterns-pattern.

Creation type

Abstract Factory (Abstract Factory mode)-> (simple factory Mode)

Factory method (factory Mode)

Builder Mode)

Singleton (single-piece mode)-> (Multi-instance mode)

Prototype (prototype)

Structural

Adapter (adapter Mode)

Bridge)

Composite (Combination Mode)

Decorator)

Facade (appearance mode, facade Mode)

Flyweight (meta mode)-> (unchanged Mode)

Proxy (proxy Mode)

Behavior Type

Chain of responsibility (responsibility chain mode)

Command (command mode)

Interpreter (Interpreter Mode)

Iteartor (iterator Mode)

Mediator (intermediary Mode)

Memento (memorandum Mode)

Observer (Observer Mode)

State)

Strategy)

Templatemethod (template method mode)

Visitor (visitor Mode)

 

 

Transferred from: rainylin