引言

对于设计模式，自己很早之前就看了好多本设计模式书籍，其中一些还看了好几遍，也一直希望自己能在编码的时候把这些设计模式用上去。可是，在日常的打码中，用的做多的就是单例，其次是观察者和建造者模式 ( builder ) 用得比较多，其他的基本很少用到。

用不到的原因是还是不能够理解设计模式的思想，无法将这些设计模式和编码遇到的问题联系起来，从而用不到设计模式。

其实设计模式的提出都是为了解决一个常见的问题而总结出来的办法。所以当你思考采用何种设计模式的时候，你应该先问问自己当前问题的是什么？根据问题去选取合适的设计模式。

等你熟悉了设计模式的以后，你会发现部分设计模式之间存在包含关系，甚至很相像，但是不同的设计模式解决的问题是不一样的。

当我们在设计一个模块的时候可以从以下几个角度去考虑：

这个模块与其他模块的关系是什么样的？

模块中哪些部分是不变的，哪些部分是在不断变化的，是如何变化的？

类与类之间的关系是怎么样的，为什么需要依赖，怎么可以不依赖？

要不要加一个接口？接口的存在是为了解决什么问题？

当然，本文并不是教你是如何使用设计模式。而是讲解设计模式的设计原则。设计模式在被设计出来的时候，也是遵循一些规则的。

设计模式六大原则，具体如下：

单一职责原则（类和方法，接口）

开闭原则 （扩展开放，修改关闭）

里氏替换原则（基类和子类之间的关系）

依赖倒置原则（依赖抽象接口，而不是具体对象）

接口隔离原则（接口按照功能细分）

迪米特法则 （类与类之间的亲疏关系）

每一个设计原则旁边都有个括号，是用来解释，或者描述应用范围的。下面将详细介绍每一个原则。

单一职责原则的定义（类、方法、接口）

单一职责原则（Single Responsibility Principle，SRP）又称单一功能原则。这里的职责是指类变化的原因，单一职责原则规定一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分（There should never be more than one reason for a class to change）。

该原则提出对象不应该承担太多职责，如果一个对象承担了太多的职责，至少存在以下两个缺点：

一个职责的变化可能会削弱或者抑制这个类实现其他职责的能力；

当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来，从而造成冗余代码或代码的浪费。

单一职责原则的优点

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。

降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。

提高类的可读性。复杂性降低，自然其可读性会提高。

提高系统的可维护性。可读性提高，那自然更容易维护了。

变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

单一职责原则的实现方法

单一职责原则是最简单但又最难运用的原则，需要设计人员发现类的不同职责并将其分离，再封装到不同的类或模块中。而发现类的多重职责需要设计人员具有较强的分析设计能力和相关重构经验。

示例

publicinterface UserService {

    publicvoid login(String username, String password);

    publicvoid register(String email, String username, String password);

    publicvoid logError(String msg);

    publicvoid sendEmail(String email);

}

这段代码很显然存在很大的问题，UserService 既要负责用户的注册和登录，还要负责日志的记录和邮件的发送，并且后者的行为明显区别于前者。

假设我要修改发送邮件的逻辑就得修改这个类，这时候 qa 还得回归登录注册逻辑，这样明显不合理。

因此我们需要进行拆分，根据具体的职能可将其具体拆分如下：

UserService：只负责登录注册

publicinterface UserService {

    publicvoid login(String username, String password);

    publicvoid register(String email, String username, String password);

}

LogService ：只负责日志

publicinterface LogService {

    publicvoid logError(String msg);

}

EmailService： 只负责发送邮件

publicinterface EmailService {

    publicvoid sendEmail(String email);

}

这时候，咱们再去回顾前面提到的优点，就能深深体会了。

这里只是讲了接口，其实对类也一样，甚至方法也是一样的。

对于类来说，根据类名，确保里面提供的方法都是属于这个类的。

对于方法，不要把不相关的对象实例作为参数传进来。如果你发现某个方法依赖某个不相关的对象，那么这个方法的实现可能就存在问题。

比如 android 中图片下载后显示到 imageView 中，我提供如下的方法：

loadImage(String url, ImageView view) {

// 下载图片，展示图片

}

对于 loadImage 这个方法，参数 url 是ok 的，但是参数 ImageView 却是不合理的。因为这里做了两个操作，下载图片，展示图片。应该将这个方法在进行拆分：

// 下载图片

 loadImage(String url) {

}

// 显示图片

displayImage(String url, ImageView view) {

// 调用 getBitmap (url)  获取图片

// 获取图片后将其设置到 view 中。

}

// 根据 url 获取图片， 

getBitmap(String url) {

}

这样整个逻辑就很清晰。后续需要修改下载逻辑，也不会影响到展示逻辑。当然其实还有个问题是，这两个方法要不要放在一个类里面？

开闭原则

开闭原则的实现方法：可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。

因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。

示例

// 矩形publicclass Rectangle {

    publicdouble getWidth() {

        return width;

    }

    publicdouble getHeight() {

        return height;

    }

}

需要计算矩形的面积

// 面积计算器publicclass AreaCalculator {

    publicdouble area(Rectangle shape){

        returnshape.getWidth() * shape.getHeight();

    }

}

假设这时候，又多了一个圆形类

// 圆形publicclass Circular {

    publicdouble getRadius(){

        return radius;

    }

}

同样也需要计算他的面积，这时候就会变成下面这样子：

publicclass AreaCalculator {

    publicdouble area(Object shape){

        if(shapeinstanceof Rectangle) {

            Rectangle rectangle = (Rectangle) shape;

            returnrectangle.getWidth() * rectangle.getHeight();

        } elseif(shapeinstanceof Circular) {

            Circular circular = (Circular) shape;

            returncircular.getRadius() * circular.getRadius() * Math.PI;

        } else {

            thrownewRuntimeException("There is no such type.");

        }

    }

}

这么更改完成，完全没有问题。但是在真实的生产环境中，情况更为复杂，更改涉及的部分较多，那样就可能导致牵一发动全身。并且，以前编写的经过测试的一些功能需要重新测试，甚至导致某些功能不可用。

改进版，把计算面积这个公有逻辑变成一个接口：

publicinterface Shape {

    publicdouble getArea();

}

publicclassRectangleimplements Shape{

    publicdouble getWidth() {

        return width;

    }

    publicdouble getHeight() {

        return height;

    }

    publicdouble getArea() {

        returngetWidth() * getHeight();

    }

}

这样，当需求变更，需要计算圆形面积的时候，我们只需创建一个圆形的类，并实现 Shape 接口即可:

publicclassCircularimplements Shape {

    publicdouble getRadius(){

        return radius;

    }

    publicdouble getArea() {

        returngetRadius() * getRadius() * Math.PI;

    }

}

计算三角形面积、四边形面积... 的时候，我们只需让它们去实现 Shape 接口即可，无需修改源代码。

里氏替换原则

里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。

里氏替换原则的作用

里氏替换原则的主要作用如下。

里氏替换原则是实现开闭原则的重要方式之一。

它克服了继承中重写父类造成的可复用性变差的缺点。

它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

加强程序的健壮性，同时变更时可以做到非常好的兼容性，提高程序的维护性、可扩展性，降低需求变更时引入的风险。

里氏替换原则的实现方法（继承）

里氏替换原则通俗来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

根据上述理解，对里氏替换原则的定义可以总结如下：

子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法

子类中可以增加自己特有的方法

当子类的方法重载父类的方法时，方法的前置条件（即方法的输入参数）要比父类的方法更宽松

当子类的方法实现父类的方法时（重写/重载或实现抽象方法），方法的后置条件（即方法的的输出/返回值）要比父类的方法更严格或相等

通过重写父类的方法来完成新的功能写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。

如果程序违背了里氏替换原则，则继承类的对象在基类出现的地方会出现运行错误。

这时其修正方法是：取消原来的继承关系，重新设计它们之间的关系。

关于里氏替换原则的例子，最有名的是“正方形不是长方形”。当然，生活中也有很多类似的例子，例如，企鹅、鸵鸟和几维鸟从生物学的角度来划分，它们属于鸟类；但从类的继承关系来看，由于它们不能继承“鸟”会飞的功能，所以它们不能定义成“鸟”的子类。同样，由于“气球鱼”不会游泳，所以不能定义成“鱼”的子类；“玩具炮”炸不了敌人，所以不能定义成“炮”的子类等。

对于正方形和长方形最好的做法是再添加一个父类，他们同时继承自这个父类。

依赖倒置（抽线细节）

依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。

由于在软件设计中，细节具有多变性，而抽象层则相对稳定，因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。这里的抽象指的是接口或者抽象类，而细节是指具体的实现类。

使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。

依赖、倒置原则的作用

依赖倒置原则的主要作用如下。

依赖倒置原则可以降低类间的耦合性。

依赖倒置原则可以提高系统的稳定性。

依赖倒置原则可以减少并行开发引起的风险。

依赖倒置原则可以提高代码的可读性和可维护性。

依赖倒置原则的实现方法

依赖倒置原则的目的是通过要面向接口的编程来降低类间的耦合性，所以我们在实际编程中只要遵循以下4点，就能在项目中满足这个规则。

每个类尽量提供接口或抽象类，或者两者都具备。

变量的声明类型尽量是接口或者是抽象类。

任何类都不应该从具体类派生。

使用继承时尽量遵循里氏替换原则。

依赖倒置原则在“顾客购物程序”中的应用。

分析：本程序反映了 “顾客类”与“商店类”的关系。商店类中有 sell() 方法，顾客类通过该方法购物以下代码定义了顾客类通过韶关网店 ShaoguanShop 购物

class Customer {

    publicvoid shopping(ShaoguanShop shop) {

        //购物        System.out.println（shop.sell());

    }

}

但是，这种设计存在缺点，如果该顾客想从另外一家商店（如婺源网店 WuyuanShop）购物，就要将该顾客的代码修改如下：

class Customer {

    publicvoid shopping(WuyuanShop shop) {

        //购物        System.out.println(shop.sell());

    }

}

顾客每更换一家商店，都要修改一次代码，这明显违背了开闭原则。

存在以上缺点的原因是：顾客类设计时同具体的商店类绑定了，这违背了依赖倒置原则。

解决方法是：定义“婺源网店”和“韶关网店”的共同接口 Shop，顾客类面向该接口编程，其代码修改如下：

class Customer {

    publicvoid shopping(Shop shop) {

        //购物        System.out.println(shop.sell());

    }

}class Customer {

    publicvoid shopping(Shop shop) {

        //购物        System.out.println(shop.sell());

    }

}

这样，不管顾客类 Customer 访问什么商店，或者增加新的商店，都不需要修改原有代码了，其类如下图所示：

程序代码如下：

package principle;publicclass DIPtest

{

    publicstaticvoid main(String[] args)

    {

        Customer wang=new Customer();

        System.out.println("顾客购买以下商品：");

        wang.shopping(new ShaoguanShop());

        wang.shopping(new WuyuanShop());

    }

}//商店interface Shop

{

    publicString sell();//卖}//韶关网店classShaoguanShopimplements Shop

{

    public String sell()

    {

        return"韶关土特产：香菇、木耳……";

    }

}//婺源网店classWuyuanShopimplements Shop

{

    public String sell()

    {

        return"婺源土特产：绿茶、酒糟鱼……";

    }

} //顾客class Customer

{

    publicvoid shopping(Shop shop)

    {

        //购物        System.out.println(shop.sell());

    }

}

程序的运行结果如下：

顾客购买以下商品：

韶关土特产：香菇、木耳……

婺源土特产：绿茶、酒糟鱼……

接口隔离原则（接口）

接口隔离原则（Interface Segregation Principle，ISP）要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。

2002 年罗伯特·C.马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法（Clients should not be forced to depend on methods they do not use）。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。

以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：

单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。

单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

接口隔离原则的优点

接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点。

将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。

接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。

如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。

使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。

能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

接口隔离原则的实现方法

在具体应用接口隔离原则时，应该根据以下几个规则来衡量。

接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。

为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。

了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。

提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

对于接口隔离，大家还是可以参考单一职责提到的示例：

publicinterface UserService {

    publicvoid login(String username, String password);

    publicvoid register(String email, String username, String password);

    publicvoid logError(String msg);

    publicvoid sendEmail(String email);

}

这时候，应该就能理解拆分的好处了。

迪米特法则 (类与类之间的关系)

迪米特法则（Law of Demeter，LoD）又叫作最少知识原则（Least Knowledge Principle，LKP)，产生于 1987 年美国东北大学（Northeastern University）的一个名为迪米特（Demeter）的研究项目，由伊恩·荷兰（Ian Holland）提出，被 UML 创始者之一的布奇（Booch）普及，后来又因为在经典著作《程序员修炼之道》（The Pragmatic Programmer）提及而广为人知。

迪米特法则的定义是：只与你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

迪米特法则的优点

迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。

降低了类之间的耦合度，提高了模块的相对独立性。

由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

迪米特法则的实现方法

从迪米特法则的定义和特点可知，它强调以下两点：

从依赖者的角度来说，只依赖应该依赖的对象。

从被依赖者的角度说，只暴露应该暴露的方法。

所以，在运用迪米特法则时要注意以下 6 点。

在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。

在类的结构设计上，尽量降低类成员的访问权限。

在类的设计上，优先考虑将一个类设置成不变类。

在对其他类的引用上，将引用其他对象的次数降到最低。

不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。

谨慎使用序列化（Serializable）功能

明星与经纪人的关系实例。

分析：明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如与粉丝的见面会，与媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则，其类图如下图所示。

代码如下：

package principle;publicclass LoDtest

{

    publicstaticvoid main(String[] args)

    {

        Agent agent=new Agent();

        agent.setStar(newStar("林心如"));

        agent.setFans(newFans("粉丝韩丞"));

        agent.setCompany(newCompany("中国传媒有限公司"));

        agent.meeting();

        agent.business();

    }

}//经纪人class Agent

{

    private Star myStar;

    private Fans myFans;

    private Company myCompany;

    publicvoid setStar(Star myStar)

    {

        this.myStar=myStar;

    }

    publicvoid setFans(Fans myFans)

    {

        this.myFans=myFans;

    }

    publicvoid setCompany(Company myCompany)

    {

        this.myCompany=myCompany;

    }

    publicvoid meeting()

    {

        System.out.println(myFans.getName()+"与明星"+myStar.getName()+"见面了。");

    }

    publicvoid business()

    {

        System.out.println(myCompany.getName()+"与明星"+myStar.getName()+"洽淡业务。");

    }

}//明星class Star

{

    private String name;

    Star(String name)

    {

        this.name=name;

    }

    public String getName()

    {

        return name;

    }

}//粉丝class Fans

{

    private String name;

    Fans(String name)

    {

        this.name=name;

    }

    public String getName()

    {

        return name;

    }

}//媒体公司class Company

{

    private String name;

    Company(String name)

    {

        this.name=name;

    }

    public String getName()

    {

        return name;

    }

}

程序的运行结果如下：

粉丝韩丞与明星林心如见面了。

中国传媒有限公司与明星林心如洽淡业务。

 到此，设计模式的六大原则就讲完了。喜欢的朋友请点个赞加个关注支持下小编，谢谢啦。