扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
作者:佚名 来源:中国IT实验室 2007年9月4日
关键字:
在本页阅读全文(共2页)
面向对象设计的过程就是将各个类按以上的两种关系组合在一起,这两种关系都非常简单,不过组合在一起却能提供强大的设计能力。下面介绍如何利用这两种关系来划分程序的不同模块。
在很多应用中,我们都需要将数据存储到数据库中。一个常见的解决手段是使用分层的方法,将程序分为应用层和存储层,Figure 4中是这种方法一个不太成熟的设计:
Figure 4 |
Application代表应用层的逻辑,DB代表了数据库访问的逻辑,在这个设计中,Application直接调用了DB的服务来将数据存储到数据库中。这样做的缺点是Application对DB有了依赖关系,一旦DB有了任何变化,Application都有可能会受其影响需要改动。当然,如果只是两个类的话,这种依赖关系根本算不上什么问题,然而,我们有理由相信,应用层和存储层都会由不只一个类组成,并都有一定的复杂度,这时它们之间的这种依赖关系就会让人头痛了。当程序的模块越来越多,如果不限制它们之间的联系,那模块间的依赖、程序的复杂度和开发维护的难度都会成指数上升。
所幸的是引入面向对象中的继承关系,我们可以解决这一问题,如图Figure 5所示:
Figure 5 |
Persistence是一个接口,其包含了Application存储所需用到的服务。DB实现了这个接口,Application则调用Persistence中的服务来存储数据,两者都只依赖于Persistence。这样,Application到DB的依赖关系被Persistence这个接口切断了。因为接口中只包含了服务,也就是成员函数的声明,而不包括任何数据和函数的实现,所以Persistence接口的内容会很简单。在Persistence不变的情况下,Application和DB这两个模块都可以自由地进行修改而不影响到对方。就这样,通过在中间插入接口的方法,程序的模块被划分开,依赖关系也变得容易管理的多。
如果从另一个角度来看Figure 4中的设计,应用层是程序的核心部分,而存储层则可以看成是实现的细节,这个设计犯了和过程式设计同样的错误,即核心逻辑依赖于具体的实现细节,这样,当细节变化时,核心逻辑也会受到影响:假如,当我们需要将数据改存到文件或目录服务中时,按照Figure 4中的设计Application模块就难免受到影响。在Figure 5的设计中则没有这一问题:这里我们可以把Application和Persistence看成是程序的核心逻辑,而Persistence接口的实现(DB)可以看成是程序的细节实现,其依赖关系是细节依赖于核心,当细节变化时核心不会受其影响,这才是一个稳定的依赖关系。遵从这一设计,我们可以在不影响程序核心的情况下,为程序添加或更改存储类型,如Figure 6所示:
Figure 6 |
这里值得注意的是Persistence和Application被划分到了一起,这是因为Persistence中的服务都是根据Application中的需求制定出来的,Persistence和Application的关系比起它和其子类的关系更加紧密。将接口和其调用者放入一个模块是一个常见的做法,当然,也可以将接口单独划分为一个模块,这一般是在有多个不同的调用模块依赖于该接口,或不同模块间需要更清晰的分离时才这样做。
例子
接下来我们将通过一个小例子来看看这两种设计方法的不同:假设我们有一个图形处理的程序,这个程序需要一个计算各种图形面积的功能。
如果用过程式的方法来设计这个功能,可以得到下面的这些代码:
|
如果您非常迫切的想了解IT领域最新产品与技术信息,那么订阅至顶网技术邮件将是您的最佳途径之一。
现场直击|2021世界人工智能大会
直击5G创新地带,就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020(Cloud)- 科技行者