【软件设计】

设计原则

单一职责原则Single responsibility principle(SRP)

A class should have a single purpose and only one reason to change If a class has more than one responsibility, then the responsibilities becomes coupled SRP is one of the simplest of the principles, and the one of the hardest to get right.

Heuristics

Describe the primary responsibility in a single sentence Group similar methods Look at hidden methods (private, protected) Many of them indicate that there is another class in the class tying to get out Look for decisions that can change They should go into a separate class Look for internal relationships Are certain variables used by some methods and not others?

Benefits

Easy to modularize, better organization of code Better robustness Weaker coupling Easier to reuse Better maintainability Easy to test Easy to debug

开闭原则Open closed principle(OCP)

Software entities( classes, modules, functions, etc.) should be open for extension, but closed for modification “Open for extension”：The behavior of the module can be extended (e.g., by subclassing) “Closed for modification”：Extending the behavior of a module does not result in changes to the existing source code or binary code of the module This is especially valuable in a production environment, where changes to source code may necessitate code reviews unit tests, Integration test etc., procedures

里氏代换原则Liskov Substitution principle(LSP)

子类可以随时代换父类

满足is……a……的关系

除非父类是抽象方法，子类不能重写

Subtypes must be substitutable for their base types LSP defines the OO inheritance principle If a client uses a base class, then it should not differentiate the base class from derived class, which means the derived class can substitute the base class

Interface segregation Principle(ISP)接口隔离原则

Clients should not be forced to depend on methods they do not use Design cohesive interfaces and avoid "fat" interfaces The dependency of one class to another one should depend on the smallest possible interface The interfaces of the class can be broken up into groups of methods Each group serves a different set of clients

Dependency inversion principle(DIP)依赖倒置原则

上层和下层中间应该有一个依赖层

High-level modules should not depend on low-level modules Both should depend on abstractions（抽象层） Abstractions should not depend on details Details should depend on abstractions DIP is at the very heart of framework design

Low of Demeter(LOD)迪米特法则

Principle of Least Knowledge最少知识原则 Only talk to your immediate friends Don’t talk to strangers Write “shy” codes Minimize coupling

A method M of an object O may only invoke the methods of the following kinds of objects： O itself M's parameters Any objects created/instantiated within M O's direct component objects/list

Composition reuse principle (CRP)

Composite / Aggregate Reuse Principle(CARP)

Note: some of the features if the new object has been created in other good object which has been achieved, then try to use the functionality provided by other objects to become part of the new object, rather than their own re-create. These new objects through objects have been assigned to multiplexing function. In short, to make use of synthesis / polymerization, try not to use inheritance.

Comparing composition and inheritance

方法：继承，组合（合成），

Inheritance is tightly coupled whereas composition is loosely coupled. There is no access control in inheritance whereas access can be restricted in composition. We expose all the superclass methods to the other classes having access to subclass. So if a new method is introduced or there are security holes in the superclass, subclass becomes vulnerable. Since in composition we choose which methods to use, it’s more secure than inheritance. Composition provides flexibility in invocation of methods that is useful with multiple subclass scenario. One more benefit of composition over inheritance is testing scope. Unit testing is easy in composition because we know what all methods we are using from other class.

Choosing between composition and inheritance

Make sure inheritance models the is-a relationship Don't use inheritance just to get code reuse Don't use inheritance just to get at polymorphism

设计模式

Creational Design Patterns

Creational design patterns abstract the instantiation process. There are two recurring themes in these patterns.

they all encapsulate knowledge about which concrete classes the system uses.
they hide how instances of these classes are created and put together.

单例模式singleton model Pattern

工厂模式Factory model Pattern

Building Design Pattern

结构模式structural Design Patterns

Adapter design pattern

Intent

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces. Wrap an existing class with a new interface. Impedance match an old component to a new system

桥接模式Bridge design pattern

解决类爆炸

将实现和抽象分离

Decouple an abstraction from its implementation so that the two can vary independently. Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy. Beyond encapsulation, to insulation

"Hardening of the software arteries" has occurred by using subclassing of an abstract base class to provide alternative implementations. This locks in compile-time binding between interface and implementation. The abstraction and implementation cannot be independently extended or composed.

bstraction (abstract class) It defined the abstract interface i.e. behavior part. It also maintains the Implementer reference. RefinedAbstraction (normal class) It extends the interface defined by Abstraction. Implementer (interface) It defines the interface for implementation classes. This interface does not need to correspond directly to abstraction interface and can be very different. Abstraction imp provides an implementation in terms of operations provided by Implementer interface. ConcreteImplementor (normal class) It implements the Implementer interface.

装饰设计模式Decorator design pattern

Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. Client-specified embellishment of a core object by recursively wrapping it. Wrapping a gift, putting it in a box, and wrapping the box.

代理设计模式Proxy design pattern

Provide a surrogate or placeholder for another object to control access to it. Use an extra level of indirection to support distributed, controlled, or intelligent access. Add a wrapper and delegation to protect the real component from undue complexity.

You need to support resource-hungry objects, and you do not want to instantiate such objects unless and until they are actually requested by the client.