javaweb 设计模式

• 开闭原则
  对源代码的扩展是开启的、对代码修改是关闭的

• 单一职责原则
  就是一个类，按照职责进行功能设计。保证一个职责只能出现在一个类当中SRP，或者这样说更好，一个类被设计只能存在一个职责，保证后续的职责改动带来最小的影响。

• 里氏代换原则
  子类型可以替换掉基类型，换言之，子类型是在父类型基础上的扩展，而没有修改基类型原有的功能。

• 依赖倒换原则
  关注接口进行编程，不要去考虑实现类的编程，保证需要实现的功能能够体现在接口中，不要将功能体现在实现中，而不存在接口中。（相比上一个原则更加严格，最好是要求层级之间的一致）

• 接口隔离原则
  保证每一个接口能够按照功能进行最小化设计，避免之后的实现类出现实现无用的方法。

• 迪米特法则
  通过第三方类来实现两个实体类之间的通信。

• 工厂方法

  • 简单工厂
    通过依赖倒换原则设计好产品的实体类还有接口，设计一个通过传递参数返回具体的对象的接口（是一个是类，不是接口）；一旦扩展产品需要修改对应的工厂方法。打破了开闭原则。

  • 工厂方法
    使用工厂方法是首先也是需要通过依赖倒换原则设计好产品的实体类还有接口，之后和简单方法不同的是，工厂方法是通过实例化不同产品对应的工厂方法来获取对应的产品对象。就算是添加了产品对应添加实现该产品的工厂就行了。

  • 抽象工厂模式
    我觉得就是对上一个模式的升级吧，也就是我们可以对已有的工厂接口在组合生成新的工厂接口，或者添加新的工厂接口。但是实现对应的产品依然是通过对应的工厂实现来实例化对应的产品。

• 单例模式
  就是一个应用从开始到结束，某一个类型值只存在一个实例。

  • 饿汉
    提前创建好并且实例化好静态对象属性，然后通过静态方法进行直接返回。

  • 懒汉
    创建好产品的属性，但是不对其进行实例化，然后通过在静态方法中判断静态属性是否已经实例化，如果没有实例化就创建返回，否则直接返回。

• 建造者模式
  首先是有一个产品，内部结构复杂。定义实现接口，实例化改接口，出现对内部结构不同的实例，创建一个调用接口，通过传递过来的创建实例来返回对应结构表现的产品，个人觉得这个使用并不常见，因为现在最求最简，我们一般不会把一个类设计的很复杂，而会对一类型出现不同表现的实例，就算有，很多都是从构造函数就解决了这个事情

• 原型模式
  就是通过已有的对象不断赋值新对象，在java中我们依赖clone接口进行实现。

• 适配器模式

  • 类适配器
    使用类适配器可以，通过对适配器进行多接口的继承实现客户端的要求

  • 对象适配器
    通过将需要的接口作为属性放在适配器中，也就是通过组合的方法

  • 接口适配器
    通过抽象类，对接口实例化来排除我们不需要的方法，以及使用我们需要的功能，这一般都是因为接口提供的方法太多，很多有可能并不需要。

• 桥接模式
  将抽象与具体的实现分离，减少了系统中类的定义，通过聚合的方式。

• 组合类别
  因为在项目中经常操作属性结构数据，所以很认真看了和模式，这个模式的作用就是提供了一种度与容器和叶子节点一致操作的方案，可以保证系统拥有更好的扩展性，它的核心就是提供了统一的操作接口，但是这个无疑对于叶子节点来说违反了接口隔离原则，因为叶子节点也要实现容器节点的操作。但是我们可以使用适配器模式解决这个问题，通过使用一个公用的接口先初始化所有的接口中的方法，然后在叶子和容器中存在对各自所需的方法的实现。

• 装饰者模式
  顾名思义，也就是这个对象被生产之前会对其进行一些修饰，大前提是在一个主接口或者是抽象类或者是类中

• 门面模式
  动里不动外，将内部的行为进行组合，对外外部的客户端访问的内部行为进行清理，达到最简行为。显然这个不符合接口隔离原则。

• 享元模式
  有点类似于单例模式，即应用从始至终对象只是出现一个，模式中有详细的角色划分是这个模式的特殊之处？通常我们在工厂中定义一个map用来存放享元对象，如果已经在map中存在就不会在创建 而是直接进行返回。

• 代理模式
  因为最近也在对aop的理解和使用，所以这个模式我也非常认真看了下 （通过代理类转发客户端的请求调用，转发给委托类，将委托类处理之后的结果返回给代理，然后代理又可以将数据返回给客户端，这个之间添加了一层代理层，可以对请求的数据以及相应的数据进行处理，而且对于一些和委托无关的功能我们也可以添加在代理上面，）

  • 静态代理
    委托类和代理类通过实现同一个接口，在代理类中通过组合的方式，代理委托类的方法，这个很像修饰模式的手段。感觉很像
  • 动态代理
    
    • jdk动态代理
      使用jdk动态代理，InvocationHandler通过实现该接口，然后使用组合的方式，但是这种代理对于所有的调用方法都是通过InvocationHandler 内的invoke进行代理处理的，所以走的是同一套代码，我我觉得这样实现扩展性不高。而且这种代理方式依赖接口，需要统一的接口。
    • cglib代理
      感觉和静态代理并没差很多如果在代码设计上，jdk动态代理需要提供一个接口，但是动态代理不需要提供接口，但是还是通过实现该InvocationHandler接口，组合委托类，并且实现获取委托类的方法。感觉和很普通自己手动写代理来讲扩展性并不好，虽然减少了代码量。

• 责任链模式
  一开始看这个模式的定义，怎么像是拦截器的作用一样。事实就是这样的。

• 命令模式
  就是减少调用者和执行者之前的耦合性，并且调用者无需知道到底是哪个执行者在执行我的命令，只需要调用对应的命令即可，这个 不也增加了命令和执行者之间的耦合

• 解释器模式
  并不常用

• 迭代器模式
  大家应该使用过迭代方法，就是能够按照顺序进行遍历一个聚合对象内部各个元素，而不需要直达内部元素的表示。比如我们使用for遍历list，必须明确内部的元素是某一种类型，但是用迭代器我们通过hasnext来遍历对象，模式并不复杂，涉及的角色，容器、具体容器、迭代器接口，具体的迭代器

• 中介者模式
  通过平台进行对象数据之间的通信。

• 访问者模式
  将数据操作和数据结构分离的设计模式，使用频率不多

• 模板模式
  定义一个模板结构，将具体的实现在子类中完成
  提高代码复用性
  将相同部分的代码放在抽象的父类中，而将不同的代码放入不同的子类中
  实现了反向控制 （最重要）
  通过一个父类调用其子类的操作，通过对子类的具体实现扩展不同的行为，实现了反向控制 & 符合“开闭原则”，多用组合少用继承

• 状态模式
  很像策略模式，是根据动作和执行动作之后状态的一种设计模式

• 观察者模式
  也就是发布订阅模式
• 备忘录模式
  在对象外保存对象的状态

总结：
多用组合少用继承

如果所有的状态都有共同的数据域，可以使用抽象类，但如果只是单纯的执行动作，就可以使用接口

尽量保证能够实现反向控制，保证子类和父类存在同样的操作方法