基本模式

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

基本模式

上一篇:【微信H5】 Redirect_uri参数错误解决方法


下一篇:行政区划分