- Layer Supertype层超类型
- 某一类型充当一层中所有类型的超类型.(DomainObject).
- 运行机制
- 当软件某一层中所有对象有公共特征时,可以将这些特征提取到一个超类上去.
- Separated Interface分离接口
- 在一个包中定义接口,而在另一个与之分离的保重实现该接口.
- 为了减少系统部件间的耦合,将类分组,然后组织成包,并限制包间的依赖关系.同时约定包间调用的约束.
- 但是,可能会出现与包间通用的一般性依赖关系有冲突的调用关系.
- 此时,使用分离接口.一个包中定义接口,而在另一个包中实现它.
- 分离接口为入口提供了一个很好的插入点.
- 运行机制
- 实现类对接口存在依赖,反之没有.
- 所以,实现包到接口包有依赖.其它包仅依赖于接口包,而忽略掉实现包.
- 当然,还是需要将接口和实现连接起来
- 可以在编译时使用另一个独立的包来完成.
- 或者在软件配置时使用插件模式.
- 接口的放置位置
- 当只有一个客户,或者所有客户都在同一包中.则可以将接口放在客户包中.由客户负责定义接口.
- 若有多个客户包,则定义一个第三方的接口包比较好.或者需要有实现包来定义接口规范时.
- 使用时机
- 需要打破两个部分之间的依赖时
- 一层需要调用另一层的代码,但是调用者却不知道被调用者的存在.如领域层调用数据映射层.
- 需要调用别人的函数,但是不想与他们提供的API产生依赖.
- 框架包中包含了一些通常情况的抽象代码,而框架包需要调用一些特定应用代码.
- 该模式的依赖管理过于复杂
- 对于小系统,在创建对象时与实现类建立依赖,而后只使用接口就可以了.
- 保持接口和实现的分离需要额外的工作.一般还需要创建接口和实现的工程类.
- 只有当需要打破依赖关系,或者同一接口有多个独立的实现时,才需要使用分离接口.
- 一般吧实现和接口放在一起,将来需要时在重构即可.
- 需要打破两个部分之间的依赖时
- Registry注册表
- 一个well-known对象,其他对象通过它可以找到公共的对象和服务.
- 在定位某一对象时,需要从管理对象入手.当没有合适的初始对象时,需要某种查找方法.
- 运行机制
- 在注册表接口中使用静态方法.
- 方便其他类查找.
- 数据的保存,应首先考虑数据的作用域
- 不同作用域要求不同的实现,但是有一致的接口.
- 进程.
- 可以使用静态域.
- 但是静态域的问题是不可替换性.
- 也可以考虑Singleton.但是这样的问题在于多线程时的复杂同步代码.
- 线程.使用词典.以线程为键,值为线程的数据对象.
- 会话.使用词典.
- 分割
- 以使用方式而非实现来分割.可以有N个Registry.
- 在注册表接口中使用静态方法.
- 使用时机
- Registry本质上是一个全局数据.
- 一般使用常规的对象间引用来访问对象.有多种替代方案
- 通过参数传递常用数据.问题是会在N层中出现无谓的参数传递开销.
- 在对象创建时把指向公共数据的引用传递给它.当数据只被部分类使用时比较合适.
- 每当增加新类型的数据时,都需要更新Registry.
- 好处是显示的方法接口.
- 使用映射存储全局数据,是隐式的.
- 一个well-known对象,其他对象通过它可以找到公共的对象和服务.
- Value Object值对象
- 一个如货币/日期范围这样的小而简单的对象,判等时并不根据其ID.
- 类似于原始类型.
- 运行机制
- 值对象是小对象,引用对象是大对象.
- 关键区别还是判等方法.引用对象基于标识.值对象基于类内部的属性值.
- 值对象小且易于创建,作为参数传递时传值而不是引用.
- 值对象应作为嵌入值/序列化LOB,而非完整记录来进行持久化.
- 使用时机.
- 判等不基于标识.小且易于创建.
- 一个如货币/日期范围这样的小而简单的对象,判等时并不根据其ID.
- Special Case特殊情况
-
- 针对特殊情况提供特殊行为的子类
- 空值.破坏多态性.必须在可能为空的环境中加入判断.如果多个地方有相似的判空逻辑,造成了冗余代码.
- 数字中的"无限"....
- 处理:返回一个特殊情况.它具有与调用者预期相同的接口.而非返回空值或某个奇怪的值.
- 运行机制
- 创建一个特殊情况子类,重置所有的方法,提供一些无害的行为.
- 通常不需要区分是否是特殊情况(是否是空客户).
- NaN就是特殊情况的实例.
- 使用时机
- 当很多地方都需要对某一特定类的实例进行条件检测,然后做相同的动作时.
-
- Plugin插件
- 在配置时而非编译时进行类链接.
- 代码需要在多个环境中运行,且每个环境下对特定行为需要不同的实现时.通常会使用分离接口模式.
- 之后,工厂方法负责在特定环境下返回需要的实现.
- 当工厂数目变多时,难以维护以后的变更.
- 插件模式通过提供集中化的,运行时配置来解决.
- 运行机制
- 首先,通过分离接口来定义那些在不同环境下有不同实现的行为.
- 然后使用基本工厂模式.
- 特定环境下,接口与那个实现连接的指定需要在一个单独的,代码之外的地方进行声明,以获取可管理性.
- txt即可很好的描述链接规则.
- 插件工厂只是简单滴读取txt,来查找当前环境下所需接口对应哪一个具体实现项,然后返回该相应实现.
- 与实现的链接必须在运行时动态进行,这样在重新配置后无需重新编译.
-
- 配合反射机制.工厂可以动态地构建实现对象.
- 配置文件必须包含从接口名到实现类型的映射.
- 使用时机
- 行为在不同运行环境下要求不同的实现时,应该使用插件模式.
- 在配置时而非编译时进行类链接.
- Service Stub服务桩
- 在测试时移出对有问题的服务的依赖.
- 对于第三方的服务.在开发阶段.使用真实的服务来进行测试是很难实现的(远程的,耗时的...)
- 在测试时,用运行在本地的,快速的,位于内存中的服务桩来代替第三方服务来推进开发进度.
- 运行机制
- 首先,使用入口来定义一个服务的访问点.入口应该是一个分离接口.
- 然后,针对该入口接口,有一个调用实际服务的实现(发布时),和一个服务桩的实现(测试时).
- 所需的入口实现以插件的方式载入.
- 服务桩的关键在于简单.
- 也就是单元测试中的Mock Object.模拟对象.
- 在测试时移出对有问题的服务的依赖.
- Record Set记录集
- 表格数据在内存中的表现形式.
- 看起来像数据库查询的结果.但是可以在其上附加业务逻辑部件.
- 能够断开记录集与其数据源链接的能力.可以序列化记录集,从而将其作为DTO来传输.
- 可以当做工作单元的一种形式.对其中数据的更新,可以使用乐观离线锁来检测是否存在冲突,没有冲突时将数据回写到DB中.
- 表格数据在内存中的表现形式.