Software Design essential "SOLID principles"

Original  unknown bug  Finally, a bug in   February 21

01SOLID Introduction Principles

    In our software design and maintenance process of the total need to constantly change the code, or when necessary, we also need to modify our design, let alone led to other engineers to maintain embarrassing territory code, then must be between engineers a set of principles designed to maintain a good code. So "SOLID principles" will send in handy, so much that it is in principle not be said to be an ideal target it! Because basically difficult to have code that can fully satisfy it.

    "SOLID" is actually five kinds of software design principles was the first letter of the name, they are:

    “Single Responsibility Principle”;

    "Open Closed Principle";

    "Liskov Substitution Principle ";

    "Interface Segregation Principle";

    "Dependency Inversion Principle"。

    The meaning of the English word are generally: single responsibility principle, the principle of opening and closing, the Liskov substitution principle, the principle of separation of the interface, dependent on the principle. So really necessary, single responsibility is the module package, the substitution principle should be that flexibility, portability, and so the interface is, I am here just simple to understand, and then later in a detailed chat with each principle.

02 Single Responsibility Principle

    Well it understood from the literal meaning, that is, the single function of our data and functions. Such modularity facilitates the one hand, but also make the module more cohesive!

    For example, a cashier in charge of the money is good, the waiter is responsible for the guests, so clear division of labor will be able to better deal with the problem on a couple and programming.

03 Open Closed Principle

    We may first feel and not well understood meaning of the principle, saying "open for extension but closed for modification" that we have to add new code to extend our functional modules, instead of modifying the current code be compatible with the previous code.

    After the point is simply to put it another function code should not modify existing customers and normal use, but new demands of customers, we work together for customer service by adding code and the old code. On the one hand this can shorten the testing process, while ensuring the stability of the old functions. For example, we can send messages through the serial communication send, can also can communicate send, then the next time we need to add communication at that time, only need to add a type of communication types, while adding the corresponding Send to!

04Liskov substitution principle

    The main principle is to replace an ideological change does not change the underlying, when we need to achieve top new features of our underlying interfaces generally do not need to be modified, but to achieve new upper application with existing interface, in fact, we are required during the development of low-level interface, when the middle interface should also have the relevant capabilities of the underlying interface to upper layers.

    For example, we report to you that your subordinates a 1-2-3 something, you probably summed up the matter in accordance with point 4 1-2-3 something, this time you need to be able to 1-2-3-4 report your boss, it is the only comprehensive.

05 Connector principle of separation

    Simply put, the more simple the interface is better, sometimes we appear a lot in order to interface to the user interface is fully open, this is not necessary, because some user interfaces do not have access, we need to simplify the interface to classify, separation of interface according to user needs! It makes the interface more easily portable and used!

06 Dependency Inversion Principle

    That we should not rely on the top of an object or specific, and should depend on an abstract class!

    For instance, we want to develop a communication protocol, the protocol should not rely on this serial device object, but should rely on a common communications, for example, rely Open / Send / Receive and so on.

    Well, here is the public number "last bug", where only a simple introduction about this design, follow-up and then to practical examples parse! You for your concern!

Guess you like

Origin www.cnblogs.com/CodeWorkerLiMing/p/12633983.html