首页 > 代码库 > 解读设计原则

解读设计原则

概述

设计原则就一本菜谱,告诉我们一道美味的菜应该是什么样的,或者说需要具备什么。但是又没有一个固化或可测量的标准。写代码就和烹饪一样,只有当自己品尝以后才知其味。

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):一个软件实体应当尽可能少地与其他实体发生相互作用。

解读

迪米特法则还有几种定义形式,包括:不要和“陌生人”说话、只与你的直接朋友通信等

一个类只与他的朋友类进行交互

所谓一个类的朋友,就是该类

  1. 当前对象本身(this);
  2. 以参数形式传入到当前对象方法中的对象,或者返回的方法返回的对象
  3. 当前对象的成员对象;

从代码层面上讲,当该类的所有方法体为空的时候,该类所依赖的类就是朋友类 所谓只与他朋友类进行交互意思就比较好理解了,就是不能直接调用他朋友的朋友方法。也就是在技术分享中,食堂服务\=\=朋友==>食堂后勤\=\=朋友==>厨师,我们不能直接在食堂服务中直接调用让厨师去炒菜。食堂服务类要与厨师类通信,也是必须要有食堂后勤类作为中介。从代码层面上来说,一般 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();
    }
}

  

小节

迪米特发展的目的就是降低系统的耦合度,使类与类之间保持松散的耦合关系。和接口隔离原则一样,迪米特法则也是一个无法进行度量。过度使用迪米特法则,也会造成系统的不同模块之间的通信效率降低,这就直接导致了系统中存在大量的中介类。因此,如何使用迪米特法则还是那句话,根据经验。

总结

单一职责原则告诉我们实现类的功能不要太多。里氏替换原则告诉我们不要破坏继承体系;依赖倒置原则告诉我们要面向接口编程;接口隔离原则告诉我们在设计接口的时候要精简单一;迪米特法则告诉我们要降低耦合。而开闭原则总的大纲,要对扩展开放,对修改关闭。
设计原则只是给我们一些指导性的意见,在实际工作中往往要根据实际情况来判断。就如开篇所说的那样,往往菜谱往往给我们的意见都是“少许”,“适量”,而真正要烹饪出一道美味还需要我们自己不断去积累和调整。

解读设计原则