首页 > 代码库 > 解读设计原则
解读设计原则
概述
设计原则就一本菜谱,告诉我们一道美味的菜应该是什么样的,或者说需要具备什么。但是又没有一个固化或可测量的标准。写代码就和烹饪一样,只有当自己品尝以后才知其味。
1 开闭原则
定义:
开闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开放,对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
解读
开闭原则很简单,就是当需求变更的时候,尽量不要修改已有代码。开闭原则是整个设计原则的核心思想。如果当你发现某个需求的改动需要涉及许多地方的代码改动,那么你的代码很有可能是不满足开闭原则的。
小结
单独说开闭原则是没有什么内容可讲的,就像和你说“坚强的人可以克服任何困难”。那么其实我们关心的是怎么才能变得“坚强”。其他的设计原则其实都是围绕着怎么实现开闭原则而进行的。
2 单一职责原则
定义:
单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责,或者可以定义为:就一个类而言,应该只有一个引起它变化的原因。
解读
通俗一点说,就是一个类不能承担太多的功能。只专心一件事,并且把这件事做好。举一个例子,假如要写一个食堂类。对于客户端来说,食堂核心功能是要能打饭和回收餐具。如果要打饭那么肯定需要有先把菜做好,如果要做菜还要有人去买菜。那么如果这些功能都放在一个类里面就会如下图:
很明显违反了单一职责原则。为什么?明明就是只负责吃相关职能啊。你都说了是吃相关,那么肯定就不只是一个简单功能。吃前要准备,吃后要收拾。其实作为一个服务,就和我们去食堂吃饭,我只关心怎么打饭,我吃完以后把餐具放哪里。其他的至于菜市从哪里买的,谁炒的都不关心。因此,改良一下
作为食堂,提供多种多样的菜品(如川菜、粤菜)。如果让一个厨师即炒粤菜又炒川菜又违背了单一职责原则。因此再改一下:
单一职责好处就是: 可以降低类的复杂度,提高类的可读性,降低变更引起的风险降低。变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响。
小结
其实单一职责不仅仅是针对一个类的设计,往小的说一个方法、往大的说一个模块都应该满足单一职责原则。只是怎么去确定职责及其范围是需要根据具体的场景来确定。
3 里氏代换原则
定义:
里氏代换原则(Liskov Substitution Principle, LSP):所有引用基类(父类)的地方必须能透明地使用其子类的对象。
解读
里氏代换原则核心就是要满足继承体系,能用父类的地方,那么其任何子类也可以正确调用。否则,就不应该做为其子类(或者父类的定义就不正确)。例如鸟是一个父类,那么所有的鸟都应该是卵生。但是如果父类定义了方法fly()就不一定了,因为有的鸟不会飞的。这个就不满足里氏替换原则。从代码层面上来说:如果一个类实现一个接口,那么就应该实现该接口的所有方法。比较经典的案例就是Spring的CacheManager的接口。
小结
如果你理解(或者使用过)面向对象语言,那么里氏替换原则理解起来就十分简单。例如java在编译的时候就会检查一个程序是否符合里氏替换原则。虽然很简单,但是这也是实现开闭原则的基本条件。试想,当扩展一个接口的时候,发现扩展类在实现该接口的方法不能正确调用,那么这个该扩展也是没有任何意义的。
4 依赖倒转原则
定义:
依赖倒转原则(Dependency Inversion Principle, DIP):抽象不应该依赖于细节,细节应当依赖于抽象。换言之,要针对接口编程,而不是针对实现编程。
解读
上面定义中的抽象可以简单的理解为接口,细节就是接口的实现类。也就是说,无论是定义变量、方法参数类型还是方法返回都尽量使用抽象接口,而不是返回具体的实现类。这样做的目的就是方便以后扩展(也就是实现开闭原则的手段)。还是前面的食堂为例,假如一开始的时候只有MarketA卖菜,采购员就只有去哪里卖菜。也许一开始的代码就会这样写:
class MarketA { public String name() { return ("MarketA"); } } class Buyer { public void buy(MarketA marketA) { System.out.println("采购员在" + marketA.name() + "买菜"); } } public void CanteenBuyFood() { Buyer buyer = new Buyer(); buyer.buy(new MarketA()); }
突然有一天,MarketB开业,并且每周一的价格比MarketA便宜,因此,选择周一在MarketB买菜。
class MarketA { public String name() { return ("MarketA"); } } class MarketB { public String name() { return ("MarketB"); } } class Buyer { public void buyA(MarketA marketA) { System.out.println("采购员在" + marketA.name() + "买菜"); } public void buyB(MarketB marketB) { System.out.println("采购员在" + marketB.name() + "买菜"); } } public void CanteenBuyFood() { Buyer buyer = new Buyer(); // 其实这也也不满足单一职责原则,即要选择菜市场,又要派采购员买菜。 if(to is monday){ buyer.buyA(new MarketA()); }else{ buyer.buyB(new MarketB()); } }
突然又有一天,MarketC,MarketD...MarketCX 开业了,并且....好吧,是不是发现这样写下去什么时候是个头啊。因此我们需要进行代码重构,使其满足开闭原则。
interface Market { String name(); } class MarketA implements Market { public String name() { return ("MarketA"); } } class MarketB implements Market { public String name() { return ("MarketB"); } } interface Buyer { public void buy(Market market); } //省略Buyer的子类 public void CanteenBuyFood() { Market market = selectMarket(); Buyer buyer = selectBuyer(); buyer.buy(market); } private Buyer selectBuyer() { //根据实际情况选择采购员 } private Market selectMarket() { // 根据情况选择市场 }
重构后代码是不是无论加多少market,只要修改selectMarket()的方法。无论加多少采购员,只要修改Buyer.getBuyer()中的代码。
小结
可以看出,在代码重构过程中,在大多数情况下开闭原则、里氏代换原则和依赖倒转原则这三个设计原则会同时出现。开闭原则是目标,里氏代换原则是基础,依赖倒转原则是手段,他们目的都是为了代码的扩展性,只是分析问题时所站角度不同而已。
5 接口隔离原则
定义:
接口隔离原则(Interface Segregation Principle, ISP):使用多个专门的接口,而不使用单一的总接口,即客户端不应该依赖那些它不需要的接口。
解读
接口隔离就是定义一个接口的时候不要定义得太而广,而是把他们分割成一些更细小的接口。一般不满足单一职责原则都不满足接口隔离原则,这样的例子很多,就不多说明了。但反过来却不一定,举一个例子(往往原则的例子举反例是最清晰的)。还是买菜的问题,如果我们定义一个市场,在市场里面买肉、买蔬菜、买水果....),往往一开始我们定义接口的时候是按照一个样例来定义接口,比如上面就是按照一个超级市场来定义的接口,其实这样做是很正常的情况。
interface Market { void buyMeat(); void buyVegetables(); } class SuperMarket implements Market { public void buyMeat() { System.out.println("买肉"); } public void buyVegetables() { System.out.println("买菜"); } }
这样定义接口在一开始是没问题,但是随着业务扩展,如果现在存在另外一个市场,他只卖菜,不卖肉。。那么该类在 buyMeat()下面怎么办?当你发现你实现一个接口的时候,某个需要实现的方法你没办法去实现,这种情况也算不满足接口隔离的原则了。这时候就需要进行重构,把接口进一步细化,例如,把Martet细化为MeatMarket和VegetableMarket。
interface Market { //其他共有方法 } interface MeatMarket extends Market{ void buyMeat(); } interface VegetableMarket extends Market{ void buyVegetables(); } class SuperMarket implements MeatMarket,VegetableMarket { public void buyMeat() { System.out.println("买肉"); } public void buyVegetables() { System.out.println("买菜"); } } class SmallMarket implements VegetableMarket { public void buyVegetables() { System.out.println("买菜"); } }
上面的实例代码仅仅是为了说明接口隔离原则,
小节
接口隔离原则核心思想就是细化接口,提高程序的灵活性。但细化到什么程度却没有具体的度量,接口不能太小,如果太小会导致系统中接口泛滥,反而不利于维护。因此如何把握这个读就是经验了。
迪米特法则
定义
迪米特法则(Law of Demeter, LoD):一个软件实体应当尽可能少地与其他实体发生相互作用。
解读
迪米特法则还有几种定义形式,包括:不要和“陌生人”说话、只与你的直接朋友通信等
一个类只与他的朋友类进行交互
所谓一个类的朋友,就是该类
- 当前对象本身(this);
- 以参数形式传入到当前对象方法中的对象,或者返回的方法返回的对象
- 当前对象的成员对象;
从代码层面上讲,当该类的所有方法体为空的时候,该类所依赖的类就是朋友类 所谓只与他朋友类进行交互意思就比较好理解了,就是不能直接调用他朋友的朋友方法。也就是在中,食堂服务\=\=朋友==>食堂后勤\=\=朋友==>厨师,我们不能直接在食堂服务中直接调用让厨师去炒菜。食堂服务类要与厨师类通信,也是必须要有食堂后勤类作为中介。从代码层面上来说,一般 A.getB().getC().xxxMethod() 往往都是破坏迪米特法则。
即使是朋友也要保持距离
一个类公开的public属性或方法越多,修改时涉及的面也就越大,变更引起的风险扩散也就越大。例如,
class A { public void step1(){ //do something } public void step2(){ //do something} } public void step3(){ //do something} } } class M { public void someCall(A a) { a.step1(); a.step2(); a.step3(); } }
从代码里面看,A确实是M的朋友,但是,M和A太"亲密"了,如果以后需要在调用step2的之前调用一个check2()的方法,就必须要修改M中的方法,如果这个调用方式大量出现在工程中,就会引起扩散。如果我之前是这么设计的交互的方式就不会存在这个问题。也就是说,朋友之间的交互不要太"亲密"。同时作为别人朋友,最好能提供“一站式服务”。
class A { private void step1(){ //do something } private void step2(){ //do something} } private void step3(){ //do something} } public void exe(){ step1(); step2(); step3(); } } class M { public void someCall(A a) { a.exe(); } }
小节
迪米特发展的目的就是降低系统的耦合度,使类与类之间保持松散的耦合关系。和接口隔离原则一样,迪米特法则也是一个无法进行度量。过度使用迪米特法则,也会造成系统的不同模块之间的通信效率降低,这就直接导致了系统中存在大量的中介类。因此,如何使用迪米特法则还是那句话,根据经验。
总结
单一职责原则告诉我们实现类的功能不要太多。里氏替换原则告诉我们不要破坏继承体系;依赖倒置原则告诉我们要面向接口编程;接口隔离原则告诉我们在设计接口的时候要精简单一;迪米特法则告诉我们要降低耦合。而开闭原则总的大纲,要对扩展开放,对修改关闭。
设计原则只是给我们一些指导性的意见,在实际工作中往往要根据实际情况来判断。就如开篇所说的那样,往往菜谱往往给我们的意见都是“少许”,“适量”,而真正要烹饪出一道美味还需要我们自己不断去积累和调整。
解读设计原则