1700465884
public static void main（String[]args）{
1700465885
1700465886
//输入的两个参数是数字
1700465887
1700465888
int a=Integer.parseInt（args[0]）；
1700465889
1700465890
String symbol=args[1]；//符号
1700465891
1700465892
int b=Integer.parseInt（args[2]）；
1700465893
1700465894
System.out.println（“输入的参数为：”+Arrays.toString（args））；
1700465895
1700465896
System.out.println（“运行结果为：”+a+symbol+b+”=”+Calculator.ADD.exec（a,b））；
1700465897
1700465898
}
1700465899
1700465900
}
1700465901
1700465902
运行结果与方案一相同。看这个场景类，代码量非常少，而且还有一个显著的优点：真实地面向对象，看看这条语句：
1700465903
1700465904
Calculator.ADD.exec（a,b）
1700465905
1700465906
是不是类似于“拿出计算器（Calculator），对a和b进行加法运算（ADD），并立刻执行（exec）”，这与我们日常接触逻辑是不是非常相似，这也正是我们架构师要担当的职责！
1700465907
1700465908
注意 策略枚举是一个非常优秀和方便的模式，但是它受枚举类型的限制，每个枚举项都是public、final、static的，扩展性受到了一定的约束，因此在系统开发中，策略枚举一般担当不经常发生变化的角色。
1700465909
1700465910
1700465911
1700465912
1700465913
设计模式之禅 [:1700454000]
1700465914
设计模式之禅 18.5 最佳实践
1700465915
1700465916
策略模式是一个非常简单的模式。它在项目中使用得非常多，但它单独使用的地方就比较少了，因为它有致命缺陷：所有的策略都需要暴露出去，这样才方便客户端决定使用哪一个策略。例如，在例子中的赵云，赵云实际上不知道使用哪个策略，他只知道拆第一个锦囊，而不知道是BackDoor这个妙计。是的，诸葛亮已经在规定了在适当的场景下拆开指定的锦囊，我们的策略模式只是实现了锦囊的管理，但是我们没有严格地定义“适当的场景”拆开“适当的锦囊”，在实际项目中，我们一般通过工厂方法模式来实现策略类的声明，读者可以参考混编模式。
1700465917
1700465918
1700465919
1700465920
1700465921
设计模式之禅 [:1700454001]
1700465922
设计模式之禅 第19章 适配器模式
1700465923
1700465924
设计模式之禅 [:1700454002]
1700465925
19.1 业务发展——上帝才能控制
1700465926
1700465927
有这样一句名言“智者千虑必有一失，愚者千虑必有一得”[1]，意思是说不管多聪明的人，经过多少次的思考，也总是会出现一些微小的错误，“智者”都是如此，何况我们这些平庸之辈呢！我们在进行系统开发时，不管之前的可行性分析、需求分析、系统设计处理得多么完美，总会在关键时候、关键场合出现一些“意外”。对于这些“意外”，该来的还是要来，躲是躲不过去的，那我们怎么来弥补这些“意外”呢？这难不倒我们的设计大师，他们创造出了一些补救模式，今天我们就来讲一个补救模式，这种模式可以让你从因业务扩展而系统无法迅速适应的苦恼中解脱而出。
1700465928
1700465929
2004年我带了一个项目，做一个人力资源管理项目，该项目是我们总公司发起的，公司一共有700多号人。这个项目还是比较简单的，分为三大模块：人员信息管理、薪酬管理、职位管理。当时开发时业务人员明确指明：人员信息管理的对象是所有员工的所有信息，所有的员工指的是在职的员工，其他的离职的、退休的暂不考虑。根据需求我们设计了如图19-1所示的类图。
1700465930
1700465931
1700465932
1700465933