面向对象的技术流程-"设计模型"

设计阶段是整个面向对象分析和设计的高潮阶段。在设计阶段，我们将要输出设计模型，并且需要综合各种方法技巧，做出满足各种需求的设计。

设计模式主要包含两部分内容：静态模型和动态模型。

静态模型又称为"类模型",主要关注系统的静态结构，描述系统包含的类，以及类的名称、职责、属性、方法，类间关系。

（静态模型主要指导类的声明，类名称、属性名、方法名）

动态模型关注系统的动态行为，描述类本身的一些动作或者状态变化，以及类之间如何配合以完成最终的业务功能。

（动态模型指导类的实现，就是每个方法内部的具体实现过程）

静态模型：

第一步（照猫画虎）：领域类映射

根据领域模型输出的领域模型图，把领域类转换为软件类，需要注意"软件类"是系统内部的一个概念，而领域类是业务领域的概念，并不是每个领域类都会最终体现在软件系统里。

如图，就像"顾客"、"屏幕"、"键盘"、"扫描仪"不需要转换。然后创建类和属性，接下里还需要创建方法，但是方法从哪来？在用例模型的描述中找动词，找到动词之后进行筛选去掉非软件类的动作，然后将找到的动词分配给软件类，比如"增加商品"、"计算总额"分配给交易类,得到如图：

第二步（精雕细琢）：应用设计原则和设计模式

事实上很多人在完成上述的工作就开始编码，其实满足用户需求只是最简单的要求，而不是一个"好设计"，怎么才能做到一个好设计呢，这时候就用到了"设计原则"、"设计模式"。

其实我们应用"设计原则"、"设计模式"的根本目的：可扩展性。

从设计原则（指导类的定义）看，我们发现交易类直接依赖会员卡类、购物卡类、现金类、信用卡类，不符合DIP原则，也就是高层与低层都要依赖抽象，这时我们提出一个支付接口或者抽象类，交易类依赖支付类，会员卡类等也依赖支付类。

然后从设计模式（指导类的行为）看，我们发现"信用卡"类存在优化的空间，因为国际上存在不同的信用卡，每种信用卡在支付的时候都需要接口入不同的机构，接入方式存在差异，为了封装这种差异，我们使用Bridge模式，提取信用卡处理类，这个类的职责主要是连接、认证、扣款。Unipay、Visa、MasterCard都继承信用卡处理类。

第三步（照本宣科）：拆分辅助类

经过前两步的设计，设计工作基本完成，但是还有一个小动作也需要做，那就是拆分辅助类，主要目的是使我们的类在编码的时候能满足一些框架的规范，比如MVC模式，购物卡类需要拆分为购物卡类和购物卡DAO类，如图

动态模型：

主要有4种：状态模型、活动模型、序列模型、协作模型

我们基于买单这个用例的正常分支设计如图：

系统中会有很多功能，重要的功能使用动态模型来描述出来即可。

模型的目的：指导代码的编写。