模式17:Levelize Build

依照模块的层级化来执行构建。 一个开发项目是否成功,与它是否拥有一个“自动化且可重复的构建过程”紧密相关。一个很重要的原因就是它能迫使你很早就开始并且频繁的集成你开发的系统,这样一来你就确保了你总是能拥有一个可以工作的系统。


Java应用架构读书笔记(8):<mark>OSGi</mark>与模式

当为目标平台提供模块化的运行时支持时,模块化软件的优点将体现得更加充分。OSGi是业界模块化方面的事实标准平台。运行时模块系统并非开发模块化软件的必须,但是一个好的运行时模块系统,比如OSGi,能够为我们的开发带来极大的帮助。


模式18:Test Module

每个模块都应该有一个对应的测试模块。 作为一个开发者,做好单元测试是至关重要的。一个测试模块可以让你把单元测试以模块为单位组织起来,每个测试模块对应一个需要被测试的模块。以下图为例,testclient.jar就是负责特使client.jar的模块。


Java应用架构读书笔记(9):OSGi的未来

KirK Knoernschild在《Java Application Architecture》中讲到了OSGi的未来。对于正在采用OSGi以及准备开始学习OSGi的人来说,OSGi的未来的确是一个需要考虑的问题。这里简单总结一下KK在概述中表达的观点。KK的主要观点在于OSGi有助于建立一个Java的生态系统。 以下只是KK观点的一些总结而已,并不表示我们完全同意他的所有观点。


模式6:Physical Layers

模块之间的关系应该符合系统在概念上的分层。 当软件开发者设计复杂的软件系统时,通常会把系统划分成三个层次:展现、业务逻辑、数据访问。但是仅仅是逻辑分隔是不够的,我们还需要进行物理分隔以提高软件复用性。


模式11:Default Implementation

缺省实现有助于平衡可用性和复用性。由于提供了缺省实现模块很容易被使用,同时又可以通过提供接口,在新的环境中以新的实现对其进行扩展。


模式16:Colocate Exception

异常类放置的位置应该靠近抛出该异常的接口或者类。 对于异常的处理,往往都是在系统开发的后期才做的,或者说对于某个功能来说,认真考虑该功能可能抛出的异常及其处理,一般都是在该功能实现的后期才做的。这个时候就会涉及到异常类摆放在哪的问题。异常类的摆放会影响系统的模块化程度,更具体来说,会影响系统模块间的依赖结构。比如错误的将异常放置在捕获异常的模块里,就容易造成循环依赖:捕获异常的模块依赖抛出异常的模块;而抛出异常的模块因为异常类定义在捕获异常的模块里,所以它又不得不依赖于后者,造成循环依赖。


模式9:Published Interface

让参与者都清楚的知道你的模块所发布的接口。 众所周知(也是老生常谈):一个模块应该封装了它的实现细节。所以理想情况下一个模块会暴露其API来作为其它模块与其交互的方式,而且这些API应该易于理解。


模式4:Acyclic Relationships

模块关系中不能存在循环依赖. 当在两个系统模块之间定义关系的时候,它们的耦合度会增加。因为模块需要互相协作来完成任务,所以一定程度的耦合是必须的。但是,循环依赖需要避免。如何判定一个依赖是循环的呢?对于一个模块A,将A直接或者间接依赖的所有模块依次加入集合中,如果发现A再次被加入集合,那么说明模块结构中存在循环依赖。


模式12:Module Facade

创建一个表面作为进入其他细粒度模块内部实现的粗粒度接口 我们创建细粒度的、轻量级的模块来增加模块复用性。不幸的是,由于使用者必须明白很多不同模块的API以及联合起来使用它们来完成某项任务,这些细粒度模块很难使用。此外,轻量级模块必须被配置到环境上下文中。因此,细粒度、轻量级模块更难使用。


最受欢迎的文章

最新评论