庄周梦蝶

生活、程序、未来
   :: 首页 ::  ::  :: 聚合  :: 管理

java package的设计原则

Posted on 2008-09-06 00:15 dennis 阅读(2715) 评论(3)  编辑  收藏 所属分类: java
    典型的J2EE项目,package的设计有成熟的套路可循,如分为domain、dao、service、action等等,职责已经分解的比较单一和清晰,循环依赖这样的情况出现并不多。而在一般的java项目,如服务器程序、客户端程序和通用性框架的开发中,包的设计并没有套路可循,毕竟由于应用和业务种类的不同,想得出通用性的设计套路是不大可能的。这时候遵循一些原则比之生搬硬套更为重要。在《敏捷软件开发》一书中对包的设计有深入的讨论,虽然针对的是发布的二进制包而言,但是对于java package的设计同样有借鉴意义,如对包的内聚性、可重用性、稳定性的强调,对于依赖的探讨,这些都是比较笼统的概念,不是那么直观,需要在实际运用中认真归纳和重构,向这些原则靠拢。
   我所想到一个比较直观的方法就是:对于一个包的描述,你是否能用一句简明扼要的话概括,也就是包的功能或者说介绍能否做到简明扼要,这是衡量一个包的设计是否合理的最简单的方法。如果可以,显然这个包的内聚性很好,所有的类都服务于一个目的,从而带来了重用的可能(其实我对重用性并不感冒,除了工具类外真正能重用的东西少之又少,内聚性才是需要关注的);反之,这个包可能承担了太多的职责或者依赖过多,仔细的重构和分离是需要做的。包的设计同样要遵循接口分离的原则,将接口与实现隔离在不同的包之中,客户程序就不会知道具体的实现,并且也保证了实现对接口的单向依赖。当然,这时就需要引入工厂类、插件或者IOC容器来负责实例化实现类。

评论

# re: java package的设计原则  回复  更多评论   

2008-09-06 10:06 by Jack.Wang
接口与实现隔离在不同的包之中是个比较好的实践,赞同。
关注点分离永远是软件开发架构的重点,LZ说重用甚少,开发软件如果架构允许的话我们都会 import 第三方组件,such as apache commons and so on. commons 重用的原因是因为和业务无关,没有依赖性,当然和业务有关的也可以重用,这也就是 SOA 的理念之一了。

# re: java package的设计原则  回复  更多评论   

2008-09-07 22:19 by dennis
@Jack.Wang
重用的粒度问题,而我说谈的重用局限在代码级别的重用。

# re: java package的设计原则  回复  更多评论   

2008-09-08 10:11 by zhuxing
赞同楼主观点,包的设计应该是在通用的设计原则的指导下完成

应该以很多个维度来综合地看待这个问题,尽量考虑到各个规则(例如尽量分离抽象和实现,更好的遵循开闭原则....),不要和经典的规则发生冲突~_~

有的人可能更喜欢从技术视角进行划分,例如可能会出现**.factory类型的包,里面放置了供用户调用的工程类;有的人则可能更喜欢从业务角度进行划分等。

大的原则是存在的,具体细节因人而异 ^_^。

只有注册用户登录后才能发表评论。


网站导航: