Design Patterns Learning Notes (i)--object-oriented design patterns and principles

1. Concept of Design Patterns
The design pattern describes a general solution to some common problems in the software design process.

2. Object-oriented design mode
Object-oriented design patterns describe organizational relationships between classes and objects that communicate with each other. The goal is to respond to changes, improve reuse, and reduce change.

3. What is an object:
1) from the conceptual level, the object is an abstraction of some kind of owning responsibility;
2) from the specification level, the object is a series of public interfaces that can be used by other objects;
3) from a language implementation level, the object encapsulates code and data (that is, behavior and state).
If we look at the concept of the object in terms of the implementation of the code, it should be like a concrete object,
For example: Hammer, from the conceptual level, the hammer has its responsibilities, that is, what it does (to hit the nails, of course, there will be other uses, such as self-defense), from the specification level, such as the use of hammer hit nails.

4. The object-oriented design pattern has three main principles
1) interface programming, to achieve polymorphism can reduce the code changes.
For example, in "Head first Design Patterns" There is an example of a duck game. There are many kinds of ducks in the game, such as: duck, Wood duck, duck model. The first thing we would think of is an abstract class: abstract class Duck,duck has a lot of abstraction properties and methods, such as quack. This method is instantiated when we inherit from a subclass.

1  Public Abstract class duck{2      Public Abstract void Quack () 3 }

public class Mallardduck extends duck{@Overridepublic void Quack () {System.out.println ("I can Quack");}}

　　

When the program was formed, we had many kinds of ducks, and suddenly we found that some ducks would fly, and we would add an abstract method to the duck to Abstract void fly ();
So we had to add the fly implementation to all the subclasses, and some would say, if we add the fly's implementation directly in the duck, wouldn't it be necessary to add the implementation to the subclass?
Then we change the idea that if we take these methods out and turn them into duck members, it seems that the problem will be simpler.

2) Prioritize the use of object combinations rather than the inheritance of classes.
This makes it more use of "has a", less use "is a". Back to the example, considering duck and its functions in a different way, we 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 Flybehavior;
}
Now we'll come up with two kinds of ducks.
public class Modelduck:duck
{
Public Modelduck ()
{
Flybehavior = new Flynoway ();
}
}

public class Mallardduck:duck
{
Public Mallardduck ()
{
Flybehavior = new flywithwing ();
}
}
So if we add some kind of action, we don't have to work on every duck. Focus on the Ducks we care about (don't be too it, beware of bird flu, Cut! ”）。
3) Package The change point, to achieve loose coupling, this does not have to say more.
It is mentioned in the course that the design patterns used in coding are not set up at the beginning of the programming, but should be refactored to get the design pattern (refactoring to Patterns). Oh, that's the way it is, understand. have problems with coding and think about how to respond. Haha, I used to think that when we started programming, we had to specify what design patterns we used.
Let's talk about design principles:
A. Single responsibility principle (SRP): A class should have only one cause for it to change.
B. Open closure principle (OCP): class modules should be extensible and non-modifiable. To illustrate, extensions and modifications are different. For example: We want to add a modelduck, then we write a Modelduck class inherits duck, which is called the extension, not the modification. What is a modification, as we begin to say, in order to add a fly function, we want to add a different implementation of all subclasses, which is called modification.
C.liskov substitution principle: Subclasses can replace base classes.
D. Dependency inversion principle: high-level modules do not depend on low-layer modules, both of which are dependent on abstraction. Or just the example: Duck is a high-rise module, Fly is a low-level module. Duck does not depend on fly, the high-rise module changes slowly, while the lower-level modules change slowly.
Abstractions should not be dependent on implementation details, and implementation details should be dependent on abstraction. Fly is an abstraction, it does not depend on how to fly.
E. Interface isolation principle: Do not force the client program to rely on the method they do not use (it makes sense that the wood duck will not fly why to let it realize the function of flying.) ）
Finally, someone asks the difference between an interface and an abstract class:
Interfaces can inherit multiple, abstract classes can only be inherited. An interface defines a contract between components. Use an abstract class for a is a relationship.

---excerpt from http://www.cnblogs.com/kid-li/archive/2006/03/29/361899.html

Design Patterns Learning Notes (i)--object-oriented design patterns and principles