设计模式——入坑

一、概述

在java中设计模式分为三大类：

• 创建型模式：包括单例、原型、工厂方法、抽象工厂、建造者。创建型模式主要特征是描述如何创建对象，基于“将对象的创建与使用分离”。
• 结构型模式：代理、适配器、桥接、装饰、外观、享元、组合。结构型模式主要特征是描述如何将对象按照一种布局组成更大的结构。
• 行为型模式：模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器。行为型模式主要特征是描述类或对象之间协作完成一项任务以及如何分配职能。

二、设计模式七大原则

1. 单一职责原则

一个类或者一个方法只负责一项职责，也就是一个类不要承担过多职能，比如开发过程中一个时间对象就处理时间的生成，格式化，换算等操作，而不要去做其他无关时间的操作。同样，一个方法应该尽可能的做好一件事，比如上面的时间处理类里，我一个方法根据参数既可以返回格式化，又可以用作换算，这样一个方法处理的事太多，其颗粒度不够细，使用也比较麻烦，代码可读性也较差。
单一职责原则的优点：

• 降低了类和方法的复杂度，便于代码维护和阅读
• 可以方便修改，不会影响其他功能

2. 开闭原则

软件实体应该对扩展开放，对修改关闭。这里的软件实体可以是一个模块，一个接口，一个类或一个方法。其实在实际开发中，这种思想我想应该已经很深刻的印在你们脑子里了，比如你要实现造房子，你不会一股脑的直接定义一个类，写上一堆方法，咚咚咚就把房子建好了，这样是错误的，我们应该先定义一个接口，将造房子的步骤给定义好，然后在具体的类里实现每个步骤的细节，就好比如李四要造，张三也要造，但是他们造房子可能各有各的想法，这就实现了可扩展；对修改关闭，其实就是在一些特定方法中，修改带来的影响是巨大的，所有我们在程序设计的时候需要考虑到对于基础的模块或者方法，将他封装起来，避免外部修改对整体结构带来的影响。
开闭原则的优点：

• 提到代码的可复用性，颗粒度越小，其复用性就越大
• 稳定性高且延续性强，易于维护
• 开发效率好，个人观点

可以通过“抽象约束、封装变化”来实现开闭原则，即通过接口或者抽象类为软件实体定义一个相对稳定的抽象层，而将相同的可变因素封装在相同的具体实现类中。
因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。

3. 里氏替换原则

继承必须确保超类所拥有的性质在子类中仍然成立，里氏替换原则主要阐述了有关继承的一些原则，也就是什么时候应该使用继承，什么时候不应该使用继承，以及其中蕴含的原理。里氏替换原是继承复用的基础，它反映了基类与子类之间的关系，是对开闭原则的补充，是对实现抽象化的具体步骤的规范。
子类可以扩展父类的功能，但不能改变父类的原有功能。在实际开发中，我对于这部分的看法就是，如果你觉得父类中的方法是固定，且不允许更改的，可以考虑加上final关键字，这样子类就不能去修改这个方法了，当然如果你能保证尽量少重写父类方法也是可以的。如果通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。
里氏替换原则的优点：

• 里氏替换原则是实现开闭原则的重要方式之一。
• 它克服了继承中重写父类造成的可复用性变差的缺点。
  它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

4. 合成复用原则

软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。
如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。
通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点:

• 继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
• 子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
• 它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。
  采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点:
• 它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
• 新旧类之间的耦合度低。这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口。
• 复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

5. 依赖倒置原则

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。其核心思想是：要面向接口编程，不要面向实现编程。依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。
依赖倒置原则的主要作用如下：

• 依赖倒置原则可以降低类间的耦合性。
• 依赖倒置原则可以提高系统的稳定性。
• 依赖倒置原则可以减少并行开发引起的风险。
• 依赖倒置原则可以提高代码的可读性和可维护性。

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

• 每个类尽量提供接口或抽象类，或者两者都具备。
• 变量的声明类型尽量是接口或者是抽象类。
• 任何类都不应该从具体类派生。
• 使用继承时尽量遵循里氏替换原则。

6. 接口隔离原则

简单点说就是将一个大接口根据特征分成几个小接口，不要一个模块就定义一个接口入口，所有方法都在一个接口中写完。
接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 5 个优点：

• 将臃肿庞大的接口分解为多个粒度小的接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。
• 接口隔离提高了系统的内聚性，减少了对外交互，降低了系统的耦合性。
• 如果接口的粒度大小定义合理，能够保证系统的稳定性；但是，如果定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险。
• 使用多个专门的接口还能够体现对象的层次，因为可以通过接口的继承，实现对总接口的定义。
• 能减少项目工程中的代码冗余。过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码。

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

• 接口尽量小，但是要有限度。一个接口只服务于一个子模块或业务逻辑。
• 为依赖接口的类定制服务。只提供调用者需要的方法，屏蔽不需要的方法。
• 了解环境，拒绝盲从。每个项目或产品都有选定的环境因素，环境不同，接口拆分的标准就不同深入了解业务逻辑。
• 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。

7. 迪米特法则

如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。
迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。

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

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

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

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

• 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
• 在类的结构设计上，尽量降低类成员的访问权限。
• 在类的设计上，优先考虑将一个类设置成不变类。
• 在对其他类的引用上，将引用其他对象的次数降到最低。
• 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
• 谨慎使用序列化（Serializable）功能。

以上七大原则皆摘自于：软件设计模式概述，同时这个网站也有详细的设计模式介绍，可以参考。