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

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.

GoF23 type design pattern

The historic book, design mode: The basis of reusable object-oriented software, describes 23 classic object-oriented design patterns, and establishes the position of the model in software design. The book
The four authors are called Gang of Four (GoF), the "Foursome", the book describes the 23 classic design patterns 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.

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.

intuitively understand object-oriented from the programming language

Various object-oriented programming languages are different, but all can see their support for the three mechanisms of object-oriented, namely: "Encapsulation, inheritance, polymorphism" – encapsulation, hidden internal implementation
– 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.

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 does not answer the fundamental question of object-oriented-why we use object-oriented. How should we use the three mechanisms to achieve "good object-oriented". What kind of object-oriented principle should we 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.

from an example

Example scenario:

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.

Structured approach

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)
{
......
}

Object-oriented design

1. Design different classes According to different employee types, and make these classes inherit 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 int getsalary ();
}
Class Engineer:employee
{
...
public override int Getsalary ()
{
...
}
}
Class Sales:employee
{
...
public override int Getsalary ()
{
...
}
}
Show Payroll procedures
Employee e = emfactory.getemployee (ID);
MessageBox.Show (E.getsalary ());

Example scenario:

Now 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.

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 ....

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 control over the range of changes, after all, the engineer class should not pay for the new "hourly" ...

What the object is. – From a conceptual level, an object is an abstraction of some kind of responsibility.
– From a specification level, an object is a series of public interfaces that can be used by other objects.
– From a language implementation level, the object encapsulates code and data.

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, not 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 instead of class inheritance

– Class inheritance is usually "white box reuse", and the object combination is usually "black-box reuse". Inheritance to some extent destroys the encapsulation, the subclass parent class coupling degree is high, but the object combination only requires that the combined object has 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.

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.

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 in order to grasp the essence of object-oriented design pattern, so as to realize flexible application of design model
Expression

Three basic object-oriented design principles – programming for interfaces, not for implementation
– Prefer to use object combinations instead of class inheritance
– The package change point uses refactoring to get the pattern. The "refactoring to Patterns" advocated by Agile software Development practice is widely recognized as the best way to use design patterns.