Object-oriented design framework

Low -level architecture: relationships between Classes
Combination, inheritance, dependency, aggregation.

High-level architecture: Design Patterns
Complex design patterns evolve with simple design patterns, solving problems that can not be solved by simple design patterns in more complex scenarios.

Design principles: (through design patterns to achieve design principles)
Single Responsibility principle (SRP), the concept of understanding a single from the responsibility is vague, because the responsibility of one thing can always be subdivided, so what is the single criterion for finding responsibility?

From the SPR words to understand: there should never is more than one reason for a class to the change.
There is a different explanation for this sentence, see your English proficiency and the degree of understanding of this sentence.
My explanation is this: when we need to modify the class because of the external requirements, we examine the reason that there is and only one (there is only one factor that changes, as to how many states of this factor do not control it). In terms of quantity, how many factors change, we have how many classes (or interfaces).
When a piece of code is reused, it must not embody the principle of single responsibility, consider the optimization of the code. Use a composite relationship between classes.

Richter Replacement Principle : Where the parent class appears, the subclass must be able to appear and will not produce any errors or exceptions
To do this, when using inheritance, you need to meet the following requirements:
1. When overriding or implementing a method of a parent class, the input parameters can be magnified and cannot be scaled down.
Subclasses have two ways of implementing the methods of the parent class, one is overwrite, and the other is overloading.
The input parameters of the former subclass method are the same as the input parameters of the parent class method, and the input parameters of the subclass method are different from the input parameters of the parent class method, or large or small (large refers to the parent class of the method input parameter of the parent class, which means that the input parameter of the subclass method is the subclass of the parent method input
The same input parameters are not discussed naturally, and the input parameters are now discussed in different situations.

1. When the input parameter of a subclass method is a subclass of the parent class method input parameter.
An error occurs where the subclass's method is executed without covering the parent class method. The logic at this point is chaotic.
2. When the input parameter of a subclass method is the parent class of the parent method input parameter.
When a method of a subclass is called, the method of the parent class is called.

Explain how complicated it can be to express with a simple constraint.
1. Subclasses can implement the abstract methods of the parent class, but cannot override the non-abstract methods of the parent class.
2. Subclasses can add their own unique methods.
3. When a method of a subclass overloads a method of the parent class, the method's preconditions (that is, the parameter of the method) are more lenient than the input parameters of the parent class method.
4. When a method of a subclass implements an abstract method of the parent class, the method's post-condition (that is, the method's return value) is stricter than the parent class.

dependency Inversion principle:
Abstraction should not rely on detail, interface-oriented programming.
Interface-oriented programming idea: What is the role of interface, define a kind of things have the commonality, that is, as long as two classes have a common part, it should be separated out of an interface. Refining things in common, then encapsulating them, is one of the core of design patterns.

interface Isolation principle:
The interface isolation principle is similar to the previous single responsibility principle, but it is different. One is that the principle of single responsibility focuses on responsibility, while the interface isolation principle focuses on the isolation of interface dependencies. Second, the principle of single responsibility is mainly constrained class, the next is the interface and method, it is the implementation and details of the program, and the interface isolation principle mainly constrains the interface interface, mainly for the abstract, the overall framework of the program for the construction.
When using the interface isolation principle to constrain the interface, the following points should be noted:
1. The interface is as small as possible, but there are limits. The refinement of the interface can improve the design flexibility is not a fact, but if too small, it will result in an excessive number of interfaces, resulting in complex designs. So be sure to be modest.
2. To customize the service for an interface-dependent class, expose only to the calling class the method it requires, and the method it does not need is hidden.
3. A minimal dependency can be established only by focusing on providing a customized service to a module.
4. Improve cohesion and reduce external interaction. Enable the interface to do the most things with the least amount of method.

Dimitri Law:
In layman's words, a class should know the least about the classes that it needs to be coupled or called, and how complex it is for you (the class that is being coupled or called) is not okay with me, that's your thing, I know the public method you provide, I'm calling so much, the rest doesn't care.
Communicate with friends only: the definition of a friend class is this: The class that appears in the member variable, the input and output parameters of the method is called the member Friend class, and the class that appears inside the method body does not belong to the friend class.

Opening and closing principle: open to expansion, closed for modification.
Each design pattern will inevitably embody one or more design principles, or deal with specific application scenarios.

design mode:
Construction class Mode:
This is the simplest way to create an object, instead of new.
Single-case mode:
Feature: A class can only generate one object
should be scene:
Design idea: Define constructors as private, external cannot create objects, and you can create objects by themselves only through static functions.

When there is no attribute value in a class, it is only used to provide a way out, typically you should use a singleton pattern, you can also use static classes and static methods, but static classes are not object-oriented and cannot be inherited and extended, with some limitations.

prototype mode:
Feature: Do not create an object by using the new keyword, but rather by copying the object.
Design idea: The prototype pattern first produces a class containing a large amount of common information, which can then be copied, amended, and a complete personality object is created.

Factory mode:
Features: the creation of the same attribute by the class famous as input parameter, returns the unified interface, reduces the coupling between the modules, and improves the expansibility of the program. To add an object of the same property again, simply add a class, and the factory class does not need to make any modifications.

Abstract Factory mode:
Features: Compared to the factory model, there are different
1. Create different classes by using the member method.
2. The abstract factory class derives from a number of specific factory classes.

Template Method Mode:
A template approach is a combination of a series of basic methods
Features: The algorithm that is considered invariant (a series of basic methods) is encapsulated in the parent class for implementation, which improves the reusability of the code. The generic template method is combined with the final keyword and is not allowed to overwrite.

Builder mode:

Proxy mode:
"Design pattern of Zen" in the game leveling by the example of the image of the agent model of the work mode, but not very good explanation of the intention of the proxy mode, if I have to invite leveling to play games, then I would rather not play games.
Proxy mode definition: Provides a proxy for other objects to control access to this object.
The definition is well understood, and the key question is why to control access to this object.
So the core purpose of this game is not to provide a proxy for a particular gamer, but because of the presence of such a proxy, when the specific theme of the role changes, you can use the minimum amount of code modification to complete the function. The proxy class does not require any changes.

Broker Mode: implementing Dimitri Law
Features: Encapsulates a series of object interactions with a mediation object, which allows the objects to be loosely coupled and can independently change the interaction between them without displaying the interaction of the objects.

Responsibility Chain Mode:
With multiple objects having the opportunity to handle requests, the responsibility chain model makes it very well to decide who will handle the request.
Design idea: Set the priority of the processor, in this priority according to the identity of the requestor to achieve the specific allocation of responsibility and delivery.

policy mode: (Dimitri Law application)
The idea of borrowing the proxy pattern is different from the wrapper role of the policy pattern and the encapsulated policy not using the same interface. Use the class object as the encapsulated input parameter.

Adapter Mode:
Transforming the interface of one class into another interface that the client expects, so that the original interface does not match and the two classes that cannot work together can work together.

iterator Mode: (Hide attribute)
Provides a way to access individual elements in a container object without exposing the object's internal details (rarely used)

Combination mode: (Implement tree structure)

Observer Pattern: (Event-processing mechanism)
Defines a one-to-many dependency between objects, so that whenever an object changes state, all objects that depend on him are notified and automatically updated.

Memo mode:

Bridge Mode: (implement dependency inversion principle)
Decoupling the abstract implementation so that the two can change independently. (The relationship between abstract and concrete??? See again)

Interfaces are designed to implement polymorphism, and abstract classes are designed to improve the reusability of code.

So for the tool class, the interface has only one implementation, is there any need for the interface?
When using the tool class, the tools are independent and not coupled, but different tools have the same parts, which can be separated separately from each other.
For example, in the image processing, the use of the Unicom domain noise reduction and unicom domain extraction will be used in the part of the analysis of the Unicom domain, can be extracted out, become a separate class.
When using the tool class, we care about the methods in the tool class, not the tools themselves, in which case love, static methods are useful. Constructors are not required and objects are not required. You can also use singleton mode.

Data classes:
The data class integrates the properties of the data, as well as the methods of manipulating the data, and the behavior of the data.

Structure class:
Complete a combination of different classes.

When is the parent class or interface called, and when is the subclass or implementation class called?
I observe the design pattern of the program, sometimes called the parent class or interface, so that the abstraction and implementation of isolation, to achieve good extensibility, call subclasses, you can achieve the personality of subclasses.

In new, the constructor of the concrete class is called, the return can be a concrete object, or it can be an abstract object, and abstract objects can be used as input parameters for other class methods for good compatibility.
Return specific objects, you can call specific objects relative to the parent object's personality method, that is, or only when the need to implement personality, the specific object will be called.

Encapsulation of Classes
The responsibilities of low-level modules should not be done by high-layer modules, or the encapsulation of classes will be broken.
The specifics of the encapsulation of classes in a program are:
1. Duplicate the object that defines the class.
2. Cross-use of various kinds of objects, the correct usage is that after one class object is used, another class object is used.

The criteria for determining the coupling between classes or the encapsulation of a class are based on the reusability of classes, and if this class is used more than once in subsequent programs, the encapsulation of this class must be strict, minimizing coupling with other classes.

Object-oriented design framework