面向对象设计模式

一 23种设计模式

  创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
  结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
  行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
  其实还有两类：并发型模式和线程池模式。用一个图片来整体描述一下：

  GoF(Gang of Four，四人组，《Design Patterns: Elements of Reusable Object-Oriented Software》/《设计模式》一书的作者：Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides)并没有把 MVC 提及为一种设计模式，而是把它当做“一组用于构建用户界面的类集合”。在他们看来，它其实是其它三个经典的设计模式的演变：观察者模式(Observer)(Pub/Sub)，策略模式(Strategy)和组合模式(Composite)。根据MVC在框架中的实现不同可能还会用到工厂模式(Factory)和装饰器(Decorator)模式。
  正如所讨论的，models 表示应用的数据，而 views 处理屏幕上展现给用户的内容。为此，MVC 在核心通讯上基于推送/订阅模型(惊讶的是在很多关于 MVC 的文章中并没有提及到)。当一个 model 变化时它对应用其它模块发出更新通知(publishes)，订阅者 (subscriber)——通常是一个 Controller，然后更新对应的 view。观察者——这种自然的观察关系促进了多个 view 关联到同一个 model。
  对于感兴趣的开发人员想更多的了解解耦性的 MVC(根据不同的实现)，这种模式的目标之一就是在一个主题和它的观察者之间建立一对多的关系。当这个主题改变的时候，它的观察者也会得到更新。Views 和 controllers 的关系稍微有点不同。Controllers 帮助 views 对不同用户的输入做不同的响应，是一个非常好的策略模式列子。
  MVC 的是为了把数据(Model)和视图(View)分离开来，然后用控制器(Controller)来粘合M和V之间的关系。 MVC是观察者模式(Observer)，策略模式(Strategy)和组合模式(Composite)三个设计模式的演变.

二 面向对象的6条设计原则

  OOP(面向对象编程(Object Oriented Programming，OOP，面向对象程序设计)是一种计算机编程架构。)基本上有6大原则，而实际上都是互补的，也就是说一些原则需要利用另一些原则来实现自己。6大原则如下：

1 单一职责原则

  单一职责原则：一个类，最好只做一件事，只有一个引起它的变化。可以看做是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。
  职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而大大损伤其内聚性和耦合度。通常意义下的单一职责，就是指只有一种单一功能，不要为类实现过多的功能点，以保证实体只有一个引起它变化的原因。
  如果能够想到多于一个的动机去改变一个类， 那么这个类就具有多于一个的职责，就应该考虑类的职责分离。

2 开放封闭原则

  是面向对象所有原则的核心，软件设计说到底追求的目标就是封装变化、降低耦合，而开放封闭原则就是这一目标的最直接体现。
  开放封闭原则：软件实体应该是可扩展的，而不可修改的。也就是，对扩展开放，对修改封闭的。开放封闭原则主要体现在两个方面：1、对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。2、对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对其进行任何尝试的修改。
  在我们最初编写代码时， 假设变化不会发生，当变化发生时， 我们就创建抽象来隔离以后发生的同类变化。通过一些面向对象的手段，如继承，多态等来隔离具体实现，需求依然可以满足，还能应对变化。即面对需求， 对程序的改动是通过增加新代码进行的， 而不是更改现有的代码。

3 依赖倒置原则

  依赖倒置原则：针对接口编程， 不要对实现编程。

A. 高层模块不应该依赖层模块，两个都应该依赖抽象。
B. 抽象不应该依赖细节，细节应该依赖抽象。

  依赖倒转其实可以说是面向对象设计的标志，编写时考虑的都是如何针对抽象编程而不是针对细节编程。即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计了。

4 Liskov替换原则

  子类必须能够替换其基类。这一思想体现为对继承机制的约束规范，只有子类能够替换基类时，才能保证系统在运行期内识别子类，这是保证继承复用的基础。在父类和子类的具体行为中，必须严格把握继承层次中的关系和特征，将基类替换为子类，程序的行为不会发生任何变化。同时，这一约束反过来则是不成立的，子类可以替换基类，但是基类不一定能替换子类。
  Liskov替换原则，主要着眼于对抽象和多态建立在继承的基础上，因此只有遵循了Liskov替换原则，才能保证继承复用是可靠地。实现的方法是面向接口编程：将公共部分抽象为基类接口或抽象类，通过Extract Abstract Class，在子类中通过覆写父类的方法实现新的方式支持同样的职责。
  Liskov替换原则是关于继承机制的设计原则，违反了Liskov替换原则就必然导致违反开放封闭原则。
  Liskov替换原则能够保证系统具有良好的拓展性，同时实现基于多态的抽象机制，能够减少代码冗余，避免运行期的类型判别。

5 接口隔离原则

  核心思想是：使用多个小的专门的接口，而不要使用一个大的总接口。
  具体而言，接口隔离原则体现在：接口应该是内聚的，应该避免“胖”接口。一个类对另外一个类的依赖应该建立在最小的接口上，不要强迫依赖不用的方法，这是一种接口污染。
  接口有效地将细节和抽象隔离，体现了对抽象编程的一切好处，接口隔离强调接口的单一性。而胖接口存在明显的弊端，会导致实现的类型必须完全实现接口的所 有方法、属性等；而某些时候，实现类型并非需要所有的接口定义，在设计上这是“浪费”，而且在实施上这会带来潜在的问题，对胖接口的修改将导致一连串的客 户端程序需要修改，有时候这是一种灾难。在这种情况下，将胖接口分解为多个特点的定制化方法，使得客户端仅仅依赖于它们的实际调用的方法，从而解除了客户 端不会依赖于它们不用的方法。
  分离的手段主要有以下两种：1、委托分离，通过增加一个新的类型来委托客户的请求，隔离客户和接口的直接依赖，但是会增加系统的开销。2、多重继承分离，通过接口多继承来实现客户的需求，这种方式是较好的。

6 迪米特原则

  如果两个类不必彼此直接通信， 那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。迪米特法则其根本思想， 是强调了类之间的松耦合。
  迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限，也就是说，一个类包装好自己的 private 状态， 不需要让别的类知道的字段或行为就不要公开。
  在程序设计时，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。

三 依赖注入

  OOD有一个重要的思想那就是依赖倒置原则(DIP)，并由此引申出IoC、DI以及Ioc容器等概念。
  依赖倒置原则(DIP): 一种软件架构设计的原则(抽象概念)。
  控制反转(IoC)：一种反转流、依赖和接口的方式(DIP的具体实现方式)。
  依赖注入(DI)：IoC的一种实现方式，用来反转依赖(IoC的具体实现方式)。
  IoC容器 ：依赖注入的框架，用来映射依赖，管理对象创建和生存周期(DI框架)。
  依赖倒置原则(DIP)：高层模块不依赖于底层模块的实现，而低层模块依赖于高层模块定义的接口。

1 控制反转(IoC)

   DIP是一种 软件设计原则，它仅仅告诉你两个模块之间应该如何依赖，但是它并没有告诉如何做。IoC则是一种 软件设计模式，它告诉你应该如何做，来解除相互依赖模块的耦合。控制反转(IoC)，它为相互依赖的组件提供抽象，将依赖(低层模块)对象的获得交给第三方(系统)来控制，即依赖对象不在被依赖模块的类中直接通过new来获取。

2 依赖注入(DI)

  控制反转(IoC)一种重要的方式，就是将依赖的对象的创建和绑定转移到被依赖对象类的外部来实现。
  依赖注入(DI)，它提供一种机制，将被依赖(低层模块)对象的引用传递给依赖(高层模块)对象。
  方法一 构造函数注入： 在需要依赖的对象的构造函数中增加一个接口参数，在实例化需要依赖的对象时，将被依赖对象传入。
  方法二 方法注入： 同上，通过方法实现。

3 IoC容器

  上面所有的例子中，我们都是通过手动的方式来创建被依赖对象，并将其传递给依赖模块
  对于大型项目来说，相互依赖的组件比较多。如果还用手动的方式，自己来创建和注入依赖的话，显然效率很低，而且往往还会出现不可控的场面。正因如此，IoC容器诞生了。IoC容器实际上是一个DI框架，它能简化我们的工作量。它包含以下几个功能：动态创建、注入依赖对象。管理对象生命周期。映射依赖关系。

4 文章

  谈谈对Spring IOC的理解：https://blog.youkuaiyun.com/qq_22654611/article/details/52606960/

四 代码可扩展性

  当需求变化时，需要对当前程序进行改变，使代码可以改变。这被称为可扩展性。可扩展的代码将允许您快速添加或删除功能，而不会引入错误。在一个完美的可扩展的世界中，我们可以添加新的功能，而不用改变任何已经存在的代码。
  白箱可扩展性：在源码级别的代码扩展。黑箱可扩展性：：扩展现有系统而不直接扩展其原始代码，源代码通常不可见，提供文档和约定。到了黑箱这一步，才算真正满足OCP原则。
  开放原则 - 开放扩展，关闭修改。使代码(类，功能)的单位，使他们永远不必再被触摸。
  分离原则 - 保持代码的一致性；保持代码松耦合；最小化冗余；使用单元测试来查找代码气味；使用多态性；有利于继承的构成；使用依赖注入来分隔使用和创建。

五 简单工厂模式–SimpleFactory

  本节内容来自这里。