C # Notes on the object-oriented design model (1)

People are an empirical animal.
Each pattern describes a recurring problem around us and the core of the solution to the problem.
-- Christopher Alexander
The design pattern describes a general solution to a type of common problems in the software design process.
The object-oriented design mode describes the common organizational relationships between classes and communication objects in specific scenarios during the object-oriented design process.

Design Pattern and object-oriented
The object-oriented design model solves the Organizational Relationship between classes and communication objects, including their roles, responsibilities, and collaboration methods.
The object-oriented design model is "Good object-oriented design". The so-called "Good object-oriented design" is the design that can meet the requirements of "Coping with changes and improving reuse.
Object-Oriented Design Patterns Describe software design, so they are independent of programming languages. However, the ultimate implementation of object-oriented design patterns still needs to be expressed using object-oriented programming languages, this course is based on the C # language, but it is actually applicable to support.. NET Framework.. NET language, such as Visual Basic.. net, C ++, and CLI.
Unlike algorithm techniques, the object-oriented design pattern can be copied and used. It is based on an empirical understanding of "Object-Oriented. The premise of understanding the object-oriented design model is to first master the "Object-Oriented "!

New Understanding of object-oriented
From a macro perspective, the object-oriented construction method can better adapt to software changes and minimize the impact of changes
From a micro perspective, the object-oriented approach emphasizes the "responsibility" of each class, and the newly added employee type does not affect the implementation code of the original employee type-this is more in line with the real world, it also gives better control over the scope of impact of changes.
What is an object?
In terms of concept, an object is an abstraction with certain responsibilities.
In terms of specifications, an object is a series of public interfaces that can be used by other objects.
In terms of language implementation, the object encapsulates code and data.

From design principles to design patterns
Interface Programming, rather than implementation programming
The customer does not need to know the specific type of the used object, but only needs to know that the object has the interface that the customer expects.

Object combination is preferred, rather than class inheritance
Class inheritance is usually "white box reuse", and the object combination is usually "black box reuse ". Inheritance damages encapsulation to some extent, and the Child class parent class has a high Coupling Degree. Object combination only requires that the combined object has a well-defined interface, and the coupling degree is low.

Encapsulation changes
The encapsulation is used to create the demarcation layer between objects, so that the designer can modify the interface on one side of the demarcation layer without adversely affecting the other side, so as to implement loose coupling between layers.

Use refactoring to get the model-the application of the design model should not be preemptible. the first use of the design model is the biggest misuse of the design model. There is no one-step design model. The "refactoringto patterns" advocated by agile software development practices is widely recognized as the best way to use the design pattern.

Several more specific design principles:
Single Responsibility Principle (SRP ):
A class should have only one reason for its change.
OCP ):
Class modules should be extensible, but cannot be modified (open to extensions and closed to changes)
Liskov replacement principle (LSP ):
Subclass must be able to replace their base classes
Dependency inversion principle (DIP ):
High-level modules should not depend on low-level modules, both of which should depend on abstraction.
Abstraction should not depend on implementation details, but on abstraction.
Interface isolation principle (ISP ):
Customer programs should not be forced to rely on methods they do not need.