C # Basic Principles of the design model (3)

Iii. Dependency inversion principle (DIP)

Dependence inversion principle: It depends on abstraction and not on specifics.

In short, the dependency inversion principle requires the client to rely on abstract coupling. Principles:

Abstraction should not depend on details; details should depend on abstraction;
Programming for interfaces is not implemented.

Negative example:

 

Disadvantage: If the coupling is too tight, changing light will affect toggleswitch.

Solution 1:
Abstract light and inherit the class from light.

 

Advantage: toggleswitch depends on the abstract class light and has higher stability. bulblight and tubelight inherit from light and can be extended according to the "open-closed" principle. As long as the light does not change, the changes between bulblight and tubelight will not affect toggleswitch.

Disadvantage: it is very difficult to use toggleswitch to control a TV. TV cannot be inherited from light.

Solution 2:
 

Advantage: it is more general and stable.

Conclusion:
The dependency relationships created by traditional procedural programming are dependent on details, which is poor because the policies are affected by changes in details. The dependency inversion principle makes the details and policies depend on abstraction. The stability of abstraction determines the stability of the system.

Iv. Interface isolation principle (ISP)

Interface segregation principle: it is better to use multiple special interfaces than to use a single total interface. In other words, from the perspective of a customer class: the dependence of a class on another class should be based on the minimum interface.

An interface that is too bloated is a pollution to the interface. Customers should not be forced to rely on methods they do not need.

My object-oriented umbrella (from design patterns explained)

Let me tell you about my great umbrella. It is large enough to get! In fact, three or four other people can get in it with me. while we are in it, staying out of the rain, I can move it from one place to another. it has a stereo system to keep me entertained while I stay dry. amazingly enough, it can also condition the air to make it warmer or colder. it is one cool umbrella.

My umbrella is convenient. it sits there waiting for me. it has wheels on it so that I do not have to carry it around. I don't even have to push it because it can propel itself. sometimes, I will open the top of my umbrella to let in the sun. (Why I am using my umbrella when it is sunny outside is beyond me !)

In Seattle, there are hundreds of thousands of these umbrellas in all kinds of colors. Most people call them cars.

Implementation Method:
1. Use the delegate separation Interface
2. Use multiple inheritance and separation Interfaces

5. Principles of synthesis/aggregation multiplexing (CARP)

Composite/aggregate Reuse Principle or carp is often referred to as Composite Reuse Principle or CRP ), it is to use some existing objects in a new object to make it a part of the new object. New objects reuse existing functions by delegating these objects.

In short, we should try to use synthesis/aggregation instead of inheritance.

O design to interfaces.
O favor composition over inheritance.
O find what varies and encapsulate it.
(From: Design Patterns explained)

Distinguish between "has-a" and "is-"

"Is-a" is strictly defined in the taxonomy meaning that one class is another class "one ". "Has-a" is different. It indicates that a role has a certain responsibility.

One common cause of incorrect inheritance rather than merging/aggregation is that "has-a" is treated as "is-".

For example:
 

In fact, employees, managers, and students describe a role. For example, if a person is a "manager", it must be "employee", and another person may be "Student employee". In the above design, A person cannot have multiple roles at the same time. If he is an "employee", he cannot be a "student". This is obviously unreasonable.

The error is caused by confusion between the "role" level structure and the "person" level structure, and mistaken "has-a" as "is-". Solution:

 

Vi. dumit rules)

The law of Demeter (or the short-cut level of measure) is also called the least knowledge principle (least knowledge principle or LKP). That is to say, an object should have as little knowledge as possible about other objects.

Other statements:
Only communicate with your friends
Do not talk to "Strangers"
Each software organization has only the minimum knowledge of other units and is limited to software units closely related to the same unit.

Dimit rules and Design Patterns
Facade mode and mediator Mode

Make people ignorant
The third chapter of Lao Tzu said: "It is based on the governance of saints, and lacks its heart, its belly, and its ambition. It often makes the people ignorant and heartless. The "Ignorance" of the "ruling" object is in the "Ignorance" state, which can reduce the cost of "ruling.
The so-called "Minimum knowledge" principle is actually the rule of Lao Tzu's "ignorance of the people.

Transactions
Lao Tzu cloud: "little country, few people ...... Neighboring countries look at each other and hear each other from each other. "Isolate the ruled objects so that they do not have direct communication, which can achieve the effect of splitting and then divide and conquer them separately. The dimit rule coincides with Lao Tzu's "little country and few people" rule.

 

References:
Min Hong, Java and mode, e-Industry Press
[Us] James W. Cooper, C # design model, Electronic Industry Press
[Us] Alan shalloway James R. Trott, design patterns explained, China Power Press
[Us] Robert C. Martin, Agile Software Development-principles, models and practices, Tsinghua University Press
[Us] Don box, Chris sells, 1st. Net essence: Public Language Runtime Library, China Power Press
Http://www.dofactory.com/Patterns/Patterns.aspx