前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >面向对象的技术流程-"设计模型"

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

作者头像
别明天就今天吧
发布2020-09-07 19:32:15
7950
发布2020-09-07 19:32:15
举报
文章被收录于专栏:别明天就今天吧

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

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

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

(静态模型主要指导类的声明,类名称、属性名、方法名)

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

(动态模型指导类的实现,就是每个方法内部的具体实现过程)

静态模型:

第一步(照猫画虎):领域类映射

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

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

第二步(精雕细琢):应用设计原则和设计模式

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

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

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

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

第三步(照本宣科):拆分辅助类

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

动态模型:

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

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

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

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2020-04-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 别明天就今天吧 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档