单一职责原则
单一职责原则（SRP：Single responsibility principle）又称单一功能原则，面向对象五个基本原则（SOLID）之一。它规定一个类应该只有一个发生变化的原因。该原则由罗伯特·C·马丁（Robert C. Martin）于《敏捷软件开发：原则、模式和实践》一书中给出的。马丁表示此原则是基于
汤姆·狄马克(Tom DeMarco)和Meilir Page-Jones的著作中的
内聚性原则发展出的。
所谓职责是指类变化的原因。如果一个类有多于一个的动机被改变，那么这个类就具有多于一个的职责。而单一职责原则就是指一个类或者模块应该有且只有一个改变的原因。
一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就
耦合
在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响
复用性
。例如：要实现逻辑和界面的分离。
如果一个类承担的职责过多，就等于把这些职责
耦合在一起了。一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当发生变化时，设计会遭受到意想不到的破坏。而如果想要避免这种现象的发生，就要尽可能的遵守单一职责原则。此原则的核心就是
解耦和增强
内聚性。
问题由来
之所以会出现单一职责原则就是因为在软件设计时会出现以下类似场景：
T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。也就是说职责P1和P2被
耦合在了一起。
产生原因
职责扩散：因为某种原因，某一职责被分化为
颗粒度更细的多个职责了。
解决办法
遵守单一职责原则，将不同的职责封装到不同的类或模块中。
单一职责原则并不是一个孤立的
面向对象设计原则，它是面向对象设计五个基本原则（SOLID）之一。这些原则是：单一职责原则、
开闭原则、
接口隔离原则、
里氏替换原则和
依赖倒置原则。这些原则被一起应用时可以使一个软件系统更易被维护和扩展。这些原则被典型的应用在测试驱动开发上，并且是
敏捷开发以及自适应软件开发等指导思想的重要组成部分。
开放封闭原则
开放封闭原则（OCP，Open Closed Principle）是所有面向对象原则的核心。软件设计本身所追求的目标就是封装变化、降低耦合，而开放封闭原则正是对这一目标的最直接体现。其他的设计原则，很多时候是为实现这一目标服务的，例如以Liskov替换原则实现最佳的、正确的继承层次，就能保证不会违反开放封闭原则。
关于开放封闭原则，其核心的思想是：
软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。
因此，开放封闭原则主要体现在两个方面：
对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。
对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。
“需求总是变化”、“世界上没有一个软件是不变的”，这些言论是对
软件需求最经典的表白。从中透射出一个关键的意思就是，对于
软件设计者来说，必须在不需要对原有的系统进行修改的情况下，实现灵活的系统扩展。而如何能做到这一点呢？
只有依赖于抽象。实现开放封闭的核心思想就是对
抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以对修改就是封闭的；而通过
面向对象的继承和对多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。这是实施开放封闭原则的基本思路，同时这种机制是建立在两个基本的设计原则的基础上，这就是Liskov替换原则和合成/聚合复用原则。
对于违反这一原则的类，必须进行重构来改善，常用于实现的设计模式主要有Template Method模式和Strategy模式。而封装变化，是实现这一原则的重要手段，将经常发生变化的状态封装为一个类。
站在银行窗口焦急等待的用户，在长长的队伍面前显得无奈。所以，将这种无奈迁怒到银行的头上是理所当然的，因为银行业务的管理显然有不当之处。银行的业务人员面对蜂拥而至的客户需求，在排队等待的人们并非只有一种需求，有人存款、有人转账，也有人申购基金，繁忙的业务员来回在不同的需求中穿梭，手忙脚乱的寻找各种处理单据，电脑系统的功能模块也在不同的需求要求下来回切换，这就是一个发生在银行窗口内外的无奈场景。而我每次面对统一排队的叫号系统时，都为前面长长的等待人群而叫苦，从梳理银行业务员的职责来看，在管理上他们负责的业务过于繁多，将其对应为
软件设计来实现，你可以将这种拙劣的设计表示如图1所示。
按照上述设计的思路，银行业务员要处理的工作，是以这种方式被实现的：
class BusyBankStaff
{
private BankProcess bankProc = new BankProcess();
// 定义银行员工的业务操作
public void HandleProcess(Client client)
{
switch (client.ClientType)
{
case "存款用户":
bankProc.Deposit();
break;
case "转账用户":
bankProc.Transfer();
break;
case "取款户":
bankProc.DrawMoney();
break;
}
}
}
这种设计和实际中的银行业务及其相似，每个BusyBankStaff（“繁忙的”业务员）接受不同的客户要求，一阵手忙脚乱的选择处理不同的操作流程，就像示例代码中的实现的Switch规则，这种被动式的选择造成了大量的时间浪费，而且容易在不同的流程中发生错误。同时，更为严重的是，再有新的业务增加时，你必须修改BankProcess中的业务方法，同时修改Switch增加新的业务，这种方式显然破坏了原有的格局，以设计原则的术语来说就是：对修改是开放的。 以这种设计来应对不断变化的银行业务，工作人员只能变成BusyBankStaff了。分析这种僵化的代码，至少有以下几点值得关注：银行业务封装在一个类中，违反单一职责原则；有新的业务需求发生时，必须通过修改现有代码来实现，违反了开放封闭原则。
解决上述麻烦的唯一办法是应用开放封闭原则：对扩展开放，对修改封闭。我们回到银行业务上看：为什么这些业务不能做以适应的调整呢？每个业务员不必周旋在各种业务选项中，将存款、取款、转账、外汇等不同的业务分窗口进行，每个业务员快乐地专注于一件或几件相关业务，就会轻松许多。综合应用单一职责原则来梳理银行业务处理流程，将职责进行有效的分离；而这样仍然没有解决业务自动处理的问题，你还是可以闻到僵化的坏味道在系统中弥漫。
应用开放封闭原则，可以给我们更多的收获，首先将银行系统中最可能扩展的部分隔离出来，形成统一的接口处理，在银行系统中最可能扩展的因素就是业务功能的增加或变更。对于业务流程应该将其作为可扩展的部分来实现，当有新的功能增加时，不需重新梳理已经形成的业务接口，然后再整个系统要进行大的处理动作，那么怎么才能更好的实现
耦合度和灵活性兼有的双重机制呢？
答案就是抽象。将业务功能抽象为接口，当业务员依赖于固定的抽象时，对于修改就是封闭的；而通过继承和多态机制，从抽象体派生出新的扩展实现，就是对扩展的开放。
依据开放封闭原则，进行重构，新的设计思路如图2所示。
图2 面向抽象的设计
按照上述设计实现，用细节表示为：
interface IBankProcess
{
void Process();
}
然后在隔离的接口上，对功能进行扩展，例如改造单一职责的示例将有如下的实现：
// 按银行按业务进行分类
class DepositProcess : IBankProcess
{
//IBankProcess Members
#region IBankProcess Members
public void Process()
{
// 办理存款业务
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
class TransferProcess : IBankProcess
{
//IBankProcess Members
#region IBankProcess Members
public void Process()
{
// 办理转账业务
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
class DrawMoneyProcess : IBankProcess
{
//IBankProcess Members
#region IBankProcess Members
public void Process()
{
// 办理取款业务
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
这种思路的转换，会让复杂的问题变得简单明了，使系统各负其责，人人实惠。有了上述的重构，银行工作人员彻底变成一个EasyBankStaff（“轻松”的组织者）：
class EasyBankStaff
{
private IBankProcess bankProc = null;
public void HandleProcess(Client client)
{
bankProc = client.CreateProcess();
bankProc.Process();
}
}
银行业务可以像这样被自动地实现了：
class BankProcess
{
public static void Main()
{
EasyBankStaff bankStaff = new EasyBankStaff();
bankStaff.HandleProcess(new Client("转账用户"));
}
}
你看，当前一切都变得轻松自在，匆忙中办理业务的人们不会在长长的队伍面前一筹莫展，而业务员也从繁琐复杂的劳动中解脱出来。当有新的业务增加时，银行经理不必为重新组织业务流程而担忧，你只需为新增的业务实现IBankProcess接口，系统的其他部分将丝毫不受影响，办理新业务的客户会很容易找到受理新增业务的窗口，如图5所示。
图5符合OCP的设计
对应的实现为：
class FundProcess : IBankProcess
{
//IBankProcess Members
#region IBankProcess Members
public void Process()
{
// 办理基金业务
throw new Exception("The method or operation is not implemented.");
}
#endregion
}
可见，新的设计遵守了开放封闭原则，在需求增加时只需要向系统中加入新的功能实现类，而原有的一切保持封闭不变的状态，这就是基于抽象机制而实现的开放封闭式设计。
然而，细心观察上述实现你会发现一个非常致命的问题：人们是如何找到其想要处理的业务窗口，难道银行还得需要一部分人力来进行疏导？然而确实如此，至少当前的设计必须如此，所以上述实现并非真正的业务处理面貌，实际上当前“轻松”的银行业务员，还并非真正的“轻松”，我们忽略了这个业务系统中最重要的一部分，就是用户。当前，用户的定义被实现为：
class Client
{
private string ClientType;
public Client(string clientType)
{
ClientType = clientType;
}
public IBankProcess CreateProcess()
{
switch (ClientType)
{
case "存款用户":
return new DepositProcess();
break;
case "转账用户":
return new TransferProcess();
break;
case "取款用户":
return new DrawMoneyProcess();
break;
}
return null;
}
}
如果出现新增加的业务，你还必须在长长的分支语句中加入新的处理选项，switch的坏味道依然让每个人看起来都倒胃口，银行业务还是以牺牲客户的选择为代价，难道不能提供一个自发组织客户寻找业务窗口的机制吗？
其中的设计原则就是用于解决上述问题的。
1、开放封闭原则，是最为重要的设计原则，Liskov替换原则和合成/聚合复用原则为开放封闭原则的实现提供保证。
2、可以通过Template Method模式和Strategy模式进行重构，实现对修改封闭、对扩展开放的设计思路。
3、封装变化，是实现开放封闭原则的重要手段，对于经常发生变化的状态一般将其封装为一个抽象，例如银行业务中的IBankProcess接口。
4、拒绝滥用抽象，只将经常变化的部分进行抽象，这种经验可以从设计模式的学习与应用中获得。
里氏替换原则
里氏替换原则，OCP作为OO的高层原则，主张使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构，维持设计的封闭性。“抽象”是语言提供的功能。“多态”由继承语义实现。
里氏替换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏替换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
如此，问题产生了：“我们如何去度量继承关系的质量？”
Liskov于1987年提出了一个关于继承的原则“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“继承必须确保超类所拥有的性质在子类中仍然成立。”也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系。
该原则称为Liskov Substitution Principle——里氏替换原则。林先生在上课时风趣地称之为“老鼠的儿子会打洞”。^_^
我们来研究一下LSP的实质。学习OO的时候，我们知道，一个对象是一组状态和一系列行为的
组合体。状态是对象的内在特性，行为是对象的外在特性。LSP所表述的就是在同一个继承体系中的对象应该有共同的行为特征。
这一点上，表明了OO的继承与日常生活中的继承的本质区别。举一个例子：生物学的分类体系中把企鹅归属为鸟类。我们模仿这个体系，设计出这样的类和关系。
类“鸟”中有个方法fly，企鹅自然也继承了这个方法，可是企鹅不能飞阿，于是，我们在企鹅的类中覆盖了fly方法，告诉方法的调用者：企鹅是不会飞的。这完全符合常理。但是，这违反了LSP，企鹅是鸟的子类，可是企鹅却不能飞！需要注意的是，此处的“鸟”已经不再是生物学中的鸟了，它是软件中的一个类、一个抽象。
有人会说，企鹅不能飞很正常啊，而且这样编写代码也能正常编译，只要在使用这个类的客户代码中加一句判断就行了。但是，这就是问题所在！首先，客户代码和“企鹅”的代码很有可能不是同时设计的，在当今软件外包一层又一层的开发模式下，你甚至根本不知道两个模块的原产地是哪里，也就谈不上去修改客户代码了。客户程序很可能是遗留系统的一部分，很可能已经不再维护，如果因为设计出这么一个“企鹅”而导致必须修改客户代码，谁应该承担这部分责任呢？（大概是上帝吧，谁叫他让“企鹅”不能飞的。^_^）“修改客户代码”直接违反了OCP，这就是OCP的重要性。违反LSP将使既有的设计不能封闭！
修正后的设计如下：
但是，这就是LSP的全部了么？书中给了一个经典的例子，这又是一个不符合常理的例子：正方形不是一个长方形。这个悖论的详细内容能在网上找到，我就不多废话了。
LSP并没有提供解决这个问题的方案，而只是提出了这么一个问题。
于是，工程师们开始关注如何确保对象的行为。1988年，B. Meyer提出了Design by Contract（
契约式设计）理论。DbC从
形式化方法中借鉴了一套确保对象行为和自身状态的方法，其基本概念很简单：
Pre-condition:
每个方法调用之前，该方法应该校验传入参数的正确性，只有正确才能执行该方法，否则认为调用方违反契约，不予执行。这称为前置条件(Pre-condition)。
Post-Condition:
一旦通过前置条件的校验，方法必须执行，并且必须确保执行结果符合契约，这称之为后置条件(Post-condition)。
Invariant:
对象本身有一套对自身状态进行校验的检查条件，以确保该对象的本质不发生改变，这称之为不变式(Invariant)。
以上是单个对象的约束条件。为了满足LSP，当存在继承关系时，子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松；而子类中方法的后置条件必须与超类中被覆盖的方法的后置条件相同或者更为严格
一些OO语言中的特性能够说明这一问题：
继承并且覆盖超类方法的时候，子类中的方法的可见性必须等于或者大于超类中的方法的可见性，子类中的方法所抛出的受检异常只能是超类中对应方法所抛出的受检异常的子类。
public class SuperClass{
public void methodA() throws Exception{}
}
public class SubClassA extends SuperClass{
//this overriding is illegal.
private void methodA() throws IOException{}
}
public class SubClassB extends SuperClass{
//this overriding is OK.
public void methodA() throws FileNotFoundException{}
}
从Java5开始，子类中的方法的返回值也可以是对应的超类方法的返回值的子类。这叫做“
协变”(Covariant)
public class SuperClass {
public Number caculate(){
return null;
}
}
public class SubClass extends SuperClass{
//only compiles in Java 5 or later.
public Integer caculate(){
return null;
}
}
可以看出，以上这些特性都非常好地遵循了LSP。但是DbC呢？很遗憾，主流的面向对象语言（不论是动态语言还是静态语言）还没有加入对DbC的支持。但是随着AOP概念的产生，相信不久DbC也将成为OO语言的一个重要特性之一。
一些题外话：
前一阵子《敲响OO时代的丧钟》和《丧钟为谁而鸣》两篇文章引来了无数议论。其中提到了不少OO语言的不足。事实上，遵从LSP和OCP，不管是静态类型还是动态类型系统，只要是OO的设计，就应该对对象的行为有严格的约束。这个约束并不仅仅体现在方法签名上，而是这个具体行为的本身。这才是LSP和DbC的真谛。从这一点来说并不能说明“万事万物皆对象”的动态语言和“C++，Java”这种“按接口编程”语言的优劣，两类语言都有待于改进。庄兄对DJ的设想倒是开始引入DbC的概念了。这一点还是非常值得期待的。^_^
另外，接口的语义正被OCP、LSP、DbC这样的概念不断地强化，接口表达了对象行为之间的“契约”关系。而不是简单地作为一种实现多继承的语法糖。
依赖倒置原则（DIP Dependence Inversion Principle）
依赖倒置原则
A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
B.抽象不应该依赖于具体实现，具体实现应该依赖于抽象。
依赖倒置原则（Dependence Inversion Principle）是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。
面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。
面向对象的开发很好的解决了这个问题，一般情况下抽象的变化概率很小，让
用户程序依赖于抽象，实现的细节也依赖于抽象。即使实现细节不断变动，只要抽象不变，客户程序就不需要变化。这大大降低了客户程序与实现细节的
耦合度。
面向过程思想的结构图：
图一
背景1：公司是福特和本田公司的金牌合作伙伴，现要求开发一套自动驾驶系统，只要汽车上安装该系统就可以实现无人驾驶，该系统可以在福特和本田车上使用，只要这两个品牌的汽车使用该系统就能实现自动驾驶。于是有人做出了分析如图一。
对于图一分析：我们定义了一个AutoSystem类，一个FordCar类，一个HondaCar类。FordCar类和HondaCar类中各有三个方法:Run(启动Car)、Turn(转弯Car)、Stop(停止Car)，当然了一个汽车肯定不止这些功能，这里只要能说明问题即可。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
|
public
class
HondaCar{
public
void
Run(){
Console.WriteLine(
"本田开始启动了"
);
}
public
void
Turn(){
Console.WriteLine(
"本田开始转弯了"
);
}
public
void
Stop(){
Console.WriteLine(
"本田开始停车了"
);
}
}
public
class
FordCar{
publicvoidRun(){
Console.WriteLine(
"福特开始启动了"
);
}
publicvoidTurn(){
Console.WriteLine(
"福特开始转弯了"
);
}
publicvoidStop(){
Console.WriteLine(
"福特开始停车了"
);
}
}
public
class
AutoSystem{
public
enum
CarType{
Ford,Honda
};
private
HondaCar hcar=
new
HondaCar();
private
FordCar fcar=
new
FordCar();
private
CarType type;
public
AutoSystem(CarType type){
this
.type=type;
}
private
void
RunCar(){
if
(type==CarType.Ford){
fcar.Run();
}
else
{
hcar.Run();
}
}
private
void
TurnCar(){
if
(type==CarType.Ford){
fcar.Turn();
}
else
{
hcar.Turn();
}
}
private
void
StopCar(){
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
|
public
class
AutoSystem{
public
enum
CarType{
Ford,Honda,Bmw
};
HondaCar hcar=
new
HondaCar();
FordCarf car=
new
FordCar();
BmwCar bcar=
new
BmwCar();
private
CarType type;
public
AutoSystem(CarTypetype){
this
.type=type;
}
private
void
RunCar(){
if
(type==CarType.Ford){
fcar.Run();
}
else
if
(type==CarType.Honda){
hcar.Run();
}
else
if
(type==CarType.Bmw){
bcar.Run();
}
}
private
void
TurnCar(){
if
(type==CarType.Ford){
fcar.Turn();
}
else
if
(type==CarType.Honda){
hcar.Turn();
}
else
if
(type==CarType.Bmw){
bcar.Turn();
}
}
private
void
StopCar(){
if
(type==CarType.Ford){
fcar.Stop();
}
else
if
(type==CarType.Honda){
hcar.Stop();
}
else
if
(type==CarType.Bmw){
bcar.Stop();
}
}
}
|
分析：这会给系统增加新的相互依赖。随着时间的推移，越来越多的车种必须加入到AutoSystem中，这个“AutoSystem”模块将会被if/else语句弄得很乱，而且依赖于很多的低层模块，只要低层模块发生变动，AutoSystem就必须跟着变动，
它最终将变得僵化、脆弱。
导致上面所述问题的一个原因是，含有高层策略的模块，如AutoSystem模块，依赖于它所控制的低层的具体细节的模块（如HondaCar()和FordCar()）。如果我们能够找到一种方法使AutoSystem
模块独立于它所控制的具体细节，那么我们就可以自由地复用它了。我们就可以用这个模块来生成其它的程序，使得系统能够用在需要的汽车上。OOD给我们提供了一种机制来实现这种“依赖倒置”。
图二
看图 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
|
public
interface ICar
{
void
Run();
void
Turn();
void
Stop();
}
public
class
BmwCar:ICar
{
public
void
Run()
{
Console.WriteLine(
"宝马开始启动了"
);
}
public
void
Turn()
{
Console.WriteLine(
"宝马开始转弯了"
);
}
public
void
Stop()
{
Console.WriteLine(
"宝马开始停车了"
);
}
}
public
class
FordCar:ICar
{
publicvoidRun()
{
Console.WriteLine(
"福特开始启动了"
);
}
public
void
Turn()
{
Console.WriteLine(
"福特开始转弯了"
);
}
public
void
Stop()
{
Console.WriteLine(
"福特开始停车了"
);
}
}
public
class
HondaCar:ICar
{
publicvoidRun()
{
Console.WriteLine(
"本田开始启动了"
);
}
public
void
Turn()
{
Console.WriteLine(
"本田开始转弯了"
);
}
public
void
Stop()
{
Console.WriteLine(
"本田开始停车了"
);
}
}
public
class
AutoSystem
{
private
ICar icar;
public
AutoSystem(ICar icar)
{
this
.icar=icar;
}
private
void
RunCar()
{
icar.Run();
}
private
void
TurnCar()
{
icar.Turn();
}
private
void
StopCar()
{
icar.Stop();
}
}
|
现在AutoSystem系统依赖于ICar 这个抽象，而与具体的实现细节HondaCar、FordCar、BmwCar无关，所以实现细节的变化不会影响AutoSystem。对于实现细节只要实现ICar 即可，即实现细节依赖于ICar 抽象。
综上：
一个应用中的重要策略决定及业务模型正是在这些高层的模块中。也正是这些模型包含着应用的特性。但是，当这些模块依赖于低层模块时，低层模块的修改将会直接影响到它们，迫使它们也去改变。这种境况是荒谬的。应该是处于高
层的模块去迫使那些低层的模块发生改变。应该是处于高层的模块优先于低层的模块。无论如何高层的模块也不应依赖于低层的模块。而且，我们想能够复用的是高层的模块。通过
子程序库的形式，我们已经可以很好地复用低层的模块了。当高层的模块依赖于低层的模块时，这些高层模块就很难在不同的环境中复用。但是，当那些高层
模块独立于低层模块时，它们就能很简单地被复用了。这正是位于框架设计的最核心之处的原则。
总结：依赖倒置原则
A.高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象。
B.抽象不应该依赖于具体，具体应该依赖于抽象。
接口隔离原则
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
一、ISP简介（ISP--Interface Segregation Principle）：
使用多个专门的接口比使用单一的总接口要好。
一个类对另外一个类的依赖性应当是建立在最小的接口上的。
一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。
“不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的
类层次结构。”这个说得很明白了，再通俗点说，不要强迫客户使用它们不用的方法，如果强迫用户使用它们不使用的方法，那么这些客户就会面临由于这些不使用的方法的改变所带来的改变。
二、举例说明：
使用场合,提供调用者需要的方法,屏蔽不需要的方法.满足接口隔离原则.比如说电子商务的系统,有订单这个类,有三个地方会使用到,
一个是门户,只能有查询方法,
一个是外部系统,有添加订单的方法,
一个是管理后台,添加删除修改查询都要用到.
根据接口隔离原则(ISP),一个类对另外一个类的依赖性应当是建立在最小的接口上.
也就是说,对于门户,它只能依赖有一个查询方法的接口.
UML结构如下:
下面是实现的代码.
|
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
|
interface
IOrderForPortal{
String getOrder();
}
interface
IOrderForOtherSys{
String insertOrder();
String getOrder();
}
interface
IOrderForAdmin{
//extendsIOrderForPortal,IOrderForOtherSys
String deleteOrder();
String updateOrder();
String insertOrder();
String getOrder();
}
/*
interface IOrderForPortal{
String getOrder();
}
interface IOrderForOtherSys{
String insertOrder();
}
interface IOrderForAdmin extendsIOrderForPortal,IOrderForOtherSys{
String updateOrder();
String deleteOrder();
}
*/
class
Order
implements
IOrderForPortal,IOrderForOtherSys,IOrderForAdmin{
private
Order(){
//--什么都不干,就是为了不让直接 new,防止客户端直接New,然后访问它不需要的方法.
}
//返回给Portal
public
static
IOrderForPortal getOrderForPortal(){
return
(IOrderForPortal)
new
Order();
}
//返回给OtherSys
public
static
IOrderForOtherSys getOrderForOtherSys(){
return
(IOrderForOtherSys)newOrder();
}
//返回给Admin
public
static
IOrderForAdmin getOrderForAdmin(){
return
(IOrderForAdmin)
new
Order();
}
//--下面是接口方法的实现.只是返回了一个String用于演示
public
String getOrder(){
return
"implemented getOrder"
;
}
public
String insertOrder(){
return
"implementedinsertOrder"
;
}
public
String updateOrder(){
return
"implementedupdateOrder"
;
}
public
String deleteOrder(){
return
"implementeddeleteOrder"
;
}
}
public
class
TestCreateLimit{
public
static
void
main(String[]
args){
IOrderForPortal orderForPortal =Order.getOrderForPortal();
IOrderForOtherSys orderForOtherSys =Order.getOrderForOtherSys();
IOrderForAdmin orderForAdmin = Order.getOrderForAdmin();
System.out.println("
Portal门户调用方法:"+orderForPortal.getOrder());
System.out.println("OtherSys外部
系统调用方法:"+orderForOtherSys.insertOrder());
System.out.println(
"Admin管理后台调用方法:"
+orderForAdmin.getOrder()+
";"
+orderForAdmin.insertOrder()+
";"
+orderForAdmin.updateOrder()+
";"
+orderForAdmin.deleteOrder());
}
}
|
这样就能很好的满足接口隔离原则了,调用者只能访问它自己的方法,不能访问到不应该访问的方法.
9万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
