Head First设计模式之策略模式

设计模式

在具体开发中, 我们会遇到很多问题, 如设计导致代码可扩展性受到限制, 两个或者多个模块间耦合比较紧等等导致代码可扩展性下降. 这些, 前人已经解决过了, 我们要做的就是学习如何应用这些"经验".

不同于代码开发, 我们要做到的代码复用; 而进行设计模式的使用, 更多的经验复用.

OO基础

• 抽象
• 继承
  设计好一个继承是OO设计的基本要求,但是很多时候继承并不能满足, 甚至导致代码的臃肿混乱的原因, 设计模式更多的是针对OO原则进行补救.
• 多态
  在程序运行时决定使用具体类的代码, 多态的实现依赖于接口, 抽象类, 基类
• 封装

OO原则

1. 分离出变化的部分
2. 针对接口编程,而不是针对实现编程
3. 多用组合,少用继承

策略模式

策略模式 定义了算法簇, 分别封装起来, 让他们之间可以互相替换, 此模式让算法的变化独立于使用算法的客户.

解决了什么问题

背景是 想要在大多数的子类中增加新的方法,比如是增加飞行行为, 如何进行呢?

• 不好的解决方法
  1. 使用继承在基类中增加飞行行为, 所有子类自动继承基类方法.
  2. 将飞行行为单独增加一个接口, 让子类去实现

• 导致的问题
  1. 针对使用继承, 将导致不需要飞行行为或者飞行行为不符的时候需要覆盖, 如果涉及子类过多将导致过于复杂,
  2. 针对使用接口,让子类去实现的办法将导致子类代码增多, 最主要的是代码没有得到复用.

如何解决的

1. 抽取出变动的代码部分, 独立出来
2. 针对接口编程, 将变化 可替换的部分抽象成一个个接口, 由具体类定义行为, 生成一个算法簇.
3. 使用组合, 基类依赖接口, 由子类动态选择具体类行为

适合应用的场景

• 适合针对某种行为有多种实现

应用示例

• 库存入库操作, 如采购入库 , 无订单入库, 内部领用退回入库, 销售退回入库等多种操作
• 营销规则计算, 比如会员种类的不同享受的折扣以及计算方式不同
• 新建组织机构时, 根据机构类型进行新建

缺点

• 使用放需要知道所有的实现(策略)
• 适合多种的策略选择场景 , 如果策略变动比较少以及策略选中的种类较少 ,没有必要进行独立

设计模式入门

共享词汇

目前还是理解为行话, 开发之间或者设计之间讨论实现过程中更好进行沟通.

如何学习以及使用设计模式

将设计模式装入脑中, 在具体设计时进行寻找.

找不到设计模式怎么办

有一些面向对象原则适用于大多数的设计模式, 当找不到设计模式时, 采用这些面向对象原则.

在本章中留下的问题

• 在解决鸭子问题时,独立出接口,让子类去实现, 在java8中接口已经可以有默认的实现了 , 这种方法是否可行? 待验证
• 如何在子类优雅的选择策略(整合策略)或者说子类如何决定使用哪一种策略:
  • 有的人是根据枚举定义与具体的策略进行绑定;
  • 有的是直接set进行设置;
  • 还有的是根据spring的注解value值进行绑定(类似的, 使用自定义注解让程序启动时与对应的策略进行绑定);

---

1. 将飞行方法独立出来, 作为接口, 具体的飞行行为实现飞行接口进行实现,生成飞行算法簇; 鸭子类将依赖飞行行为接口, 由子类进行选择飞行行为. ↩︎