设计模式之总结

面向对象-编程

 

1. 面向对象编程方法具有的四个基本原则：

抽象、封装、继承、多态

2.设计模式之六大设计原则：

单一职责原则、开放封闭、依赖倒转、里氏代换原则、合成聚合、迪米特

3.设计模式分类：

（1）创建型模式：单例、工厂方法、抽象工厂、创建者、原型

抽象工厂，为什么需要创建型模式：创建型模式隐藏了这些类的实例是如何被创建和放在一起，整个系统关于这些对象所知道的是由抽象类所定义的接口。创建模式在创建了什么、谁创建它、怎么被创建的，以及何时创建这些方面提供了很大的灵活性。

原型模式，补充：当一个系统应该独立于它的产品创建、构成和表示时，考虑创建模式。建立相应数目的原型并克隆他们通常比每次用合适的状态手工实例化该类更方便一些。

创建者实现松耦合：将一个复杂对象的构建与它的表示分离，这就很容易改变一个产品的内部表示，并且使得构造代码和表示代码分开。这样对于客户来说，无需关心产品创建过程，只需告诉需要什么，就能用创建过程创建不同的产品给客户。

单例模式：对一些类来说，一个实例是很重要的。单例的优势是让类的自身负责保存它的唯一实例。这个类可以保证没有其他实例被创建。

工厂方法，与其他几个相比的优势？通常设计应该是从工厂方法开始，当设计者发现需要更大灵活性时，设计便会向其他创建模式演化。当设计者在设计标准之间进行权衡的时候，了解多个创建模式可以给设计者更多选择余地。

 

（2）结构型模式：适配器、外观、桥接 --- 组合、享元、代理、装饰

适配器：想使用一个已经存在的类，而它的接口不符合要求，或者希望创建一个可以复用的类，该类可以与其他不相关的类或不可预见的类协同工作。正如开放-封闭原则，适配器可以让这些接口不同的类通过适配后，协同工作。

桥接，面对变化如何处理？继承是好东西，但往往过度使用，继承会导致类的结构过于复杂，关系太多，难以维护，更糟糕的是扩展性非常差。如果能发现继承体系中，有两个甚至多个方向的变化，那么解耦这些不同方向的变化，通过对象组合的方式，把两个角色之间的继承关系改为组合关系，从而可以使两者可以应对各自独立的变化，也就是合成聚合复用原则。“主张找出变化并封装之。”

装饰，面对变化如何处理？面对变化，如果采用生成子类的方法进行扩充，为支持每一种扩展的组合，会产生大量的子类，使子类数目呈爆炸性增长。这也是继承所带来的灾难，事实上，这些子类多半只是为某个对象增加一些职责。通过装饰，可以更加灵活、以动态、透明的方式给单个对象添加职责，并在不需要时撤销相应职责。

组合—如何表示对象的部分与整体的层次结构？客户可以一致的使用组合结构和单个对象。任何用到基本对象的地方都可以使用组合对象。

外观：如果两个类不必彼此直接通讯，那么就不要让这两个类发生直接的相互作用。如果实在需要调用，可以通过第三者转发调用。外观模式让一个软件中的子系统间的通信和相互依赖关系达到最小，具体办法是引入一个外观对象，它为子系统间提供了一个单一而简单的屏障。

享元：对象使得内存占用过多，而且如果都是大量重复对象，那就是资源的极大浪费。

代理与外观的不同、与适配器的区别：代理与外观的区别在于，代理对象代表一个单一对象而外观对象代表一个子系统；代理的客户对象无法直接访问目标对象，由代理提供对单独目标对象的访问控制，而外观的客户对象可以直接访问子系统各个对象，但通常由外观对象提供需子系统各元件功能的简化的共同层次的调用接口。至于和适配器，代理是一种原来对象的代表，其他需要与这个对象打交道的操作都是和这个代表交涉。而适配器则不需要虚构出一个代表者，只需要为应付特定使用目的，将原来的类进行一些组合。

 

适配器、外观、桥接三者比较：外观更优；

桥接模式与适配器模式有一些共同特征：就是给另一对象提供一定程度的间接性，但是不能等到问题发生了再去考虑解决问题，而是应该在设计之初就想好如何避免问题发生，桥接模式通常是在设计之初，就对抽象接口与它的实现部分进行桥接，让抽象和实现独立演化。

外观模式与桥接、适配器模式的比较：桥接和适配器被用于软件生命周期的不同阶段，针对的是不同的问题，谈不上孰优孰劣。对于外观模式，和适配器有些相似，都是对现存系统的封装，但外观定义的是一个新的接口，而适配器是复用一个原有的接口，适配器是使两个已有接口协同工作，外观则是为现存系统提供一个更为方便的访问接口。

 

（3）行为型模式一组：观察者、模板、命令、状态、职责链

观察者，目标和观察者不是紧密耦合的，它们可以属于一个系统中的不同抽象层次，目标所知道的仅仅是它有一系列观察者，每个观察者实现Observer的简单接口，观察者属于哪一具体类，目标是不知道的。

模板方法，对代码复用的理解以及如何实现代码重用？代码重用是编程中最常见、最糟糕的‘坏味道’，如果我们在一个以上的地方看到相同的程序结构，那么可以肯定，设法将他们合二为一，程序会变得更好。但是完全相同的代码当然存在明显的重复，而微妙的重复会出现在表面不同，但是本质相同的结构会处理步骤中。模板方法由一个抽象类组成，这个抽象类定义了需要覆盖的可能有不同实现的模板方法。

命令模式，为什么请求发送者与具体实现者要具体分离？好处是什么？将调用操作的对象与指导如何操作的对象解耦，意味着可以在这两者间处理很多事，比如完全可以发送者发送完请求就完事了，具体怎么做是我的事，可以在不同的时刻指定、排列和执行请求。可以在实施操作前将状态存储起来，以便支持取消或重做的操作。还可以记录整个操作日志，以便以后可以在系统出问题时查找原因或恢复重做。总之有类似请求时，利用命令模式分离请求者和实现者。

职责链模式，为什么请求发送者与具体实现者要具体分离？好处是什么？我们时常碰到多个对象可以处理一个请求，哪个对象处理该请求事先并不知道，要在运行时刻自动确定，此时最好的办法就是请求发送者与具体处理者分离，让客户在不明确指定接收者的情况下，提交一个请求，然后由所有能处理这个请求的对象连成一条链，并沿着这条链传递请求，直到有一个对象处理为止。

状态模式，条件分支的大量应用有何问题？状态模式决定状态转移的逻辑不在单块的if或switch中，而是分布在各个状态子类之间，由于所有与状态相关的代码都存在于某个状态子类中，所以通过定义新的子类可以很容易的增加新的状态和转移。

 

（3）行为型模式组二：解释器、中介者、访问者、策略、备忘录、迭代器

解释器：如果一种特定类型的问题发生的频率足够高，那么可能就值得将该问题的各个实例表述为一个简单语言中的句子。这样就可以构建一个解释器，该解释器通过解释这些句子来解决该问题。

中介者：面向对象设计鼓励将行为分布到各个对象中，这种分布可能会导致对象间有很多连接。也就是说，有可能每一个对象都需要知道其他许多对象。对象间的大量相互连接使得每一个对象似乎不太可能在没有其他对象的支持下工作，这对于应对变化是不利的，任何较大的改动都和困难。中介者提倡将集体行为封装在单独中介者对象来避免这个问题，中介者负责控制和协调一组对象间的交互。中介者充当一个中介以使组中的对象不再相互显示引用。从而减少了相互连接的数目。

访问者对朋友要求苛刻，要请其帮忙很难，请问喜欢交朋友吗？

意思就是使用条件苛刻。也就是贵精不贵多。访问者增加具体的Element是困难的，但增加依赖于复杂对象结构的构建的操作变得容易。仅需增加一个新的访问者即可在一个对象结构上定义一个新的操作。

策略：继承提供了一种支持多种算法或行为的方法，我们可以直接生成一个类A的子类B、C、D，从而给他以不同行为。但这样会将行为硬件编制到父类A中，而将算法的实现与类A的实现混合起来，从而使得A难以理解、难以维护和扩展，还不能动态的改变算法。所以将算法封装在独立的策略Strategy类中使得你可以独立于其类A改变它，易于扩展理解。

备忘录：通常原对象A都有很多状态属性，保存对象的内部状态，其实也就是将这些状态属性值可以记录到A对象外部的另一个对象B，但是，如果记录过程对外透明，那就意味着保存过程耦合了对象状态细节。使用备忘录不会出现这个问题，它可以避免暴露一些只应由对象A管理却又必须保存在对象A之外的信息。备忘录模式把可能很复杂的对象A的内部信息对其他对象屏蔽起来，从而保持了封装边界。

迭代器：关键思想是将对列表的访问和遍历从列表对象中分离出来并放入一个迭代器对象中，迭代器类定义了一个访问该列表元素的接口。迭代器对象负责跟踪当前的元素，并且知道哪些元素已经遍历过了。

 

工厂方法、外观、观察者、策略 --- 适配器

分析最后五种设计模式参与其中，发挥什么作用，具体如何做？

应用题：

外观模式：

观察者：需求中提到“要有菜单、工具栏、状态栏等要素”，每个按钮或链接的点击都需要触发一系列事件。而所有事件机制其实都是观察者模式的一种应用，即当一个对象状态发生改变时，素有依赖于它的对象都得到通知并被自动更新，比如状态栏就是一个根据事件的不同时刻需要更新的控件。

适配器：需求说“统计图生成如若时间充裕则自行开发，否则就购买第三方组件。”，这里的意思是说，统计图表的生成是自己开发还是购买组件是有变数的。既然这里存在可能的变化，那很显然要考虑将其封装，根据依赖倒转规则，我们让业务模块依赖一个抽象的生成图接口，而非具体的第三方组件或自行实现代码将有利于随机应变。至于第三方组件接口不统一问题，完全可以利用适配器模式来处理。

策略：公司有多种薪资发放规则，但不管哪种发放规则，只不过是计算的不同，最终都将是数据的存储与展示，因此我们不希望发放规则的变化会影响系统的数据新增修改、数据统计查询等具体的业务逻辑。用策略模式，可以很好的吧薪资发放规则一个个封装起来，并且使他们可以相互替代，这样哪怕再增加发放规则，或者修改原有规则，都不会影响其他业务实现。

工厂方法：