I. Introduction
C # version of the 23 design patterns has been finished, and now to a summary of the time. Speaking of design patterns, I would be relatively more. Just start writing code, there is a demand to write code to solve demand, if there is new demand, or demand has changed, I take it for granted modify their code to meet the new requirements, this feeling is taken for granted, nor I feel there is nothing wrong. Write code for more than two years, once in a while, I heard of design patterns, design patterns is heard, according to the software industry, "Magic Power", then you can learn invincible, so I started my learning path.
At first, I was like a lot of beginner programming people, it is easy to say the three characteristics of object-oriented language in front of the interviewer: inheritance, encapsulation and polymorphism, in fact, I do not understand the meaning of these three words, or understand very shallow. Of course, there are many concepts are unclear, such as: OOPL (object-oriented languages) is that OO is not all, in the end what is the difference between object-oriented design patterns and design patterns, and so on related issues. Since their own learning design patterns, many of the concepts become clear, principled work, or that there is a guideline, and is not just enough to solve the problem, not whether code written is reasonable. Write code that can be very beautiful, and the structure is more reasonable, and he began to rethink the code for this thing.
Learning design patterns is not easy, especially in the beginning, since many of their own concept is not very clear, but also take a lot of detours, but by his own insistence, through their continued watching, constantly writing, comprehension of the model is also more and more accurate. Write code is not a very simple thing, to do anything is principled, writing code, too, if his mind to do something no guidelines, and it headless flies, do it or not is the same. Write code and write code that is not the same, if to write good code, consider the problem more, consider the stability, scalability and coupling, of course, also consider issues related upstream and downstream, so that you do things when you know how to do, but also know how to do, which is to learn to bring the benefits of design patterns.
Well, say a lot, and I put my writing mode are listed here, each mode has a link, you can directly click to view and read, we want to read useful.
Series Navigation:
Creating type:
C#设计模式(1)——单例模式（Singleton Pattern）
C#设计模式(2)——工厂方法模式（Factory Pattern）
C#设计模式(3)——抽象工厂模式（Abstract Pattern）
C#设计模式(4)——建造者模式（Builder Pattern）
C#设计模式(5)——原型模式（Prototype Pattern）
Structural:
C#设计模式(6)——适配器模式（Adapter Pattern）
C#设计模式(7)——桥接模式（Bridge Pattern）
C#设计模式(8)——装饰者模式（Decorator Pattern）
C#设计模式(9)——组合模式（Composite Pattern）
C#设计模式(10)——外观模式（Facade Pattern）
C#设计模式(11)——享元模式（Flyweight Pattern）
C#设计模式(12)——代理模式（Proxy Pattern）
Behavioral:
C#设计模式(13)——模板方法模式（Template Method）
C#设计模式(14)——命令模式（Command Pattern）
C#设计模式(15)——迭代器模式（Iterator Pattern）
C#设计模式(16)——观察者模式（Observer Pattern）
C#设计模式(17)——中介者模式（Mediator Pattern）
C#设计模式(18)——状态模式（State Pattern）
C#设计模式(19)——策略模式（Stragety Pattern）
C#设计模式(20)——责任链模式（Chain of Responsibility Pattern）
C#设计模式(21)——访问者模式（Vistor Pattern）
C#设计模式(22)——备忘录模式（Memento Pattern）
C#设计模式(23)——解释器模式（Interpreter Pattern）
Second, the object-oriented design principles
Write code that is principled reason why we use design patterns, mainly in order to adapt to change, improve code reuse rate, to make the software more maintainable and extensible. If we can better understand the design principles, to our understanding of object-oriented design patterns it is also helpful, since these models are generated based on these principles. These rules are: Single Responsibility Principle (SRP), the open closed principle (OCP), Richter instead of principle (LSP), Dependency Inversion Principle (DIP), Interface Segregation Principle (ISP), the synthesis of multiplexing principles (CRP) and Dmitri special principles (LoD). Here we have introduced these types of design principles.
2.1 Single Responsibility Principle (SRP):
(1), SRP (Single Responsibilities Principle) definition: On a category, it should only be one the cause of change. In short, to a single function.
(2) if a class excessive responsibilities under, equal to these functions coupled together, a change in the duty may impair their ability to inhibit this class or perform other duties. This coupling will lead to fragile designs, when a change occurs, the design will suffer unexpected damage. (Agile Software Development)
(3), software design many elements really need to do is find those duties and responsibilities separated from each other.
Summary: Single Responsibility Principle (SRP) can be seen as a low coupling, high cohesion extended on object-oriented principles, we will define the responsibilities cause changes to improve cohesion to reduce the causes of variation. The more reason too much responsibility, changes caused by it, which would lead to duties depend greatly damage its cohesion and coupling.
2.2 Open Closed Principle (OCP)
(1), OCP (Open-Close Principle) definition: that software entities (classes, methods, etc.) should be extended (extended as will be appreciated increase), but can not modify the original method or a class, it may be so He said that the increase in open code, modify the code closed.
(2), two features OCP: For the expansion (increase) is open, because it does not affect the original, which is newly added. Modifications are closed, if you always modify the logic will become increasingly complex.
Summary: Open Closed Principle (OCP) is an object-oriented design core idea. Following this principle can bring huge benefits to our object-oriented design: Maintenance (less maintenance costs, make management simple, with minimal impact), extensible (new demand, increase like), reusable (not coupled, You can use the code before), good flexibility (easy maintenance, simple). Frequent changes in those parts of the developer should appear only program to make the abstract, but not extreme, for each part of the application are deliberately abstract is also not a good idea. As important as immature denial of abstraction and abstraction itself.
2.3 Richter instead of principle (LSP)
(1), LSP (Liskov Substitution Principle) definition: subtype thereof must be able to replace the parent type. More straightforward to say, LSP is the basis for the programming interface.
Summary: where any base class can appear, sub-class will be able to appear, so we can achieve oriented programming interface. LSP is inherited cornerstone multiplexed only when subclasses can replace the base class, software functionality is not affected, the base class can really be reused, and the subclass can add new behavior on the basis of the base class on. Richter substitution principle is - to add "on-off" principle. To achieve "open - closed" principle is a key step in abstraction. The inheritance relationship with a base class is a subclass of the abstract concrete realization, so Richter substitution principle is the specification for concrete steps to achieve the abstract.
2.4 Dependency Inversion Principle (DIP)
(1), defined DIP (Dependence Inversion Principle): The abstract should not rely on the details, should depend on the details of abstraction. It simply is, we want an interface for programming, but not for the realization of programming.
(2) high-level modules should not depend on low-level modules, both should depend on the abstract, because the abstract is stable. Abstract should not rely on specific (detail), in particular (detail) should depend abstraction.
Summary: Dependency Inversion principle can actually be said to be an object-oriented logo design, if taken into account when we are encoded programming to interfaces, rather than a simple function to achieve, reflecting the stability of the abstract, the only way to meet the object-oriented design .
2.5 Interface segregation principle (ISP)
(1), the interface segregation principle (Interface Segregation Principle, ISP) refers to the use of a plurality of dedicated interfaces always better than using a single interface. That is not to let a single interface to assume too many responsibilities and duties of each should be separated into multiple specialized interface, the interface separation. Too bloated interface is a pollution of the interface.
(2), a plurality of dedicated interfaces than using a single interface to better overall.
(3), a class dependent on another class should be based on the smallest interface.
(4), an interface represents a role, should not be different roles are handed over to an interface. Not related interfaces merge together to form a large bloated interface, which is the pollution of the roles and interfaces.
(5) "should not be forced to rely on the method of their customers do not have the interface belonging to the customer, it does not belong in the class hierarchy." This made it very clear, and then popular point that, do not force customers to use their unused , forcing users to use if they are not used, then these customers will face a change due to changes in the use of these methods are not brought.
Summary: Interface Segregation Principle (ISP) tells us that when doing interface design, interface functions to try to design a single, single function, making it less variation factors, so that even more stable, in fact, this reflects the high cohesion, low coupling principle, this would also avoid contamination of the interface.
2.6 Principles combination multiplexing (CRP)
(1), a combination of multiplexing principles (Composite Reuse Principle, CRP) is the use of some existing objects inside a new object, making it part of the new object. The new object is reached by multiplexing functions have been delegated to the purpose of these objects. Simply put, it is to minimize the use of synthetic / polymeric, try not to use inheritance.
(2), to use a good combination of multiplexing principles of relations first need to distinguish between "Has-A" and "Is-A" of. "Is-A" refers to a class "a" of another class, belonging to the relationship, while the "Has-A" is different, one representing a particular character has responsibility. Common cause of the error using inheritance instead of polymerization is mistakenly "Has-A" as "Is-A" for example: Chickens are animals, this is the "Is-A" performance, someone has a gun, People type which contains a Gun type, this is the "Has-a" performance.
Summary: composition / polymerization multiplexing principle may make the system more flexible, reducing the degree of coupling between the class and class, a relatively small change in the influence of other classes class caused, it is generally preferred to use a combination of / polymerization achieve multiplexing; Second, before considering inheritance, when using inheritance, you need to strictly follow the Richter substitution principle, the effective use of inheritance would help understanding of the problem, reduce complexity, and the abuse of inheritance but will increase the complexity of building and maintaining the systems and the difficulty of system degree, and therefore require careful use inheritance to reuse.
2.7 Law of Demeter (Law of Demeter)
(1), Demeter (Law of Demeter, LoD) also known as the principle of least knowledge (Least Knowledge Principle, LKP), refers to an object should have as little knowledge of other objects. That is, the interaction between the entity and the other modules or objects should be minimal, so that the system is relatively independent functional modules, so that when a module is modified, the less affected modules, expansion much easier.
(2), on the Law of Demeter some other statements are: friends only communicate directly with you; do not talk to "strangers."
(3), the appearance model (Facade Pattern) and intermediary model (Mediator Pattern) on the use of Demeter.
Summary: Demeter intention is to reduce the coupling between classes, high cohesion, low coupling between the types, it can be decoupled so. But everything has a degree, excessive use of Demeter principle, this will generate a lot of intermediaries and pass the class, leading to system complexity increases. Therefore, when employed to weigh Demeter, do both clear structure, but also the high cohesion and low coupling.
Original: https: //www.cnblogs.com/mq0036/p/8288099.html