Object-oriented design patterns and principles.

Introduction to Design Patterns

Each pattern describes a recurring problem around us, as well as the core of the solution to the problem.
--Christopher Alexander

The design pattern describes a general solution to a common problem in the software design process. Object-oriented design patterns describe the common organizational relationships among object-oriented design processes, specific scenarios, classes, and objects that communicate with each other.

design pattern of GoF23

The historical book "Design Pattern: the foundation of reusable object-oriented software" describes 23 kinds of classic object-oriented design patterns, and establishes the status of the pattern in software design. The book
The four authors are called the Gang of Four (GoF), the four-person group, and the 23 classical design patterns described in the book are called GoF23 Design patterns.

Because design patterns: the basics of reusable object-oriented software, a book identifies the status of design patterns, which are often described as "object-oriented design Patterns" implicitly.
This does not mean that "design pattern" equals "object-oriented design pattern", nor does it mean that the GoF23 pattern represents all the "object-oriented design patterns." In addition to "object-oriented design patterns," There are other design patterns. In addition to the GoF23 design patterns, there are more object-oriented design patterns.

GoF23 design pattern is the starting point of learning 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

Object-oriented design patterns address "the organizational relationships between classes and objects that communicate with each other, including their roles, responsibilities, and ways of collaborating."

The object-oriented design pattern is "good object-oriented design", and the so-called "good object-oriented design" is those that can meet the "response 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 object-oriented programming language, this course 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 technique, can be copied replicable, it is based on the "object-oriented" skillful, in-depth understanding of the empirical understanding. The prerequisite of mastering object-oriented design pattern is to master "object-oriented" first.

intuitive understanding of object oriented from programming language

Various object-oriented programming languages are different from each other, but they can all see their support for the three main object-oriented mechanisms, namely: "Encapsulation, inheritance, polymorphism"-encapsulation, hidden internal implementation
– Inheritance, reusing existing code
-Polymorphism, overwriting object behavior

The use of Object-oriented programming languages such as C # enables programmers to think about software design structures with object-oriented thinking, thereby strengthening object-oriented programming paradigms.

C # is an excellent language that supports object-oriented programming, including: various levels of encapsulation support, single implementation inheritance + multiple interface implementations, abstract methods and virtual method overrides.

but OOPL is not an object-oriented whole

Object-oriented programming Language (OOPL) is not an Object-oriented object-oriented, or even a shallow object oriented.

The three mechanisms of OOPL, "encapsulation, inheritance and polymorphism", can express all the concepts of object-oriented, but the three mechanisms themselves do not depict the core object-oriented spirit. In other words, the three mechanisms can be used to make "good object-oriented design", or use these three mechanisms to make "poor object-oriented design." Instead of using object-oriented language (such as C #), object-oriented design and development are achieved. Therefore, we can not rely on the object-oriented mechanism of programming language to grasp the object-oriented.

OOPL doesn't answer the fundamental object-oriented question-Why do we use object-oriented objects. How should we use the three mechanisms to achieve "good object-oriented". What kind of object-oriented principles should we follow?

Any serious object-oriented programmer, such as a C # programmer, needs to systematically learn object-oriented knowledge and object-oriented knowledge from programming languages and not be competent for object-oriented design and development.

from an example

Example scenario:

We need to design a personnel management system, one of the functions of a variety of different types of employees, the monthly salary-different types of employees, have different salary calculation system.

Structured approach

1. Access to all possible employee types in the personnel system
2. Calculate the salary according to the different salary system corresponding to the different types of staff
Enumemployeetype
{
Engineer;
Sales;
Manager;
...
}
Payroll Program Calculation
if (type = = Employeetype.engineer)
{
......
}
else if (type = = Employeetype.sales)
{
......
}

Object-oriented design

1. Design different classes based on different employee types, and make these classes inherit from an employee abstract class, with an abstract method getsalary.
2. In various categories of employees, according to their own salary system, rewrite (override) Getsalary method.
Abstract class Employee
{
...
public abstract int getsalary ();
}
Class Engineer:employee
{
...
public override int Getsalary ()
{
...
}
}
Class Sales:employee
{
...
public override int Getsalary ()
{
...
}
}
Show Payroll Programs
Employee e = emfactory.getemployee (ID);
MessageBox.Show (E.getsalary ());

Example scenario:

Now the demand has changed ... With the expansion of customer business scale, there are more types of employees, such as hourly, piecework workers ... And so on, it challenges the personnel management system--the original procedure has to change.

Structured approach

Almost all areas involving the type of employee (including, of course, "payroll procedures") need to be changed ... All of 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, rewrite the Getsalary () method, and then generate a new employee type in the Employeefactory.getemployee method based on the relevant criteria. Other places (showing payroll procedures, engineer, sales, etc.) do not require any changes.

re-understanding of object-oriented

For the previous example, from a macro perspective, object-oriented construction is more adaptable to software changes and minimizes the impact of change

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-this is more in line with the real world and
More control over the range of changes, after all, engineer class should not be for the new "hourly" to pay ...

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

With these knowledge, how to design "good object-oriented". -Follow certain object-oriented design principles
-Familiarize yourself with some typical object-oriented design patterns

from design principles to design patterns

Programming for interfaces, not for implementation

– Customers do not need to know the specific types of objects they use, just know that the object has the interface that the customer expects.

Prioritize the use of object combinations rather than class inheritance

– Class inheritance is usually "white box reuse", and the object combination is usually "black boxes reuse." Inheritance destroys encapsulation in some degree, and the coupling of subclass parent class is high, while object combination only requires a well-defined interface and low coupling degree of the grouped objects.

Package Change Point

– Use encapsulation to create a boundary layer between objects so that designers can modify them on one side of the boundary layer without adversely affecting the other side, thus enabling loose coupling between the layers.

Using refactoring to get the pattern-design pattern application should not be preconceived, on the use of design patterns is the largest misuse of design patterns. There is no one-step design pattern. "Refactoring to Patterns", which is advocated by Agile software development practice, is the best way to use design patterns universally accepted.

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 to extensions, closed for changes)

Liskov replacement principle (LSP):
– Subclasses must be able to replace their base classes

. Dependency inversion principle (DIP):

– High-level modules should not rely on low-level modules, both of which should depend on abstraction.

– Abstractions should not depend on implementation details, and implementation details should depend on abstraction.

Interface isolation principle (ISP):

– Client programs should not be forced to rely on methods they do not use.

Summary

The design pattern describes a general solution to a common problem in the software design process. Object-oriented design patterns describe the common organizational relationships among object-oriented design processes, specific scenarios, classes, and objects that communicate with each other.

To understand the object-oriented is the basis of learning the design pattern, mastering the principle of object-oriented design can grasp the essence of object-oriented design pattern, so as to realize the flexible application of design model.
Expression

Three basic object-oriented design principles-programming for interfaces, not for implementation
– Use object combinations instead of class inheritance
– The encapsulation change point uses refactoring to get the pattern. "Refactoring to Patterns", which is advocated by Agile software development practice, is the best way to use design patterns universally accepted.