ASP.NET 设计模式中依赖倒置原则

依赖倒置原则

A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。

B.抽象不应该依赖于具体，具体应该依赖于抽象。

依赖倒置原则

A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。

B.抽象不应该依赖于具体，具体应该依赖于抽象。

目录


1概述


2意图


3代码实现


4结构图

1概述编辑

所谓依赖倒置原则（Dependence Inversion Principle）就是要依赖于抽象，不要依赖于具体。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

2意图编辑

面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。

面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的耦合度。

面向过程思想的结构图：

图一

背景1：公司是福特和本田公司的金牌合作伙伴，现要求开发一套自动驾驶系统，只要汽车上安装该系统就可以实现无人驾驶，该系统可以在福特和本田车上使用，只要这两个品牌的汽车使用该系统就能实现自动驾驶。于是有人做出了分析如图一。

对于图一分析：我们定义了一个AutoSystem类，一个FordCar类，一个HondaCar类。FordCar类和HondaCar类中各有三个方法:Run(启动Car)、Turn(转弯Car)、Stop(停止Car)，当然了一个汽车肯定不止这些功能，这里只要能说明问题即可。AutoSystem类是一个自动驾驶系统，自动操纵这两辆车。

3代码实现编辑


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

publicclassHondaCar{

publicvoidRun()

{

Console.WriteLine("本田开始启动了");

}

publicvoidTurn()

{

Console.WriteLine("本田开始转弯了");

}

publicvoidStop()

{

Console.WriteLine("本田开始停车了");

}

}

publicclassFordCar

{

publicvoidRun()

{

Console.WriteLine("福特开始启动了");

}

publicvoidTurn()

{

Console.WriteLine("福特开始转弯了");

}

publicvoidStop()

{

Console.WriteLine("福特开始停车了");

}

}

publicclassAutoSystem

{

publicenumCarType{Ford,Honda};

privateHondaCarhcar=newHondaCar();

privateFordCarfcar=newFordCar();

privateCarTypetype;

publicAutoSystem(CarTypetype)

{

this.type=type;

}

privatevoidRunCar()

{

if(type==CarType.Ford)

{

fcar.Run();

}

else

{

hcar.Run();

}

}

privatevoidTurnCar()

{

if(type==CarType.Ford)

{

fcar.Turn();

}

else

{

hcar.Turn();

}

}

privatevoidStopCar()

{

if(type==CarType.Ford)

{

fcar.Stop();

}

else

{

hcar.Stop();

}

}

}

代码分析：上面的程序确实能够实现针对Ford和Honda车的无人驾驶，但是软件是在不断变化的，软件的需求也在不断的变化。

背景2：公司的业务做大了，同时成为了通用、三菱、大众的金牌合作伙伴，于是公司要求该自动驾驶系统也能够安装在这3种公司生产的汽车上。于是我们不得不变动AutoSystem：


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

publicclassAutoSystem

{

publicenumCarType{Ford,Honda,Bmw};

HondaCarhcar=newHondaCar();

FordCarfcar=newFordCar();

BmwCarbcar=newBmwCar();

privateCarTypetype;

publicAutoSystem(CarTypetype)

{

this.type=type;

}

privatevoidRunCar()

{

if(type==CarType.Ford)

{

fcar.Run();

}

elseif(type==CarType.Honda)

{

hcar.Run();

}

elseif(type==CarType.Bmw)

{

bcar.Run();

}

}

privatevoidTurnCar()

{

if(type==CarType.Ford)

{

fcar.Turn();

}

elseif(type==CarType.Honda)

{

hcar.Turn();

}

elseif(type==CarType.Bmw)

{

bcar.Turn();

}

}

privatevoidStopCar()

{

if(type==CarType.Ford)

{

fcar.Stop();

}

elseif(type==CarType.Honda)

{

hcar.Stop();

}

elseif(type==CarType.Bmw)

{

bcar.Stop();

}

}

}

分析：这会给系统增加新的相互依赖。随着时间的推移，越来越多的车种必须加入到AutoSystem中，这个“AutoSystem”模块将会被if/else语句弄得很乱，而且依赖于很多的低层模块，只要低层模块发生变动，AutoSystem就必须跟着变动，

它最终将变得僵化、脆弱。

导致上面所述问题的一个原因是，含有高层策略的模块，如AutoSystem模块，依赖于它所控制的低层的具体细节的模块（如HondaCar()和FordCar()）。如果我们能够找到一种方法使AutoSystem模块独立于它所控制的具体细节，那么我们就可以自由地复用它了。我们就可以用这个模块来生成其它的程序，使得系统能够用在需要的汽车上。OOD给我们提供了一种机制来实现这种“依赖倒置”。

4结构图编辑

图二

看图 2中这个简单的类图。这儿有一个“AutoSystem”类，它包含一个“ICar”接口。这个“AutoSystem”类根本不依赖于“FordCar”和“HondaCar”。所以，依赖关系被“倒置”了：“AutoSystem”模块依赖于抽象，那些具体的汽车操作也依赖于相同的抽象。

于是可以添加ICar


1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

publicinterfaceICar

{

voidRun();

voidTurn();

voidStop();

}

publicclassBmwCar:ICar

{

publicvoidRun()

{

Console.WriteLine("宝马开始启动了");

}

publicvoidTurn()

{

Console.WriteLine("宝马开始转弯了");

}

publicvoidStop()

{

Console.WriteLine("宝马开始停车了");

}

}

publicclassFordCar:ICar

{

publicvoidRun()

{

Console.WriteLine("福特开始启动了");

}

publicvoidTurn()

{

Console.WriteLine("福特开始转弯了");

}

publicvoidStop()

{

Console.WriteLine("福特开始停车了");

}

}

publicclassHondaCar:ICar

{

publicvoidRun()

{

Console.WriteLine("本田开始启动了");

}

publicvoidTurn()

{

Console.WriteLine("本田开始转弯了");

}

publicvoidStop()

{

Console.WriteLine("本田开始停车了");

}

}

publicclassAutoSystem

{

privateICaricar;

publicAutoSystem(ICaricar)

{

this.icar=icar;

}

privatevoidRunCar()

{

icar.Run();

}

privatevoidTurnCar()

{

icar.Turn();

}

privatevoidStopCar()

{

icar.Stop();

}

}

现在AutoSystem系统依赖于ICar 这个抽象，而与具体的实现细节HondaCar、FordCar、BmwCar无关，所以实现细节的变化不会影响AutoSystem。对于实现细节只要实现ICar 即可，即实现细节依赖于ICar 抽象。

综上：

一个应用中的重要策略决定及业务模型正是在这些高层的模块中。也正是这些模型包含着应用的特性。但是，当这些模块依赖于低层模块时，低层模块的修改将会直接影响到它们，迫使它们也去改变。这种境况是荒谬的。应该是处于高

层的模块去迫使那些低层的模块发生改变。应该是处于高层的模块优先于低层的模块。无论如何高层的模块也不应依赖于低层的模块。而且，我们想能够复用的是高层的模块。通过子程序库的形式，我们已经可以很好地复用低层的模块了。当高层的模块依赖于低层的模块时，这些高层模块就很难在不同的环境中复用。但是，当那些高层模块独立于低层模块时，它们就能很简单地被复用了。这正是位于框架设计的最核心之处的原则。

总结：依赖倒置原则

A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。

B.抽象不应该依赖于具体，具体应该依赖于抽象。

ASP.NET 设计模式中依赖倒置原则,布布扣,bubuko.com

时间： 2024-11-13 04:08:44

ASP.NET 设计模式中依赖倒置原则的相关文章

设计模式-1依赖倒置原则示例

public interface ICar {    public void run();} public interface IDriver {    public void drive();} public class Benz implements ICar {        public void run() {        System.out.println("奔驰车在跑");    }} public class BMW implements ICar{       

面象对象设计6大原则之五：依赖倒置原则

依赖倒置原则(DIP),The Dependency Inversion Principle 定义 1.高层模块不应该依赖低层模块,两都应该依赖于抽象. 2.抽象不依赖于具体细节. 3.具体细节应该依赖于抽象. 抽象就是指接口或者抽象类,细节是指实现接口或者抽象类的具体实现类. 也就是说模块之间的依赖通过接口或抽象发生的,两个实现细节之间不能直接发生依赖,接口不能依赖实现,实现应该依赖抽象. 我们在进行分布式系统开发时,比如常用的dubbo框架,各个系统的连接都是通过接口发生的,只要依赖对方的接

设计模式六大原则： 老板是如何减轻负担的 -- 依赖倒置原则

很多创业公司都对外宣称"扁平化管理",什么是"扁平化管理"呢?请看下面这张架构图: 因为人少,老板直接管理着采购.销售.人力跟 IT 等人员,虽然累了点,但部门少.人不多也还好. 但是随着公司规模发展,每次新加入人员老板都要去认识.沟通,出现问题还得去约出去喝个茶,老板发现自己的时间都浪费在这些琐事,容易耽搁事不说,还发挥不出更大价值. 这时他决定招一些经理替自己分别管理各个部门,自己只要管理这些经理就好了. 于是新的架构图是这样的: 老板这下子省心多了,有问题直接

设计模式六大原则（3）--依赖倒置原则

定义: 高层次的模块不应该依赖于低层次的模块,两者都应该依赖于抽象接口:抽象接口不应该依赖于具体实现.而具体实现则应该依赖于抽象接口.依赖倒置原则英文全称为Dependence Inversion Principle,简称为DIP. 问题由来: 类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案: 将类A修改为依赖接口I,类B和

设计模式六大原则（3）：依赖倒置原则(转载)

设计模式六大原则(3):依赖倒置原则 定义:高层模块不应该依赖低层模块,二者都应该依赖其抽象:抽象不应该依赖细节:细节应该依赖抽象. 问题由来:类A直接依赖类B,假如要将类A改为依赖类C,则必须通过修改类A的代码来达成.这种场景下,类A一般是高层模块,负责复杂的业务逻辑:类B和类C是低层模块,负责基本的原子操作:假如修改类A,会给程序带来不必要的风险. 解决方案:将类A修改为依赖接口I,类B和类C各自实现接口I,类A通过接口I间接与类B或者类C发生联系,则会大大降低修改类A的几率. 依赖倒置原则

C#软件设计——小话设计模式原则之：依赖倒置原则DIP

前言:很久之前就想动笔总结下关于软件设计的一些原则,或者说是设计模式的一些原则,奈何被各种bootstrap组件所吸引,一直抽不开身.群里面有朋友问博主是否改行做前端了,呵呵,其实博主是想做“全战”,即各方便都有战斗力.关于设计模式,作为程序猿的我们肯定都不陌生.博主的理解,所谓设计模式就是前人总结下来的一些对于某些特定使用场景非常适用的优秀的设计思路,“前人栽树,后人乘凉”,作为后来者的我们就有福了,当我们遇到类似的应用场景的时候就可以直接使用了.关于设计模式的原则,博主将会在接下来的几篇里面

读秦小波老师《设计模式之禅》问一-依赖倒置原则

这本<设计模式之禅>得来不易,当时是在CSDN的论坛中向秦小波老师提问有幸获得的.读这种经典书籍不能如读小说,逛十里洋场意在消遣,更多的应该是边读变问,每到重点就应该问为什么.秦小波老师的语言有时幽默,有时又切中要害,引人深思.对于"倒置"秦小波老师是从人的思维层面解读的,生活中,例如张三就依赖他家的宝马上下班,也许可以更具体到BMW 740Li,然后回归到程序中,如果我们这样去构建依赖关系,那么如果哪天张三发达了,换了玛莎拉蒂,那是不是整个程序都得改,这个时候我们可以让张

学习设计模式 - 六大基本原则之依赖倒置原则

设计模式总共有六大基本原则,统称为SOLID (稳定)原则,分别是S-单一职责原则(Single Responsibility Principle), O-开闭原则(Open closed Principle),L-里氏替换原则(Liskov Substitution Principle),L-迪米特法则(Law of Demeter),I-接口隔离原则(Interface Segregation Principle),D-依赖倒置原则(Dependence Invension Principl

增删改查也有设计模式——依赖倒置原则另解

一个增删改查的例子解读面向接口编程和依赖倒置原则 依赖倒置原则介绍 依赖倒置原则包括两个部分 .高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象. 抽象不应该依赖于具体实现,具体实现应该依赖于抽象. 例子 现在有如下场景和需求:老板要求设计任务模块,包括发布任务和撤回任务等.假设这个需求只给了几个小时去做,那肯定是来不及设计了,写到哪算哪.定义撤回接口的控制层如下 @RequestMapping('cancel') @ResponseBody public String cancelT