Beyond design Patterns: Deep discussion of design principles beyond design patterns

The basis of reusable object-oriented software-design mode, with its reusable design intention, ingenious logical thinking by the vast number of object-oriented program design is sought after. But many programmers often turn the question of thinking into what patterns they encounter. This kind of confucianism、the thinking has seriously influenced the artistry of the program design in some degree, and solidified the idea of the programmer, which violates the original intention of the designing mode. In this paper, the author sums up the core idea behind the design pattern, and puts forward several key design principles, such as interface-oriented, encapsulation change, dependency inversion principle, chatting with friends only. Programmers only need to follow these principles in programming, and they will find that some design patterns are already in use.

Introduction questions

GOF Design Model After the launch, by the enthusiastic pursuit of programmers, many programmers are very happy to bury their heads and even recite its 23 design patterns, and to be familiar with the design pattern and proud. However, in the actual program design, many programmers have not been able to apply the design pattern to their own scene. There are many reasons why design patterns are so much that they are often confused; the design pattern scenario is too restrictive or the programmer is unaware of the application. Combined with a variety of reasons, the root causes only one, the programmer does not understand thoroughly, proficient in the application of design patterns of the core ideas. The author thinks, the design pattern is not the rules and regulations, the design pattern is not simple 23 kinds. The design pattern manifests one kind of thought is: As far as possible reuse, but realizes the reusable means to have no outside the author summarizes several design principles.

Completely forget the design pattern of GOF, programming should be an art, not a constrained pattern.

Principle One: Package change

The core idea of the principle is to find out where the application may need to change in the program design, to separate them so that they can be easily modified or expanded, without affecting the parts that don't need to change. In fact, if you go back and read the book of design patterns, you'll find that encapsulation changes are almost the spirit behind each design pattern. All patterns provide a way for a part of the system to change without affecting other parts.

As a simple example, we build a car base class with two inheriting classes Benz and BMW, as detailed in Figure 1 below:

Figure 1. First implementation of car

I'm sure most people will design this, but what's wrong with this design? We look at the problem needs to develop the vision, if the technology development, all the car can fly, how to do? Some people say, very simple, give car add a protected fly () method, so that Benz and BMW can fly, inherit really great! OK, so if I need to build another car toy cart (toycar), we know that the toy car can run, but not fly. What to do? Still good to do, we can overload the toy car fly method, let them do nothing. Well, another subclass is coming, model car (MODELCAR). Model cars can not run, can not fly, good to do, continue to overload their methods. See Figure 2 below:

Figure 2. The second implementation of the car

What if we have more of the car's subclasses? Does it feel a little cumbersome, yes, we need to overload too many methods.