Category six principles [and] design patterns Design patterns

A classification, design patterns

Overall, the design patterns into three categories:

　　Create a schema, a total of five categories: factory method pattern, abstract factory pattern, singleton, the builder pattern, prototype model.

　　Structural model, a total of seven kinds: adapter mode, decorative mode, proxy mode, the appearance mode, bridge mode, combination mode, Flyweight.

　　Behavioral patterns, a total of eleven kinds: Strategy pattern, the template method pattern, observer mode, iterator pattern, the responsibility chain mode, command mode, the memo mode state mode, the visitor pattern, intermediary model to explain the mode.

　　In fact, there are two types: concurrency pattern and thread pool mode.

Second, the design pattern of six principles

• Single Responsibility Principle

• Richter substitution principle

• Dependency Inversion Principle

• Interface Segregation Principle

• Dmitry principle

• Open Closed Principle

Single Responsibility

• The concept: the functional classification, the code decoupling

• Chestnut: a network request frame is roughly divided into: request class, cache, configuration, and; can not be mixed together these three functions, must be divided into three categories are to achieve different functions

Richter replacement

• Concept: When inheriting class, in addition to the expansion of some of the new features, try not to delete or modify the reference to the parent class method, but also try not to overload the parent class method

• Chestnut: Each class is a subclass of Object, Object class has a toString () method, if the subclass overrides this method and return null, null is returned inherited subclass of this level, then different developers may not consider the maintenance of this issue and is likely to cause the program to crash

Dependency Inversion

• The concept: high-level module does not depend on the details of low-level modules, high-level is not dependent on the details but rather rely on abstract (not dependent on a specific category, but rather rely on the interface)

• Chestnut: a networking framework to meet the needs of different developers, that can be used efficiently OkHttp framework, you can use native API. The so-called turnip cabbage all have love, how it is to switch it, this time of need oriented programming interface ideas, and the method of some network requests packaged into one interface, and then create the interface implementation class OkHttp and native API are, of course, also facilitate follow-up to other developers to extend the application of the framework of other networks

Interface Segregation

• Concept: When defining the interface method should be rationalized, minimized as much as possible the pursuit of simple, avoid bloated interfaces

• Chestnuts: in the actual development, often in order to save time, probably more will be drawn into a method function of the interface, in fact, this concept is not correct, it would be the interface is bloated state, then you need a reasonable split method interface, additional extraction into a separate interface to avoid legacy interface codes cause difficulty in understanding a bloated

Dimitris | Minimum know

• The concept: an object should be to other objects the least understood; a class should know the least of their needs coupled or call category, how the internal class implementation, how complex are associated with the caller or dependence does not matter, the caller or dependents only need to know the way he needed to, the other not and will not care. The closer the relationship between class and class, the greater the degree of coupling, when a class is changed, the influence of another class is also greater. Only direct communication with friends. Each object is bound to have coupling relationship with other objects, the coupling between the two objects becomes a friend relationship, this relationship, there are many types, such as a combination, polymerization dependence.

• Chestnuts: In general, when using the framework, the framework developer would have taken a class for external calls, while the main classes as an intermediary like to call other classes inside the framework, just inside the framework of other classes are generally inaccessible ( call), and this framework will comply with the principles of Demeter, other developers only care about the method call, you do not need to worry about how to implement specific functions

Opening and closing

• The concept: classes, modules and functions should be open for extension, closed for modification

• Chestnuts: in the software life cycle because of changes, upgrades, and maintenance or other reasons need to modify existing software code, the old code could have introduced errors or may cause us to have to reconstruct the whole function, and we need the original code has been retested, the whole process a great impact on the development cycle, this time on the need to open and close in principle to resolve this problem

to sum up

• Single Responsibility Principle tells us to implement a single class responsibilities

• Richter substitution principle tells us not to destroy the inheritance hierarchy

• Dependency Inversion Principle tells us to be oriented programming interface

• Interface Segregation Principle tells us in the design of the interface of time to streamline the single

• Dimitris principle tells us to reduce the coupling

• Opening and closing principle is Master, tell us to open to extension, closed for modification

Author: Android wheels brother
link: https: //www.jianshu.com/p/068b2d0ce4e6