日更挑战-设计模式之概要

越不懂的越爱装

大家都同等:IT世界没有难不难,只有是否了解过

挑战目录

如何理解七大原则

• 开闭原则：

  1. 扩展开放，对修改关闭 。

  2. 当需求改变时，不改变任何现有代码逻辑。进行扩展功能。

  3. 开闭原则的途径:里式替换原则、依赖倒置原则、

• 里式替换原则：

  1. 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法
  2. 子类中可以增加自己特有的方法
  3. 子类继承父类时，除添加新的方法完成新增功能和实现抽象方法外，尽量不要重写父类的方法

• 依赖倒置原则：

  1. 要面向接口编程，不要面向实现编程
  2. 通过面向接口编程，来降低耦合性
  3. 尽量提供接口或抽象类，或者两者
  4. 变量的声明类型尽量是接口或者是抽象类
  5. 任何类都不应该从具体类继承出来
  6. 高层不应该依赖低层
  7. 使用继承时尽量遵守里氏替换

• 单一职责原则：

  1. 一个类应该有且仅有一个引起它变化的原因
  2. 一个方法不要处理太多的事情
  3. 是自己的事情不要给别人做

• 接口隔离原则：

  1. 不应该被迫实现不使用的方法(当接口设计太大时，会出现有些方法本是不需要实现的)
  2. 定制型接口:只提供调用者需要的方法，屏蔽不需要的方法
  3. 定义最少的方法，完成最多的事情

• 迪米特法则：

  1. 只持有必须持有的对象
  2. 只暴露必须暴露的方法
  3. 优先考虑将类设置成不变类
  4. 尽量降低类与类之间的耦合
  5. 尽量降低类的访问权限
  6. 谨慎使用序列化

• 合成复用原则：

  1. 优先考虑组合、聚合等关联关系来实现，之后考虑继承关系来实现
  2. 使用继承关系时，必须严格遵循里氏替换原则

怎样创建对象？？？(创建型模式)

• 创建对象始终只需要一个(或有限个)：单例

  怎样创建对象？？？答： 创建一个整个程序只有一个或有限个的类对象。
  
  应用场景：
    某类只要生成一个对象的时候。如一个班的班长等。
    某些类创建实例时占用资源较多，或实例化耗时较长，且经常使用。
    某类需要频繁实例化，而创建的对象又频繁被销毁的时候，如多线程的线程池、网络连接池等。
    频繁访问数据库或文件的对象。
    从系统上来讲应当是单一控制逻辑的操作。有多个实例，则系统会完全乱套。
    对象需要被共享的场合。如 Web 中的配置对象、数据库的连接池等。
  
  好处：
    单例模式可以保证内存里只有一个实例，减少了内存的开销。
    可以避免对资源的多重占用。
    单例模式设置全局访问点，可以优化和共享资源的访问。
  
  缺点：
    单例模式一般没有接口，扩展困难。如果要扩展，则除了修改原来的代码，没有第二种途径，违背开闭原则。
    在并发测试中，单例模式不利于代码调试。在调试过程中，如果单例中的代码没有执行完，也不能模拟生成一个新的对象。
    单例模式的功能代码通常写在一个类中，如果功能设计不合理，则很容易违背单一职责原则。
  

• 创建对象不想对外暴露太多类：工厂“家族”

  怎样创建对象？？？答：创建一个类的构造函数参数过多的复杂类对象。
  

• 对对象进行“复制而克隆”出多个和原型类似的新实例：原型

  怎样创建对象？？？答：创建一个相同或相似的新对象。
  

• 将复杂对象分成多个简单部分，根据需要分别创建，最后构建成复杂对象：建造者

  怎样创建对象？？？答： 创建一个复杂对象，有多个功能方法按一定步骤组合而成，而子部件并不是都必须
  
  应用场景：
  
  好处：
  
  缺点：不符合开闭原则？？？增减属性需要修改类。
  

如何将类或对象按“某种布局”组成更大的结构？？？(结构型模式)

对象结构型模式:

• 对使用量较大的方法作控制：代理模式

  某种布局？？？答：现有布局为-> 有一个方法或功能需要到处调用。
  组成更大的结构？？？答：大的环境下-> 可能需要对该方法在不同时候、不同地点、不同状态等作不同控制。
  
  应用场景：
  简单的比如，日志打印。
  

• 多维度变化的类的子类化实现转为组合关系代替继承关系来实现：桥接模式

  某种布局？？？答：现有布局为-> 一个类具有多个维度的子类，现增加一个维度变化。
  组成更大的结构？？？答：大的环境下-> 可能需要对每个现有子类增加一个该维度的变化的子类。
  
  应用场景： 桥接模式用于防止上述需要过多增加子类的情况。
  

• 类似于建造者的一种遵守开闭原则的方式(为什么这个不是创建型模式？？)、也类似于桥接模式的一种防爆炸式子类增长的方式：装饰模式

  某种布局？？？答：现有布局为->
  组成更大的结构？？？答：
  
  应用场景：
  
  好处：
  
  缺点：
  装饰器模式会增加许多子类，过度使用会增加程序得复杂性。
  

• 相当于接口隔离原则的一类：外观模式

  某种布局？？？答：现有布局为-> A,B,C,D和a,b,c,d之间有各种交互
  组成更大的结构？？？答：将A系统的A,B,C,D和B系统的a,b,c,d直接加一个交互层。所有交互都通过该类来交互。被提供接口的系统为使用外观模式的系统。
  

• 创建对象始终只需要一个：享元模式

  某种布局？？？答：现有布局为->
  组成更大的结构？？？答：
  
  应用场景：
  
  好处：
  
  缺点：
  

• 创建对象始终只需要一个：组合模式

  某种布局？？？答：现有布局为->
  组成更大的结构？？？答：
  
  应用场景：
  
  好处：
  
  缺点：
  

• 将一个类的接口转换成希望的另一个接口：适配器模式

  某种布局？？？答：现有布局为->方法A需要一个接口B作为参数。
  组成更大的结构？？？答：大的环境下可能C不是B的实现，但是需要用方法A的情况
  
  实现: 定义适配器Adaptee类实现接口B，然后将Adaptee作为参数传入方法A。并且在适配器Adaptee中传入C作为具体的实现依据。
  
  优点：
  目标类和适配类解耦，更换适配器的实例依据或者增加新的适配器都非常方便，符合“开闭原则”
  
  缺点
  过多的使用适配器，会让系统非常零乱，比如，明明看到调用的是A，其实被适配成B
  

类结构型模式:

• 创建对象始终只需要一个：适配器模式

  某种布局？？？答：
  组成更大的结构？？？答：
  
  应用场景：
  
  好处：
  
  缺点：
  

类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？(行为型模式)

对象行为型模式:

• 创建对象始终只需要一个：策略模式

  类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？答：
  
  应用场景：
  
  好处：
  
  缺点：
  

• 把行为封装成对象：命令模式

  类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？
  答：
  抽象命令类：
  具体命令：
  实现|接收者：
  调用|发出者：发起请求的入口(抽象命令类为参数)
  

• 代替if-else和switch???：职责链模式

  改造if-else和switch语句 怎样“相互协作”完成单个对象“无法完成”的任务？？？答：
  所有任务处理器构成一个链表，某个任务处理器执行时，若自己不能处理，这交给下一个任务处理器处理
  
  应用场景：改造判断非常复杂时的if-else结构
  

• 某些类的状态改变导致其行为发生改变：状态模式

  类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？答：类似责任链模式那样，将各种状态改成链式行为。
  

• 创建对象始终只需要一个：观察者模式

  类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？答：
  
  应用场景：
  
  好处：
  
  缺点：
  

• 创建对象始终只需要一个：中介者模式

  类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？答：
  
  应用场景：
  
  好处：
  
  缺点：
  

• 创建对象始终只需要一个：迭代器模式

  类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？答：
  
  应用场景：
  
  好处：
  
  缺点：
  

• 一触发多的 一对多 形式的触发事件传递：访问者模式

  类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？答：利用广播
  

• 使用类对象进行深拷贝,进行恢复之前的状态：备忘录模式

  类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？答：
  如今很少使用类对象来做了。现如今更多的是使用序列化的技术实现
  

• 将类抽象出来写成抽象类,其他类继承这个模板类：模板方法模式

  类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？答：子类通过继承父类进行扩展额外的操作，不需要扩展的操作直接在父类中实现。
  

• 使用类表示语法规则，可以使用继承抽象表达式扩展文法：解释器模式

  类或对象 怎样“相互协作”完成单个对象“无法完成”的任务？？？
  答：
  环境角色:定义map存储参与解释的变量和对应的值 ->
                提供:添加变量功能、根据key获取变量的功能 
  变量类：
  解释表达式：抽象表达式，定义抽象“解释(环境参数)”方法。和继承的子类