Design Patterns: C # Object-oriented design patterns discussion on [Learning: 01. Object-oriented design patterns and principles course notes]

First Lecture: 1. Object-oriented design patterns and principles

Introduction to Design Patterns:

Each pattern describes a problem that recurs around us, and the core of the solution to the problem.
--christopher alexander{Architect}

Software designers ' understanding of the concept of design patterns:

(1) The design pattern describes a general solution to some common problems in the software design process .
(2) The object-oriented design pattern describes the common relationship between objects in the object-oriented design process, under specific scenarios, and between classes and communicating with each other .
(3) Man is an experienced animal

GOF23 design patterns are the basis of object-oriented design patterns, but not all of the design patterns
? The historic book "Design pattern: The basis of reusable object-oriented Software" 19,941 describes 23 classic object-oriented design patterns, and establishes the position of the model in software design. The book's four authors are known as Gang of Four (GoF), the "foursome", and the 23 classic design patterns described in the book are also known as GoF23 design patterns.
? Because the design pattern: the basis of reusable object-oriented software , the book determines the position of the design pattern, and the design pattern that people usually say implies "object-oriented design pattern". However, this does not mean that the "design pattern" is equal to "object-oriented design pattern", nor does it mean that the GoF23 pattern represents all "object-oriented design patterns". In addition to the object-oriented design pattern, there are other design patterns. In addition to GoF23 design patterns, there are more object-oriented design patterns.
? GoF23 design pattern is the starting point of learning the object-oriented design pattern, not the end point; the goal of this training course is to enable students to master GoF23 design patterns based on effective methods.

Design patterns and Object-oriented
? The object-oriented design pattern solves the relationship between classes and the objects that communicate with each other, including their roles, responsibilities, and ways of collaborating.
? Object-oriented design pattern is "good object-oriented design", so-called "good object-oriented design" is those who can meet the "response to change, improve reuse" design. {"Source code is Design", "good pattern is constantly refactoring"}
? The object-oriented design pattern describes software design, so it is independent of the programming language, but the final implementation of the object-oriented design pattern is still expressed in the object-oriented programming language, which is based on the C # language, but in fact it is suitable for support. NET Framework for all. NET languages, such as Visual Basic.NET, C + +/CLI, and so on.
? Object-oriented design pattern is not like algorithm skill, can copy replicable, it is based on the "object-oriented" skillful, in-depth understanding of the basis of empirical understanding. The premise of mastering object-oriented design pattern is to master "object-oriented" first!

Basics: Intuitive understanding of object-oriented from programming languages {at least at the language level understand object-oriented, implement layer understanding object-oriented}
? Various object-oriented programming languages are different from each other, but they can see their support for the three mechanisms of object-oriented: "Encapsulation, inheritance, polymorphism"
– Encapsulation, hiding internal implementations
– Inherit, reuse existing code
– polymorphic, overriding object behavior
? Using object-oriented programming languages such as C #, you can push programmers to think about the software design structure with object-oriented thinking, thus reinforcing the object-oriented programming paradigm.
? C # is an excellent language that supports object-oriented programming, including: various levels of encapsulation support, single implementation inheritance + multi-interface implementations, abstract methods and virtual methods overrides.

But OOPL is not all object-oriented. {Applying object-oriented language and application object-oriented design pattern is two completely different situations, understanding object-oriented language does not prove that you master design-oriented schema}
? Object-oriented programming language (OOPL)-oriented objects are not all object-oriented, or even just shallow object-oriented.
? The three mechanisms of oopl "encapsulation, inheritance, polymorphism" can express all the concepts of object-oriented, but the three mechanisms themselves do not depict the core spirit of object-oriented. In other words, the three mechanisms can be used to make "good object-oriented design", but also use these three mechanisms to make "poor object-oriented design." Instead of using object-oriented languages (such as C #), Object-oriented design and development is implemented! Therefore, we cannot rely on the object-oriented mechanism of programming language to master object-oriented.
? OOPL doesn't answer the fundamental question of object-oriented--why should we use object-oriented? How should we use the three mechanisms to achieve "good object-oriented"? What is the object-oriented principle we should follow?
? Any serious object-oriented programmer (such as C # Programmer) needs to learn the object-oriented knowledge systematically, and the object-oriented knowledge obtained from the programming language alone is not capable of object-oriented design and development.

Start with an example {What design is designed for design object Design}
We need to design a personnel management system, one of which is to calculate the salary of the month for different types of employees-- different types of employees, with different salary calculation systems .
Example scenario: (1) structured approach (PASICAL\C)
1. Access to all possible employee types in the personnel system
2. Calculate salary according to different salary system for different types of employees
Enumemployeetype{engineer; Sales; Manager, ...}
Calculate Payroll Procedures
If (Type==employeetype.engineer) {...}
else if (type== employeetype.sales) {...}

Example scenario: (2) object-oriented design
1. Different classes are designed according to different employee types, and the classes are inherited from an employee abstract class, which has an abstract method getsalary.
2. In each of the different employee classes, override the Getsalary method according to your own salary system.
Abstract class employee{
...
public abstract intgetsalary ();
}
Class engineer:employee{
...
public override Intgetsalary () {
......
}
}
Class sales:employee{
...
public override Intgetsalary () {
......
}
}
Show Payroll procedures
Employee E=emfactory.getemployee (ID);
MessageBox.Show (E.getsalary ());

Now the demand has changed {} ...
With the expansion of the customer's business scale, there are more types of employees, such as the hourly, piece work ... And so on, this presents a challenge to the personnel Management system-the original procedure must be changed.
Example scenario: (1) structured approach
Almost all the types of employees involved (including, of course, "payroll procedures") need to be changed ... This code needs to be recompiled, redeployed ....
(2) Object-oriented approach
Just add a new employee class to the new file, let it inherit from the employee abstract class, and rewrite the Getsalary () method, then create a new employee type in the Employeefactory.getemployee method based on the relevant conditions. Other places (show payroll, engineer, sales, etc.) do not need to be changed.

Re-understanding Object-oriented
? For the previous example, from the macro level, the object-oriented approach is more adaptable to software changes, minimizing the impact of changes
? At the micro level, the object-oriented approach emphasizes the "responsibility" of each class, and the new employee type does not affect the implementation code of the original employee type--which is more in line with the real world and more able to control the scope of the change, after all, the engineer class should not pay for the new "hourly" ...
? What is the object? {Don't care about the internal link}.
– From a conceptual level, an object is some kind of abstract {} with responsibility.
– From a specification level, an object is a series of public interfaces that can be used by other objects
– From the language implementation level, the object encapsulates the code and data {encapsulates the behavior and State}.
? With these realizations, how can you design "good object-oriented"?
– Follow certain object-oriented design principles
– Familiar with some typical object-oriented design patterns

From design principles to design patterns
? Programming for interfaces rather than programming for implementation – the customer does not need to know the specific type of object being used, just know that the object has the interface that the customer expects.
? Prefer to use object combinations rather than class inheritance – class inheritance is typically "white box reuse", and object combinations are typically "black box multiplexing." Inheritance to some extent destroys the encapsulation, the subclass parent class coupling degree is high, but the object combination only requires the combination of the
Like a well-defined interface, the coupling degree is low.
? Package Change Point
– Use encapsulation to create a boundary layer between objects, allowing the designer to modify on one side of the boundary layer without adversely affecting the other side, allowing for loose coupling between layers.
? Using refactoring to get patterns--the application of design patterns should not be preconceived , the use of design patterns is the greatest misuse of design patterns. There is no design pattern for one step. The "refactoring to Patterns" advocated by Agile software Development Practice is widely recognized as the best way to use design patterns. {Source code is design}

A few more specific design principles
? Single responsibility Principle (SRP):
– A class should have only one reason to cause it to change.
? Open closure principle (OCP):
– class modules should be extensible, but not modifiable (open for extensions, closed for changes)
? Liskov replacement principle (LSP):
– subclasses must be able to replace their base classes
? Dependency inversion principle (DIP):
– The high-level modules should not be dependent on the lower layer modules, both should be dependent on abstraction.
– Abstractions should not be dependent on implementation details, and implementation details should be dependent on abstraction.
? Interface Isolation principle (ISP):
– The client program should not be forced to rely on methods that they do not use.

Lecture Summary
? The design pattern describes a general solution to some common problems in the software design process. The object-oriented design pattern describes the common organization relationships between objects in the object-oriented design process, under specific scenarios, and between classes and communicating with each other.
? A deep understanding of object-oriented is the basis of learning design patterns, mastering certain object-oriented design principles can grasp the essence of object-oriented design pattern, and thus realize the flexible use of design patterns.
? Three basic object-oriented design principles
– Programming for interfaces, not for implementation
– Prefer to use object combinations instead of class inheritance
– Package Change Point
? Use refactoring to get patterns. The "refactoring to Patterns" advocated by Agile software Development practice is widely recognized as the best way to use design patterns.

Design Patterns: C # Object-oriented design patterns discussion on [Learning: 01. Object-oriented design patterns and principles course notes]