背景：

商场收银软件，单价、数量、各种折扣活动，向客户收费

小菜：

v1.0：输入单价和数量，算出金额并累加到总额上（缺点：折扣活动未考虑，例如一会打五折、一会八折、一会不打折，不可能每次折扣变动都改动程序编译重装）

v1.1：增加下拉选择框，根据下拉选择的折扣，来计算金额并累加到总额（缺点：每次新增折扣都需要实现不同的下拉选项功能，但折扣和满减活动，逻辑规则一样，没必要每次新增类）

注意：面向对象，不是类越多越好，要对相同属性、功能的对象进行抽象处理。

v1.2（简单工厂）：正常收费（直接返回收钱数）、折扣类（初始化时传入折扣率，返回收钱数*折扣率）、返利类（初始化时传入满额和返利额，例如满300减100，即传入300和100，函数传入原始收钱数，返回按照返利规则收钱数），三种类均继承收费抽象类，然后使用工厂方法，根据收银软件下拉选择实例化不同的类进行收费。

缺点：简单工厂只是解决了对象的创建问题，工厂类包含所有的收费方式创建，商场经常性打折，每次都需要改动工厂类编译部署

策略模式

1）它定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。例如可以把使用方的变化，转移到策略模式中。

2）小菜v1.2简单工厂版本，值需要把工厂方法变成策略持有类（Context）即可，此时，算法（各种折扣、返利）使用方（收银客户端），需要根据下拉选择switch选择不同的算法类来实例化Context

缺点：变化还是没有转移到策略模式中，需进一步改进

3）改进：Context类中，和简单工厂结合（传入不同的活动信息，type），实例化不同的算法类，也就是Context方法本身就可看作是一个简单工厂类，这样客户端就把变化转移到了策略模式

4）适用场景：不同时间应用不同的业务规则，就可以考虑使用策略模式处理这种变化

5）缺点：Context中还是使用了switch语句（简单工厂根据不同的条件创建不同的算法类），每次变化还是会改动Context类

解决办法：反射，使用反射后，值需要新增对应的算法类，Context类不用改动（使用反射即可实例化对应的实例）