Design Patterns learning notes (I)-object-oriented design patterns and principles

Today, I attended the course "C # object-oriented design patterns (1): Object-oriented Design Patterns and Principles. Summarized some notes.
First, we will introduce what is the design pattern: the design pattern describes a general solution to a common problem in the software design process.
The following describes the object-oriented design patterns.
The object-oriented design mode describes the Organizational Relationship between classes and objects that communicate with each other. The purpose is to cope with changes, improve reuse, and reduce changes.
So what is the object:
1. In terms of concept, the object is an abstract with certain responsibilities;
2. In terms of specifications, an object is a series of public interfaces that can be used by other objects;
3. In terms of language implementation, the object is encapsulated Code And data (that is, behavior and status ).
What I understand most about these three points is the third point. This may be due to my focus on code implementation, but I ignore the idea of programming. If we look at the object concept without the implementation of the Code, it should be like a specific object, for example, the response header. At the conceptual level, the Response Header has its responsibilities, that is, what it is for (for hitting a nail, of course there will be other uses, such as anti-body), from the perspective of specifications, such as people using a finger to hit a nail.
The object-oriented design model has three principles:
1. This interface programming is not for implementation programming. Before Knowing the design pattern, I did not understand the appearance of the interface. I don't understand why nothing can be implemented. Of course, I am confused about polymorphism. In fact, I have not understood the idea of object-oriented programming. After a little understanding of the design pattern, I found that the interface is indeed a good thing. using it to implement polymorphism does reduce code modifications.
For example, there is an example in head first design patterns about a duck game. There are many types of ducks in the game, such as wild duck, wooden duck, and duck model. We will first think of an abstract class: abstract class duck, which has many abstract attributes and methods, such as quack. This method will be instantiated when we inherit from sub-classes.
Public abstract class duck
{
Public abstract void quack ()
}

Public class mallardduck: Duck
{
Public override void quack ()
{
Console. Write ("I can quack ");
}
}
When Program After the formation, we had a lot of ducks. Suddenly, we found some ducks could fly. We will add an abstract method abstract void fly () in duck (); so we have to add the fly implementation to all subclasses. Some people will say that if we directly add the fly implementation to the duck, will we not need to add the implementation to the subclass soon? The boss should ask you: you have seen the wooden duck flying all over the sky (OH, my god! The wooden duck is also flying. What is the world !). Sorry, boss. Now we have all seen it.
In this case, we have another idea. If we extract all these methods and turn them into duck members, it seems that the problem will be simpler.
Haha, it seems a little far away. Now I will take my notes.
2. Give priority to object combinations, rather than class inheritance.
In this case, "has a" is a "is not used. Haha, I want to explain the example above. From another perspective, we will consider duck and its functions. We will design a fly interface and some specific flight methods.
Public interface flybehavior
{
Void fly ();
}

Public class flywithwing: flybehavior
{
Public void fly ()
{
Console. Write ("I can fly \ n ");
}
}

Public class flynoway: flybehavior
{
Public void fly ()
{
Console. Write ("I can't fly \ n ");
}
}
Well, for duck, now it should have a (has a) Fly Method
Public abstract class duck
{
Public duck ()
{}
Public flybehavior;
}
Now let's implement two ducks.
Public class modelduck: Duck
{
Public modelduck ()
{
Flybehavior = new flynoway ();
}
}

Public class mallardduck: Duck
{
Public mallardduck ()
{
Flybehavior = new flywithwing ();
}
}
In this way, if we add some behavior, we don't have to work on every kind of duck. Focus on the Duck breed we care about (don't pay too much attention to, be careful with the bird flu, "achai !").
3. encapsulate the change point to achieve loose coupling.
As mentioned in the course, the use of design patterns in coding is not defined at the beginning of programming, but should be reconstructed to get the design pattern (refactoring to patterns ). Oh, it turns out to be so nice to understand. Problems encountered in coding, and then think about how to deal with them. Haha, I thought that when we started programming, we specified what design patterns we used.
The following describes the design principles:
1. Single Responsibility Principle (SRP): A class should have only one reason for its change.
2. Open and closed principle (OCP): class modules should be extensible and cannot be modified. The extension and modification are different here. For example, if we want to add a modelduck, We will write a modelduck class to inherit duck, which is called extension, not modification. What is modification, as we started to talk about it. To add a fly function, we need to add different implementations to all subclasses. This is called modification.
3. liskov replacement principle: subclasses can replace base classes.
4. Dependency inversion principle: High-Level modules do not depend on low-level modules, and both rely on abstraction. In another example, duck is a high-level module and fly is a low-level module. Duck does not rely on fly. Changes to the upper-level modules are slow, while changes to the lower-level modules are slow.
Abstraction should not depend on implementation details, but on abstraction. Fly is an abstraction that does not depend on how to fly.
5. Interface isolation principle: Do not force customer programs to rely on methods they do not need (it makes sense that the wooden duck won't fly Why should it implement the flying function .)
Finally, the difference between the question interface and the abstract class is as follows:
Interfaces can be inherited. abstract classes can only be inherited. Interface defines the contract between components. Use an abstract class as a is a relation.