下面是系统设计。
这里呢由于当前是一种这个外部应用系统。
所以呢, 这个系统设计呢,它有自身一些特色。
就是说这里面包括一些内容,我们前面讲到一些 各个部分的一些设计,它不一定全部都会使用得到,这个问题域部分是
需要的,人机交互也是肯定的,但是我们这少了一个什么呢,控制驱动部分的设计。
控制驱动部分知道它是一个,它本身当然是一个大型的,外部应用系统是一个并发系统,但实- 际上呢,
借助于操作系统和中间件应用服务器,数据库管理 系统实际上呢可以将一个在
部署的时候,在执行的时候将一个顺序系统给它变成一个 多并发的一个系统,但是在我们软件开发的时候实际上没必要,
自己在编写程序的时候没必要进行这个控制驱动部分的一个 设计,所以这一部分呢我们可以省略。
然后这个 数据管理部分,它本身这是一个数据密集型的一种应用,所以 在数据管理部分实际是一个非常重要的一个应用。
另外呢,这个构件部署部分的设计,这是一个什么呢? 这是一个也是因为它是一个分布式系统,所以这也需要的。
那么首先看一下这个问题域部分的设计。
问题域部分的设计这时候就相对来说呢,就是 复杂一些。
因为这时候呢需要注意的问题包括这个 这个以分析类图作为起点,
然后把这个中文变成英文,然后标注一些可见性和类型式的类, 非常详细和完善,便于以后实现为这个java的类
另外呢就是与这个基础软件和开发技术,便利要修改我们这个 模型。
这里呢这个需要考虑的问题的问题域部分,一个方面是复用,包括
尽可能复用已经存在的一些类和这个为以后的这个版本 和这个人类的一些其他的系统提供一个方便的复用
机会,另外就是性能考虑,再就是这个去除没必要的关联以及调整泛化关系,根据我们这个当- 前的这个 系统。
再就是应用设计模式。
本系统的这个实际情况是我们是一种BS浏览
器服务器的一种架构,并且是基于java的一种轻量级的平台,在这个SS框架中
这个Hibernate在ORM的时候,实际上呢他这个要求一种POJO对象。
什么是POJO对象呢?就是非常简单的一个属性,但是这个属性里面呢 这个类呢是一个对于一些永久,对于这个需要永久
性存储的这么一些这个对象。
我们要建立它的POJO对象,这样便于 让Hibernate这个框架和我们系统之间产生一种非常 这个统一的接口。
什么是POJO对象呢? 这个POJO对象,它实际上呢是不允许有一些
复杂的一些业务封装,复杂业务逻辑的一些操作。
它 也有一些这个需要这个存储的它的所有的一些所有的属性,各种各样的类型。
然后呢,它的方法是什么呢?就是get set方法,就是设置这个某一属性的值和取这个某个属性的值。
所以这就是什么是POJO对象,它要求这个。
所以我们在问题域部分的设计 的时候,我们就要尽可能地往这上面靠,我们要变更我们的系统分析模型,
然后呢让它们来进行这个 这个非常好的支持这个Hibernate框架。
这是 一个方面,另外就是要综合运用多种设计模式。
另外这个主动对象由界面承担,所以这个
在这个进行设计的时候实际上是比较简单的。
下面我们看一下这个问题域部分的设计。
在这个设计过程中呢, 我们对刚才我们这个系统分析的那个类图进行一个调整,根据一些问题
其中就是在调整的过程中呢,这个 我们可以看到呢就是
我们加上了什么呢,我们把一些持久、 持久的一些对象
我们进行了一个改写,就是说我们把它们拆分了,比如说一个 管理员是需要持久化的一个对象。
这个管理员呢我们变成了一个什么呢?一个这个 manager,一个manager的类。
还有一个是什么呢,与他对应的这个,一个POJO对象。
这样的话呢就是说我们把这个 一复杂的一些业务逻辑封装在这个管理员manager。
但是那个管理员本身的一些信息,一些这个关联的一些 属性的信息,加上getter
setter,然后我们把它变成一个POJO对象, 把它变成与它有关联的这么一个对象。
这样的话就是 所有的这个管理员,所有的持久化的一些类呢我们全部给它
变成一拆为二,就是变成一个manager的一个类。
然后呢,与它相 变成一个依赖关系,就是一个什么呢?真正的那个 用户和管理员。
它们之间为什么是一种依赖关系呢,就是因为它们之间不是在实现过程中呢,
并不是一种嵌入对方,指针的那种方式来进行实现的, 而是这个用参数的方式,这个调用这个
在这个manager这个类中,取得用户,比如说,它实际上是
这个传递了一个用户的一个引用。
这样的话来 实现取得用户。
所以它们之间是一种参数的一种这个依赖关系。
所以这时候呢不是关联关系。
这里面我们把这个用户
和把以前这个系统分析的时候的这个,OA的时候的用户一拆为二,变成用户和用户mana- ger。
管理员变成管理员和管理员manager,然后这个
读者变成读者和读者manager,订单变成订单和订单manager,等等。
这是 这个我们需要注意的。
好,另外呢我们就是把这个 变成英文了,是吧。
为了便于实现我们把所有的这些 类名啊,和这个操作,属性啊,方法啊全部变成了英文。
这是这个给出我们这个英文的这么一个 进一步的,中间的这个类图,中间有个调整的过程。
这是一个 当然说对于一些购物车来说,它不需要这个进行这个POJO,它本身是个存在内存中的一-
个对象。
它没有必要持久化。
所以, 至少在当前的应用中,这个需求中,没有把这个购物车持久化。
所以这时候我们可以看,大概看到这个 所有持久化的类全部一拆为二,一个是manager,一个是这个customer。
customer本身被 这个变成一个简单对象,POJO对象,它只有属性和getter setter方法。
而真正的一些复杂的业务逻辑被封装在了这个manager里边,而它们之间 两者之间是通过一种参数调用关系。
另外呢我们 这个用到了三种设计模式,一个是抽象工厂,一个是 Facade,一个是Strategy。
这个抽象工厂呢就是用于进行一些这个 产生对象的时候,我们借助于Spring框架实际上不需要我们这个用
编程序的方式来进行这个,生成一些对象把它们组装到在一块。
而是我们通过一些Spring中的一些 xml的这么一些文件。
在那个里面来实现 描述哪个对象是装配上那个对象的一个部分。
然后它实际上有程序有框架, 自动的会帮我们完成,这个本身这个抽象工厂不需要我们编写
代码来实现,这个我们就不多说了,另外我们重点看一下这个后面两个。
首先这个Facade,我们这个后面重点介绍。
Strategy呢 实际上就是我们刚才提到的。
由于这个当前呢, 在打折的时候,由于不同的算法,是吧。
它综合 运用,综合运用,有的时候用这个,有的时候用那个。
这个时候我们就会 为了这个统一接口的时候,就是统一他们的这个操作。
但是呢我们这个 它们的这个实现起来的这个方法是不一样的,也就是要什么样的对象有什么呢,
多态的方式来进行实现。
这个就是到设计模式的专门的一个 Strategy,其实就是我们所说的多态,统一这个复用接口来实现。
好,这个Facade呢是什么意思呢,我们看一下这个 Facade,这里呢,我们先看一下这个
之前的Strategy,就是在当前的这个
打折器,就是IDiscountManager。
这么一个类,它是一个接口。
这个借口这个它实际上是 由这个提供了一些,不管是这个
什么样的打折,它统一接口,统一接口之后呢,这个到底是由 哪个具体的打折器来完成。
这里呢它后面有一个实现,就是不同的类 比如说一些这个根据顾客的类型来进行打折。
用customer discount
根据当中一个时期,一个序列,图书序列,用这个serial discount。
根据实效性打折,用time discount。
根据庆典来打折,进行庆典打折器。
所有这些实际上是分别要实现就是get discount price和get discount
type,这么两个这个 操作,但是实现的这个方法,具体的方法是不同的。
但是对于打折器来说呢,只要调用这个 idiscountmanager
的一个接口, 它会自动的根据这个实例化,或者给它装配的那个具体的那个打折器来进行打折。
最后呢如果说是有一个这个综合打折,由那个 final discounter,把这个所有的综合打折
这个根据综合大,取最,取这个所有可能打折的一个最小的一个
最低的一个折扣,来进行这个描述。
所以这里用到的这个模式,就是 strategy,其实就是最简单的这个 面向对象中的这个多态的这么一个。
这是第一个,第一个是 strategy 的这个模式,这个比较简单。
下面我们看看这个第二个就是 facade,这个 客面这个类,为什么要用到这样一个类呢?实际上就是
这就是牵扯到了我们那个 manager
和这个本身 这个 manager 本身是表示这个业务逻辑,封装业务逻辑类,
而这个业务逻辑所有的这个类呢,需要在这个完成它固定的一个业务逻辑的时候,它需要 调用那个
orm,或者说一些数据库的一些查询啊, 增删改查的那些类的一些操作。
这时候呢 如果说是这个,我们这里大概所有的这些
我们可以看到,booktypemanager 这个所有的这个
customermanager,还有什么 用户 manager,这些
manager 呢 它们这个由不同的,比如说它需要
这个对每一些,对它相应的一些表都需要增删改查。
突出类型的这个 manager,它要增加一个突出类型,
减少一个突出类型,修改一个突出类型, 这个还有一些其它的一些业务逻辑。
它这个对于顾客的那个 manager 它需要增加顾客减少一个顾客 修改一个顾客。
对于那个订单那个 manager,增加订单,减少订单,删除订单。
并且它需要什么呢,需要这个编程的时候,开发的时候 需要将某一个
manager 与其另外的一个什么呢,后面我们讲到的那个 这个 orm 那个类来进行一个关联。
这样的话这个编程序人的这个记忆非常复杂,也就是说这是一个
这个负责,如果是开发通过不同的用户来进行这个划分的话,
是吧,在当前这个业务逻辑这块,有一个程序员来负责,
后端有一个程序员来写 orm,这相当于两个包,这两个包实际上这个不同的这个
类之间,包和包之间实际上是一种错综复杂的一种 关联关系,这是我们不愿意看到的。
这样的话呢 对于开发人员来说他要有一些额外的记忆的负担,他需要记住
当前这个 manager 需要与其它的另外的一些 orm
中的哪些类需要打交道, 这是这个他增加的额外负担。
另外呢 这个为解决这个问题呢,就需要我们呢 建立一个 facade。
就是说你不要这个,你当前的这个程序员,不要 不需要这个考虑来与另外一个包中的哪些类来打交道了,我
就给你建立一个统一的一个 facade,这么一个客面, 你就直接找它,有什么问题找它,由它作为一个中转
然后它会自动的根据这个实际的情况给你找到相应的一个 类。
所以这叫 facade。
所以在这过程中我们建立了 什么呢,建立了这个 facade,这个 facade
实际上呢这个真正的 c++ 的设计模式的时候,这个 facade
实际上是一个多重继承了 被调用的那个这个服务器
包的一些相关的一些类,这样的话它既然多重继承了
这个所有的类,那么它就把所有的类的一些操作全部都容纳在当前这个类里边。
这样的话呢,不管你调用哪个 增删改查,你只要找到这一个类,它就会自动地
帮你把这个消息转发到其它类中,或者说是直接在这就实现了。
但是我们现在是用 java 来实现,这个 java 它不支持
多重继承,我们在 java 如何实现 facade 的这个设计模式呢?
这时候我们就需要应用一个变通的方式。
那就我们这个实际上 既然这个 java 中这个类和类之间没有多重关系,但是这个
java 中这个接口和接口之间却是有这个 继承关系,所以我们多重继承关系,所以我们先用这个
搞一个 interface 之间的多重继承,所以我们建立了一个 interface, interface这个
ifacade 这个类,这个类呢实际上多重继承了所有的那些
这个 customer 这个 manager。
然后呢这个 它怎么实现,当然光有接口是不行的,但是最后实现起来呢是完全是通过什么呢?
委托关系,通过委托,就是由真正的这个 manager
呢,与这个相应的这个 后台的一个这个 facade
发生一个关联关系,来这个实现这个 通过这个委托的方式,发送消息的方式来实现。
需要这个用明显的这种方式
不是像那个多重继承,类之间的多重继承,直接继承过来就可以用了,它这只是多重继承一个- 接口,然后
这个接口是怎么实现的呢?有后台的一个实现类 这个通过向相应的类发送消息的实现,是这么一种
情况,这样的话呢就可以比较好的解决这个问题。