设计模式原则· GitBook

设计模式原则 · 写在前面 · 设计的六大原则 · 依赖倒置原则(Dependence Inversion Principle) · 接口隔离原则(Interface Segregation Principle) · 迪米特原则( Law of Demeter). Introduction UML中类的关系 继承 实现 聚合关系 组合关系 关联关系 依赖关系 设计模式原则 创建型模式 简单工厂模式 工厂方法模式 抽象工厂模式 三种工厂模式比较 建造者模式 原型模式 单例模式 结构型模式 静态代理模式 动态代理模式 行为型模式 本書使用GitBook釋出 设计模式原则 设计模式原则 写在前面 天下武林，林林总总。

名门正宗如少林武当，诚然名扬天下，而武林之大，但凡修得暗镖神剑者，亦可独步江湖。

所以门派无尊贵，只有适合不适合。

设计的本质：即使最懂设计的人，也要心胸坦荡，认识到自我局限性，不可以名门正宗自居，须认识到获得真理是一个学无止境、永远追求的过程。

十八般武艺样样精通，仅出现在武侠传说中，现实中即使是全栈工程师也不敢说十八般武艺样样精通，对于普通的IT从业者来说，如何从码农变为一个合格的工程师来说，软件设计是必经之路。

当然要软件设计一定要遵循设计的六大原则。

在工作的初期，我们可能会经常有这样的感受，自己的代码接口设计混乱、代码耦合较为严重、一个类的代码过多等等，当自己回头再看这些代码时可能会感慨，怎么能写成这个鸟样。

再看那些知名的开源库，它们大多有整洁的代码、清晰简单的接口、职责单一的类，这个时候我们会通常会捶胸顿足而感慨：什么时候老夫才能写出这样的代码！ 在做开发的这些年中，我渐渐的感觉到，其实国内的一些初、中级工程师写的东西不规范或者说不够清晰的原因是缺乏一些指导规则。

他们手中挥舞着面向对象的大旗，写出来的东西却充斥着面向过程的气味。

也许是他们不知道有这些规则，也许是他们知道但是不能很好的运用到实际的代码中，亦或是他们没有在实战项目中体会到这些原则能够带来的优点，以至于他们对这些原则并没有足够的重视。

设计的六大原则 在此之前，有一点需要大家知道，熟悉这些原则并不是说你写出的程序就一定灵活、清晰，只是为你优秀的代码之路铺上了一层栅栏，在这些原则的指导下，你才能避免陷入一些常见的代码泥沼，从而让你写出优秀的东西。

单一原则(SingleResponsibilityPrinciple) 单一职责原则的英文名称是SingleResponsibilityPrinciple，简称是SPR，简单地说就是一个类只做一件事，这个设计原则备受争议却又极其重要。

只要你想和别人争执、怄气或者是吵架，这个原则是屡试不爽的。

因为单一职责的划分界限并不是如马路上的行车道那么清晰，很多时候都是需要个人经验来界定。

当然，最大的问题就是对职责的定义，什么是类的职责，以及怎么划分类的职责。

这跟我们社会分工一样，一些人干这个，另一些人干那个，只有大家都这样做了，我们的社会才更和谐。

试想一下，如果你遵守了这个原则，那么你的类就会划分的很细，每个类都有比较单一的职责，这不就是高内聚、低耦合么！当然，如何界定类的职责就需要你的个人经验了。

当然，软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离，就是抽象的能力。

其实要去判断是否应该分离出类来，也不难，那就是如果你能想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责。

我们来定义一个网络类，代码如下： publicinterfaceIHttp{ /** *发送Http请求，并且返回一个Response */ publicResponsesendRequest(Request>request); } 我们可以看到，IHttp只有一个sendRequest函数，它的职责就是执行网络请求并且返回一个Response，它的职责很单一，这样在需要修改执行网络请求的相关代码时，只需要修改实现Http接口的类，而不会影响其他类的代码。

如果某个类的职责包含有执行网络请求、解析网络请求、进行gzip压缩、封装请求参数等，那么在你修改某处代码时就必须谨慎，以免修改的代码影响了其它的功能。

当你修改的代码能够基本上不影响其他功能。

这就一定程度上保证了代码的可维护性。

注意，单一职责原则并不是一个类只能有一个函数，而是说这个类中的函数所做的工作是高度相关的，也就是高内聚。

基本判断原则，就是一个特定的类，当确认以后，它的责任就确定了，不能增加它行为以外的功能。

例如一般我们定义API接口的时候，如果这个接口干了很多事情，就是一些隐含的事情，我们就认为它设计没有遵循单一原则。

优点 类的复杂性降低，实现什么职责都有清晰明确的定义。

可读性提高，复杂性降低，那当然可读性提高了。

可维护性提高，可读性提高了，那当然更容易维护了。

变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

里氏替换原则(LiskovSubstitutionPrinciple) 里氏替换原则本质就是继承和多态的应用。

继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。

比如使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。

里氏替换原则通俗的来讲就是：子类可以扩展父类的功能，但不能改变父类原有的功能。

它包含以下4层含义： 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。

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

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

当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

还拿上面的Http类举例，我们用RestfulAPI方式进行Http网络请求，代码如下： publicclassRestfulClient{ .... PublicRestfulClient(IHttphttp){ this.http=http!=null?http:createHttp(); } publicvoiddoGet(Stringurl,List