什么是设计模式

什么是设计模式

能够用一句话归纳设计模式———设计模式是一种利用OOP的封闭、继承和多态三大特性，同时在遵循单一职责原则、开闭原则、里氏替换原则、迪米特法则、依赖倒置原则、接口隔离原则及合成/聚合复用原则的前提下，被总结出来的通过反复实践并被多数人知晓且通过分类和设计的可重用的软件设计方式。

OOD七大原则

面向对象设计（OOD）有七大原则（是的，你没看错，是七大原则，不是六大原则），它们互相补充。

开-闭原则

Open-Close Principle（OCP），即开-闭原则。开，指的是对扩展开放，即要支持方便地扩展；闭，指的是对修改关闭，即要严格限制对已有内容的修改。开-闭原则是最抽象也是最重要的OOD原则。简单工厂模式、工厂方法模式、抽象工厂模式中都提到了如何经过良好的设计遵循开-闭原则。

里氏替换原则

Liskov Substitution Principle（LSP），即里氏替换原则。该原则规定“子类必须可以替换其父类，不然不该当设计为其子类”。换句话说，父类出现的地方，都应该能由其子类代替。因此，子类只能去扩展基类，而不是隐藏或者覆盖基类。

依赖倒置原则

Dependence Inversion Principle（DIP），依赖倒置原则。它讲的是“设计和实现要依赖于抽象而非具体”。一方面抽象化更符合人的思惟习惯；另外一方面，根据里氏替换原则，能够很容易将原则的抽象替换为扩展后的具体，这样能够很好的支持开-闭原则。

接口隔离原则

Interface Segration Principle（ISP），接口隔离原则，“将大的接口打散成多个小的独立的接口”。因为Java类支持实现多个接口，能够很容易的让类具备多种接口的特征，同时每一个类能够选择性地只实现目标接口。

单一职责原则

Single Responsibility Principle（SRP），单一职责原则。它讲的是，不要存在多于一个致使类变动的缘由，是高内聚低耦合的一个体现。

迪米特法则/最少知道原则

Law of Demeter or Least Knowledge Principle（LoD or LKP），迪米特法则或最少知道原则。它讲的是“一个对象就尽量少的去了解其它对象”，从而实现松耦合。若是一个类的职责过多，因为多个职责耦合在了一块儿，任何一个职责的变动均可能引发其它职责的问题，严重影响了代码的可维护性和可重用性。

合成/聚合复用原则

Composite/Aggregate Reuse Principle（CARP / CRP），合成/聚合复用原则。若是新对象的某些功能在别的已经建立好的对象里面已经实现，那么应当尽可能使用别的对象提供的功能，使之成为新对象的一部分，而不要再从新建立。新对象可经过向这些对象的委派达到复用已有功能的效果。简而言之，要尽可能使用合成/聚合，而非使用继承。《Java设计模式（九） 桥接模式》中介绍的桥接模式便是对这一原则的典型应用。

OOP三大基本特性

封装

封装，也就是把客观事物封装成抽象的类，而且类能够把本身的属性和方法只让可信的类操做，对不可信的进行信息隐藏。

继承

继承是指这样一种能力，它可使用现有的类的全部功能，并在无需从新编写原来类的状况下对这些功能进行扩展。

多态

多态指一个类实例的相同方法在不一样情形有不一样的表现形式。具体来讲就是不一样实现类对公共接口有不一样的实现方式，但这些操做能够经过相同的方式（公共接口）予以调用。

设计模式十万个为何

为何要用设计模式

• 设计模式是高级软件工程师和架构师面试基本必问的项目（先经过面试进入这个门槛咱们再谈其它）
• 设计模式是通过大量实践检验的安全高效可复用的解决方案。不要重复发明轮子，并且大多数时候你发明的轮子尚未已有的好
• 设计模式是被主流工程师/架构师所普遍接受和使用的，你使用它，方便与别人沟通，也方便别人code review（这个够实在吧）
• 使用设计模式能够帮你快速解决80%的代码设计问题，从而让你更专一于业务自己
• 设计模式自己是对几大特性的利用和对几大设计原则的践行，代码量积累到必定程度，你会发现你已经或多或少的在使用某些设计模式了
• 架构师或者team leader教授初级工程师设计模式，能够很方便的以你们承认以方式提升初级工程师的代码设计水平，从而有利于提升团队工程实力

是否是必定要尽量使用设计模式

每一个设计模式都有其适合范围，并解决特定问题。因此项目实践中应该针对特定使用场景选用合适的设计模式，若是某些场景下如今的设计模式都不能很彻底的解决问题，那也没必要拘泥于设计模式自己。实际上，学习和使用设计模式自己并非目的，目的是经过学习和使用它，强化面向对象设计思路并用合适的方法解决工程问题。

设计模式有时并不是最优解

有些人认为，在某些特定场景下，设计模式并不是最优方案，而本身的解决方案可能会更好。这个问题得分两个方面来讨论：一方面，如上文所述，全部设计模式都有其适用场景，“one size does not fit all”；另外一方面，确实有可能本身设计的方案比设计模式更适合，但这并不影响你学习并使用设计模式，由于设计模式通过大量实战检验能在绝大多数状况下提供良好方案。

设计模式太教条化

设计模式虽然都有其相对固定的实现方式，可是它的精髓是利用OOP的三大特性，遵循OOD七大原则决定项目问题。因此学习设计模式的目的不是学习设计模式的固定实现方式自己，而是其思想。

我有本身的一套思路，不必引导团队成员学习设计模式

设计模式是被普遍接受和使用的，引导团队成员使用设计模式能够减小沟通成本，而更专一于业务自己。也许你有本身的一套思路，可是你怎么能保证团队成员必定承认你的思路，进而将你的思路贯彻实施呢？统一使用设计模式能让团队只使用20%的精力决解80%的问题。其它20%的问题，才是你须要花精力解决的。