Getting started with design patterns-principles of design patterns

Principles of design patterns
1. "Open-Close" principle-the module should be open for extension, but should be closed for modification.
2. Rys replacement principle-if the parent class is called, the replacement of the Child class can be completely run. The Li's replacement principle is a basis for inheritance and reuse.
3. Merging Reuse Principle-less inheritance and more synthesis relationships are required.
4. Dependency inversion principle-Abstraction should not be dependent on details, but details should be dependent and abstract.
Programming for interfaces, rather than implementing programming.
5. Interface isolation principle-each interface should be a type of role. There are not many roles that should not be done, and everything should be done.
6. abstract classes
7. The dimit rule-the minimum knowledge principle. Do not talk to strangers.

Design pattern is a set of design pattern that is repeatedly used, known to most people, and classified,CodeSummary of design experience. The design pattern is used to make code reusable, make it easier for others to understand, and ensure code reliability.

There is no doubt that the design model is a win-win solution for others and the system. The design model enables code compilation to be truly engineered. The design model is the foundation of software engineering, just like the building blocks.

Gof's "Design Pattern" is the first time that it has elevated the design pattern to a theoretical level and standardized it. This book has proposed 23 basic design patterns. Since then, during the development of reusable object-oriented software, a large number of new design patterns are emerging.

I. Design Model and framework

Currently, reusable object-oriented software systems are generally divided into three categories: ApplicationsProgramToolbox and framework. The specific software we develop at ordinary times is an application; Java API is a toolbox; the framework is a group of collaborative classes that constitute a type of reusable design for specific software. EJB (enterprisejavabeans) is a Java framework applied to enterprise computing.

The framework usually defines design parameters such as the relationship between the overall structure class and object of the application system, so that specific application implementers can focus on specific details of the application. The framework mainly records the common design decisions in software applications, and emphasizes design reuse. Therefore, the design model must be used in the framework design.

In addition, the design patterns help you understand the framework structure. Mature frameworks usually use multiple design patterns. If you are familiar with these design patterns, you will no doubt be able to quickly master the structure of the Framework, if developers suddenly come into contact with ejbj2ee and other frameworks, they will feel particularly difficult to learn and master. Instead, they will first master the design mode, which is undoubtedly a powerful tool for you to analyze the EJB or J2EE system.

Ii. Principles of design patterns

In recent years, everyone has begun to pay attention to the design model. So why should we use the design pattern? Why are so many design patterns designed? To be honest, I have never figured it out before. It's just a look at everyone's "design pattern", and the heart is a bit weak. So I bought the design model of the "four-person gang". The results showed that I understood it clearly. I forgot it later. It may be because I am relatively "stupid" :)) recently, I have some insights. "Joy is better than joy". I 'd like to share it with you and hope to give you some advice!
Why do we advocate "Design Pattern? The root cause is to reuse code and increase maintainability. So how can we achieve code reuse? OO has several principles of its predecessors: "open-closed" principle (open closed principal), Rishi replacement principle, and synthetic Reuse Principle. The design pattern is to achieve these principles, so as to achieve code reuse and increase maintainability.

1. "Open-Close" Principle

This principle was proposed by "Bertrand Meyer. Original article: "software entities shocould be open for extension, but closed for modification ". That is to say, the module should be open for expansion, but closed for modification. The module should be extended without modifying the original (original) code. How can we scale it out? Let's look at the factory model "factory pattern": Suppose Zhongguancun has a hacker who sells pirated disk and wool film. We designed a "CD sales management software" for him ". We should first design a "cd" interface.
[Pre] ______________
| <> |
| Cd |
| _____________ |
| + Sell () |
|
| _____________ | [/PRE]
The pirated disk and the wool film are its sub-categories. The kid manages these CDs through "discfactory. Code:

Public class discfactory {
Public static disc getdisc (Java/lang/string.java.html "target =" _ blank "> string name ){
Return (CD) Java/lang/class.java.html "target =" _ blank "> class. forname (name). getinstance ();
}
}
How can someone buy a pirated disk?

Public class kiddies {
Public static void main (Java/lang/string.java.html "target =" _ blank "> string [] ARGs ){
CD d = discfactory. getdisc ("pirated disk ");
CD. Sell ();
}
}

If one day, this kid finds his conscience and starts selling genuine software. It doesn't matter. We just need to create another sub-category "genuine software" of "cd. You do not need to modify the original structure and code. How is it? For extension development, disable modification. "Open-closed principle"
The factory model is to expand specific products. Some projects may require more scalability. To expand the "Factory", it becomes an "Abstract Factory model ".

2. Lee's replacement principle

The Li's replacement principle was proposed by "Barbara liskov. If the parent class is called, the sub-classes can be fully run. For example:
CD d = new pirated disk ();
D. Sell ();
Now I want to change the category of "pirated disk" to "fake disk". No problem, it can be fully run. The Java compiler checks whether the program complies with the Li's replacement principle. Do you still remember a principle inherited by Java? The access permission of the subclass overload method cannot be less than that of the method corresponding to the parent class. For example, if the "sell" access permission in "cd" is "public", the "sell" method in "pirated disk" and "Mao film" cannot be package or private, and compilation cannot pass. Why? You think: if the "selling" method of "pirated disk" is private. The following code cannot be executed:
CD d = new pirated disk ();
D. Sell ();
It can be said that the Li's replacement principle is a basis for inheritance reuse.

3. Principles of merging and reuse

That is to say, we need to use less inheritance and more synthesis relationships. I once wrote a program like this: There are several classes that need to deal with the database, so I wrote a database operation class, and other classes dealing with the database inherit this class. As a result, I modified a method of the database operation class, and each class needs to be modified. "Pull your whole body "! Object-oriented is to limit fluctuations to the smallest possible range.

In Java, you should try to program interfaces instead of implementing classes. In this way, changing the subclass does not affect the code that calls its method. We need to keep every category in touch with others as little as possible, "Don't talk to strangers ". In this way, the fire in the city will not affect the fish in the pool. Scalability and maintainability can be improved

After understanding these principles, let's look at the design model, just how to implement these principles on specific issues. Zhang Wuji learned Taijiquan. He forgot all his tricks and knocked down Xuan Mi, the so-called "No tricks in his mind ". The design pattern can be described as a trick. If you learn all kinds of patterns first, and forget all the patterns and do what you want, it can be described as the highest level of OO. Haha, funny, funny! (JR)

4. Dependency reversal Principle

Abstraction should not be dependent on details, but details should be dependent and abstract.

Programming for interfaces, rather than implementing programming.

PASS Parameters, or reference classes with high levels as much as possible in composite aggregation relationships.

We can dynamically create various specific objects when constructing objects. Of course, if some specific classes are stable, you do not have to create an abstract class as its parent class, this gives you the feeling of tongue-filling.

5 interface isolation principles

In the example of customized services, each interface should be a role, not many, and should not do anything that should not be done.

6 abstract classes

The abstract class does not have instances. It is generally inherited as a Child class of the parent class and generally contains the common attributes and methods of this series.

Note: In a good inheritance relationship, only leaf nodes are specific classes, and other nodes should be abstract classes, that is, specific classes

Is not inherited. Put as much common code as possible into the abstract class.

7 dumit's Law

Minimum knowledge principle. Do not talk to strangers.

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/Cnami/archive/2008/07/18/2675147.aspx