设计模式（一）--设计原则

此系列只是对《大话设计模式》的巩固总结。

在理解设计模式之前，需要理解几个：面向对象的设计原则

1. 单一职责：一个类只专注于做一件事。
2. 里氏替换：基类存在的地方，子类可以将其替换。
3. 依赖倒置：实现尽量依赖抽象，不依赖具体实现。
4. 接口隔离：为使用者提供尽可能小的的单独接口，而不是大而全。
5. 迪米特法则： 一个实体尽可能少的与其他实体发生相互作用。
6. 开闭原则：面向扩展开放、面向修改关闭。
7. 组合/聚合：尽量使用组合聚合达到复用的目的， 尽量少用继承。

理解：个人理解，众多设计原则与设计模式的基础是对需要实现目标合理抽象及分类。合理的选择和使用设计模式，前提是对自己需要实现的东西合理的抽象，并且准确的分类。加上对一种编程语言的熟练运用，可创作出比较美观的代码。

单一职责：一个类只负责一项职责，这里的关键是对职责的描述。如果对职责描述是细化还是一定概括性，这就一定程度的取决项目需求了。过于细化将会产生大量的类，如果公司没有好的文档管理策略+较好统一的编程风格+熟练的编程人员 ， 结果是生产的细而全的类并不一定好用。如果纯粹站在代码层面来看，遵守单一原则，对于后续代码扩展，维护有很多好处的。但死磕这儿，可能在设计阶段，导致过度设计。需要设计人员，对公司的业务方向、项目方向有较好的理解，准确把握职责划分。

里氏替换：软件中基类对象替换为子类对象，程序不会出现异常。（大牛总结）这里强调的思想：子类可以扩展父类的功能，但不能改变父类原有的功能。

• 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
• 子类中可以增加自己特有的方法。
• 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
• 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。

依赖倒置：高层模块不应该依赖底层模块，二者都应该依赖抽象；抽象不依赖细节；细节应该依赖抽象。反应到代码中，一个高层类强耦合了一个底层类，--依赖倒置原则--，这里介绍的很清晰。思想：面向接口编程，参与协作开发的人越多、项目越庞大，采用依赖导致原则的意义就越重大。现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。

接口隔离原则：过多的类不应依赖一个大而多接口。将大而多的接口拆分，按需实现。

• 接口尽量小，但是要有限度。对接口进行细化可以提高程序设计灵活性是不挣的事实，但是如果过小，则会造成接口数量过多，使设计复杂化。所以一定要适度。
• 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

迪米特法则：只与直接的朋友通信。首先来解释一下什么是直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖、关联、组合、聚合等。其中，我们称出现成员变量、方法参数、方法返回值中的类为直接的朋友，而出现在局部变量中的类则不是直接的朋友。也就是说，陌生的类最好不要作为局部变量的形式出现在类的内部。你和女盆友就是直接盆友，和她闺蜜就不是，有什么事，直接和她讲，不要直接找她闺蜜（捂脸）。

开闭原则：修改封闭、扩展开放。这里和依赖倒置有一些相似之处，对于会有变化的地方进行抽象化，用实现扩展细节。这样对于修改某一个实现的细节，并不影响其他。而对于需要添加扩展的功能，新增抽象的实现即可。开闭应该是软件设计的最终原则，无论是类，还是模块。

组合聚合原则：相对的是继承，继承需要遵循里氏原则。继承复用破坏数据封装性，将基类的实现细节全部暴露给了派生类，基类的内部细节常常对派生类是透明的，白箱复用；虽然简单，但不安全，不能在程序的运行过程中随便改变；基类的实现发生了改变，派生类的实现也不得不改变；从基类继承而来的派生类是静态的，不可能在运行时间内发生改变，因此没有足够的灵活性。组合/聚合复用原则可以使系统更加灵活，类与类之间的耦合度降低，一个类的变化对其他类造成的影响相对较少，因此一般首选使用组合/聚合来实现复用。

最后贴一段大牛精辟的总结：

    最后说明一下如何去遵守这六个原则。对这六个原则的遵守并不是是和否的问题，而是多和少的问题，也就是说，我们一般不会说有没有遵守，而是说遵守程度的多少。任何事都是过犹不及，设计模式的六个设计原则也是一样，制定这六个原则的目的并不是要我们刻板的遵守他们，而需要根据实际情况灵活运用。对他们的遵守程度只要在一个合理的范围内，就算是良好的设计。我们用一幅图来说明一下。

        图中的每一条维度各代表一项原则，我们依据对这项原则的遵守程度在维度上画一个点，则如果对这项原则遵守的合理的话，这个点应该落在红色的同心圆内部；如果遵守的差，点将会在小圆内部；如果过度遵守，点将会落在大圆外部。一个良好的设计体现在图中，应该是六个顶点都在同心圆中的六边形。

        在上图中，设计1、设计2属于良好的设计，他们对六项原则的遵守程度都在合理的范围内；设计3、设计4设计虽然有些不足，但也基本可以接受；设计5则严重不足，对各项原则都没有很好的遵守；而设计6则遵守过渡了，设计5和设计6都是迫切需要重构的设计。

         到这里，设计模式的六大原则就写完了。主要参考书籍有《设计模式》《设计模式之禅》《大话设计模式》以及网上一些零散的文章，但主要内容主要还是我本人对这六个原则的感悟。写出来的目的一方面是对这六项原则系统地整理一下，一方面也与广大的网友分享，因为设计模式对编程人员来说，的确非常重要。正如有句话叫做一千个读者眼中有一千个哈姆雷特，如果大家对这六项原则的理解跟我有所不同，欢迎留言，大家共同探讨。