mirror of
https://github.com/zhwei820/learn.lianglianglee.com.git
synced 2025-09-17 08:46:40 +08:00
1593 lines
55 KiB
HTML
1593 lines
55 KiB
HTML
<!DOCTYPE html>
|
||
|
||
<!-- saved from url=(0046)https://kaiiiz.github.io/hexo-theme-book-demo/ -->
|
||
|
||
<html xmlns="http://www.w3.org/1999/xhtml">
|
||
|
||
<head>
|
||
|
||
<head>
|
||
|
||
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
||
|
||
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1.0, user-scalable=no">
|
||
|
||
<link rel="icon" href="/static/favicon.png">
|
||
|
||
<title>084 深入理解简单设计.md.html</title>
|
||
|
||
<!-- Spectre.css framework -->
|
||
|
||
<link rel="stylesheet" href="/static/index.css">
|
||
|
||
<!-- theme css & js -->
|
||
|
||
<meta name="generator" content="Hexo 4.2.0">
|
||
|
||
</head>
|
||
<body>
|
||
<div class="book-container">
|
||
|
||
<div class="book-sidebar">
|
||
|
||
<div class="book-brand">
|
||
|
||
<a href="/">
|
||
|
||
<img src="/static/favicon.png">
|
||
|
||
<span>技术文章摘抄</span>
|
||
|
||
</a>
|
||
|
||
</div>
|
||
|
||
<div class="book-menu uncollapsible">
|
||
|
||
<ul class="uncollapsible">
|
||
|
||
<li><a href="/" class="current-tab">首页</a></li>
|
||
|
||
</ul>
|
||
<ul class="uncollapsible">
|
||
|
||
<li><a href="../">上一级</a></li>
|
||
|
||
</ul>
|
||
<ul class="uncollapsible">
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/001 「战略篇」访谈 DDD 和微服务是什么关系？.md.html">001 「战略篇」访谈 DDD 和微服务是什么关系？.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/002 「战略篇」开篇词：领域驱动设计，重焕青春的设计经典.md.html">002 「战略篇」开篇词：领域驱动设计，重焕青春的设计经典.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/003 领域驱动设计概览.md.html">003 领域驱动设计概览.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/004 深入分析软件的复杂度.md.html">004 深入分析软件的复杂度.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/005 控制软件复杂度的原则.md.html">005 控制软件复杂度的原则.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/006 领域驱动设计对软件复杂度的应对（上）.md.html">006 领域驱动设计对软件复杂度的应对（上）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/007 领域驱动设计对软件复杂度的应对（下）.md.html">007 领域驱动设计对软件复杂度的应对（下）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/008 软件开发团队的沟通与协作.md.html">008 软件开发团队的沟通与协作.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/009 运用领域场景分析提炼领域知识（上）.md.html">009 运用领域场景分析提炼领域知识（上）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/010 运用领域场景分析提炼领域知识（下）.md.html">010 运用领域场景分析提炼领域知识（下）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/011 建立统一语言.md.html">011 建立统一语言.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/012 理解限界上下文.md.html">012 理解限界上下文.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/013 限界上下文的控制力（上）.md.html">013 限界上下文的控制力（上）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/014 限界上下文的控制力（下）.md.html">014 限界上下文的控制力（下）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/015 识别限界上下文（上）.md.html">015 识别限界上下文（上）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/016 识别限界上下文（下）.md.html">016 识别限界上下文（下）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/017 理解上下文映射.md.html">017 理解上下文映射.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/018 上下文映射的团队协作模式.md.html">018 上下文映射的团队协作模式.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/019 上下文映射的通信集成模式.md.html">019 上下文映射的通信集成模式.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/020 辨别限界上下文的协作关系（上）.md.html">020 辨别限界上下文的协作关系（上）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/021 辨别限界上下文的协作关系（下）.md.html">021 辨别限界上下文的协作关系（下）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/022 认识分层架构.md.html">022 认识分层架构.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/023 分层架构的演化.md.html">023 分层架构的演化.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/024 领域驱动架构的演进.md.html">024 领域驱动架构的演进.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/025 案例 层次的职责与协作关系（图文篇）.md.html">025 案例 层次的职责与协作关系（图文篇）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/026 限界上下文与架构.md.html">026 限界上下文与架构.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/027 限界上下文对架构的影响.md.html">027 限界上下文对架构的影响.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/028 领域驱动设计的代码模型.md.html">028 领域驱动设计的代码模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/029 代码模型的架构决策.md.html">029 代码模型的架构决策.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/030 实践 先启阶段的需求分析.md.html">030 实践 先启阶段的需求分析.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/031 实践 先启阶段的领域场景分析（上）.md.html">031 实践 先启阶段的领域场景分析（上）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/032 实践 先启阶段的领域场景分析（下）.md.html">032 实践 先启阶段的领域场景分析（下）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/033 实践 识别限界上下文.md.html">033 实践 识别限界上下文.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/034 实践 确定限界上下文的协作关系.md.html">034 实践 确定限界上下文的协作关系.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/035 实践 EAS 的整体架构.md.html">035 实践 EAS 的整体架构.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/036 「战术篇」访谈：DDD 能帮开发团队提高设计水平吗？.md.html">036 「战术篇」访谈：DDD 能帮开发团队提高设计水平吗？.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/037 「战术篇」开篇词：领域驱动设计的不确定性.md.html">037 「战术篇」开篇词：领域驱动设计的不确定性.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/038 什么是模型.md.html">038 什么是模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/039 数据分析模型.md.html">039 数据分析模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/040 数据设计模型.md.html">040 数据设计模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/041 数据模型与对象模型.md.html">041 数据模型与对象模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/042 数据实现模型.md.html">042 数据实现模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/043 案例 培训管理系统.md.html">043 案例 培训管理系统.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/044 服务资源模型.md.html">044 服务资源模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/045 服务行为模型.md.html">045 服务行为模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/046 服务设计模型.md.html">046 服务设计模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/047 领域模型驱动设计.md.html">047 领域模型驱动设计.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/048 领域实现模型.md.html">048 领域实现模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/049 理解领域模型.md.html">049 理解领域模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/050 领域模型与结构范式.md.html">050 领域模型与结构范式.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/051 领域模型与对象范式（上）.md.html">051 领域模型与对象范式（上）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/052 领域模型与对象范式（中）.md.html">052 领域模型与对象范式（中）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/053 领域模型与对象范式（下）.md.html">053 领域模型与对象范式（下）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/054 领域模型与函数范式.md.html">054 领域模型与函数范式.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/055 领域驱动分层架构与对象模型.md.html">055 领域驱动分层架构与对象模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/056 统一语言与领域分析模型.md.html">056 统一语言与领域分析模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/057 精炼领域分析模型.md.html">057 精炼领域分析模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/058 彩色 UML 与彩色建模.md.html">058 彩色 UML 与彩色建模.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/059 四色建模法.md.html">059 四色建模法.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/060 案例 订单核心流程的四色建模.md.html">060 案例 订单核心流程的四色建模.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/061 事件风暴与业务全景探索.md.html">061 事件风暴与业务全景探索.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/062 事件风暴与领域分析建模.md.html">062 事件风暴与领域分析建模.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/063 案例 订单核心流程的事件风暴.md.html">063 案例 订单核心流程的事件风暴.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/064 表达领域设计模型.md.html">064 表达领域设计模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/065 实体.md.html">065 实体.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/066 值对象.md.html">066 值对象.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/067 对象图与聚合.md.html">067 对象图与聚合.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/068 聚合设计原则.md.html">068 聚合设计原则.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/069 聚合之间的关系.md.html">069 聚合之间的关系.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/070 聚合的设计过程.md.html">070 聚合的设计过程.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/071 案例 培训领域模型的聚合设计.md.html">071 案例 培训领域模型的聚合设计.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/072 领域模型对象的生命周期-工厂.md.html">072 领域模型对象的生命周期-工厂.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/073 领域模型对象的生命周期-资源库.md.html">073 领域模型对象的生命周期-资源库.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/074 领域服务.md.html">074 领域服务.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/075 案例 领域设计模型的价值.md.html">075 案例 领域设计模型的价值.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/076 应用服务.md.html">076 应用服务.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/077 场景的设计驱动力.md.html">077 场景的设计驱动力.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/078 案例 薪资管理系统的场景驱动设计.md.html">078 案例 薪资管理系统的场景驱动设计.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/079 场景驱动设计与 DCI 模式.md.html">079 场景驱动设计与 DCI 模式.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/080 领域事件.md.html">080 领域事件.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/081 发布者—订阅者模式.md.html">081 发布者—订阅者模式.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/082 事件溯源模式.md.html">082 事件溯源模式.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/083 测试优先的领域实现建模.md.html">083 测试优先的领域实现建模.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
<a class="current-tab" href="/专栏/领域驱动设计实践（完）/084 深入理解简单设计.md.html">084 深入理解简单设计.md.html</a>
|
||
|
||
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/085 案例 薪资管理系统的测试驱动开发（上）.md.html">085 案例 薪资管理系统的测试驱动开发（上）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/086 案例 薪资管理系统的测试驱动开发（下）.md.html">086 案例 薪资管理系统的测试驱动开发（下）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/087 对象关系映射（上）.md.html">087 对象关系映射（上）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/088 对象关系映射（下）.md.html">088 对象关系映射（下）.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/089 领域模型与数据模型.md.html">089 领域模型与数据模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/090 领域驱动设计对持久化的影响.md.html">090 领域驱动设计对持久化的影响.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/091 领域驱动设计体系.md.html">091 领域驱动设计体系.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/092 子领域与限界上下文.md.html">092 子领域与限界上下文.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/093 限界上下文的边界与协作.md.html">093 限界上下文的边界与协作.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/094 限界上下文之间的分布式通信.md.html">094 限界上下文之间的分布式通信.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/095 命令查询职责分离.md.html">095 命令查询职责分离.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/096 分布式柔性事务.md.html">096 分布式柔性事务.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/097 设计概念的统一语言.md.html">097 设计概念的统一语言.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/098 模型对象.md.html">098 模型对象.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/099 领域驱动设计参考过程模型.md.html">099 领域驱动设计参考过程模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/100 领域驱动设计的精髓.md.html">100 领域驱动设计的精髓.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/101 实践 员工上下文的领域建模.md.html">101 实践 员工上下文的领域建模.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/102 实践 考勤上下文的领域建模.md.html">102 实践 考勤上下文的领域建模.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/103 实践 项目上下文的领域建模.md.html">103 实践 项目上下文的领域建模.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/104 实践 培训上下文的业务需求.md.html">104 实践 培训上下文的业务需求.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/105 实践 培训上下文的领域分析建模.md.html">105 实践 培训上下文的领域分析建模.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/106 实践 培训上下文的领域设计建模.md.html">106 实践 培训上下文的领域设计建模.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/107 实践 培训上下文的领域实现建模.md.html">107 实践 培训上下文的领域实现建模.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/108 实践 EAS 系统的代码模型.md.html">108 实践 EAS 系统的代码模型.md.html</a>
|
||
</li>
|
||
|
||
<li>
|
||
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/109 后记：如何学习领域驱动设计.md.html">109 后记：如何学习领域驱动设计.md.html</a>
|
||
</li>
|
||
|
||
</ul>
|
||
</div>
|
||
|
||
</div>
|
||
<div class="sidebar-toggle" onclick="sidebar_toggle()" onmouseover="add_inner()" onmouseleave="remove_inner()">
|
||
|
||
<div class="sidebar-toggle-inner"></div>
|
||
|
||
</div>
|
||
<script>
|
||
|
||
function add_inner() {
|
||
|
||
let inner = document.querySelector('.sidebar-toggle-inner')
|
||
|
||
inner.classList.add('show')
|
||
|
||
}
|
||
function remove_inner() {
|
||
|
||
let inner = document.querySelector('.sidebar-toggle-inner')
|
||
|
||
inner.classList.remove('show')
|
||
|
||
}
|
||
function sidebar_toggle() {
|
||
|
||
let sidebar_toggle = document.querySelector('.sidebar-toggle')
|
||
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
|
||
let content = document.querySelector('.off-canvas-content')
|
||
|
||
if (sidebar_toggle.classList.contains('extend')) { // show
|
||
|
||
sidebar_toggle.classList.remove('extend')
|
||
|
||
sidebar.classList.remove('hide')
|
||
|
||
content.classList.remove('extend')
|
||
|
||
} else { // hide
|
||
|
||
sidebar_toggle.classList.add('extend')
|
||
|
||
sidebar.classList.add('hide')
|
||
|
||
content.classList.add('extend')
|
||
|
||
}
|
||
|
||
}
|
||
|
||
|
||
function open_sidebar() {
|
||
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
|
||
let overlay = document.querySelector('.off-canvas-overlay')
|
||
|
||
sidebar.classList.add('show')
|
||
|
||
overlay.classList.add('show')
|
||
|
||
}
|
||
|
||
function hide_canvas() {
|
||
|
||
let sidebar = document.querySelector('.book-sidebar')
|
||
|
||
let overlay = document.querySelector('.off-canvas-overlay')
|
||
|
||
sidebar.classList.remove('show')
|
||
|
||
overlay.classList.remove('show')
|
||
|
||
}
|
||
</script>
|
||
<div class="off-canvas-content">
|
||
|
||
<div class="columns">
|
||
|
||
<div class="column col-12 col-lg-12">
|
||
|
||
<div class="book-navbar">
|
||
|
||
<!-- For Responsive Layout -->
|
||
|
||
<header class="navbar">
|
||
|
||
<section class="navbar-section">
|
||
|
||
<a onclick="open_sidebar()">
|
||
|
||
<i class="icon icon-menu"></i>
|
||
|
||
</a>
|
||
|
||
</section>
|
||
|
||
</header>
|
||
|
||
</div>
|
||
|
||
<div class="book-content" style="max-width: 960px; margin: 0 auto;
|
||
|
||
overflow-x: auto;
|
||
|
||
overflow-y: hidden;">
|
||
|
||
<div class="book-post">
|
||
|
||
<p id="tip" align="center"></p>
|
||
|
||
<div><h1>084 深入理解简单设计</h1>
|
||
|
||
<p>测试驱动开发遵守了测试—开发—重构的闭环。测试设定了新功能的需求期望，并为功能实现提供了保护；开发让实现真正落地，满足产品功能的期望；重构则是为了打磨代码质量，降低软件的维护成本。期望—实现—改进的螺旋上升态势，为测试驱动开发闭环提供了源源不断的动力。缺少任何一个环节，闭环都会停滞不动。没有期望，实现就失去了前进的目标；没有实现，期望就成为了空谈；没有改进，前进的道路就会越来越窄，突破就会变得愈发地艰难。</p>
|
||
|
||
<h3>重构改进的目标</h3>
|
||
|
||
<p>若已有清晰的用户需求，为其设定期望然后寻求实现，这并非难事。但是改进的标准却是模糊的。要达到什么样的目标才符合重构的要求？Martin Fowler 的回答是让代码消除坏味道，他甚至编写了专著《重构：改善既有代码的设计》来总结他在多年开发和咨询工作中遇见的所有坏味道，如下表所示：</p>
|
||
|
||
<table>
|
||
|
||
<thead>
|
||
|
||
<tr>
|
||
|
||
<th align="left">坏味道</th>
|
||
|
||
<th align="left">问题</th>
|
||
|
||
</tr>
|
||
|
||
</thead>
|
||
|
||
<tbody>
|
||
|
||
<tr>
|
||
|
||
<td align="left">重复代码</td>
|
||
|
||
<td align="left">函数包含相同代码；两个子类包含相同代码；两个不相干类包含相同代码</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">过长函数</td>
|
||
|
||
<td align="left">函数越长越难以理解</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">过大的类</td>
|
||
|
||
<td align="left">一个类要做的事情太多，可能导致重复代码</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">过长参数列表</td>
|
||
|
||
<td align="left">参数列表过长会导致难以理解，太多参数会造成前后不一致、不易使用，会导致频繁修改</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">发散式变化</td>
|
||
|
||
<td align="left">一个类因为不同原因在不同的方向发生变化，指“一个类受多种变化的影响”</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">霰弹式修改</td>
|
||
|
||
<td align="left">与发散式修改相反，因为一个变化导致多个类都需要作出修改</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">依恋情结</td>
|
||
|
||
<td align="left">函数对某个类的兴趣高过对自己所处类的兴趣</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">数据泥团</td>
|
||
|
||
<td align="left">两个类中相同的字段、许多函数签名中相同的参数。这些总是绑在一起出现的数据应该拥有属于它们自己的对象</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">基本类型偏执</td>
|
||
|
||
<td align="left">基本类型不能很好地表现某个概念</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">Switch 语句</td>
|
||
|
||
<td align="left">Switch 语句的问题在于重复</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">平行继承体系</td>
|
||
|
||
<td align="left">每当你为某个类增加一个子类，必须也为另一个类相应增加一个子类</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">冗余类</td>
|
||
|
||
<td align="left">一个类的所得不值其身价，就是冗余的，应该去掉</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">夸夸其谈未来</td>
|
||
|
||
<td align="left">过度设计，过度抽象</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">临时字段</td>
|
||
|
||
<td align="left">某个实例变量仅为某种特定情况而设</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">消息链条</td>
|
||
|
||
<td align="left">如果你看到用户向一个对象请求另一个对象，然后再向后者请求另一个对象，然后再请求另一个对象，这就是消息链条</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">中间人</td>
|
||
|
||
<td align="left">过度运用委托，例如某个类接口有一半的函数都委托给其他类</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">狎昵关系</td>
|
||
|
||
<td align="left">两个类过于亲密，花费太多时间去探究彼此的 private 成分</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">异曲同工的类</td>
|
||
|
||
<td align="left">如果两个函数做同一件事，却有着不同的签名</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">数据类</td>
|
||
|
||
<td align="left">拥有一些字段以及访问这些字段的函数，除此之外没有其他方法</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">被拒绝的馈赠</td>
|
||
|
||
<td align="left">子类应该继承超类的函数和数据，但如果它们不想或不需要继承，意味着继承体系设计错误</td>
|
||
|
||
</tr>
|
||
|
||
<tr>
|
||
|
||
<td align="left">过多的注释</td>
|
||
|
||
<td align="left">一段代码有着长长的注释，但这些注释之所以存在是因为代码很糟糕</td>
|
||
|
||
</tr>
|
||
|
||
</tbody>
|
||
|
||
</table>
|
||
|
||
<p>数一数，Martin Fowler 一共提出了二十一种代码坏味道。要记住所有的坏味道并非易事，更何况我们还得保持嗅觉的敏感性，一经察觉代码的坏味道，就得尽量着手重构。经科学家研究证明，人类的短时记忆容量大约为 7±2，如果一时无法记住所有的坏味道，则可遵循 Kent Beck 的简单设计原则。我在 1-11《领域实现模型》中已经简单地介绍了简单设计原则，内容为：</p>
|
||
|
||
<ul>
|
||
|
||
<li>通过所有测试（Passes its tests）</li>
|
||
|
||
<li>尽可能消除重复（Minimizes duplication）</li>
|
||
|
||
<li>尽可能清晰表达（Maximizes clarity）</li>
|
||
|
||
<li>更少代码元素（Has fewer elements）</li>
|
||
|
||
<li>以上四个原则的重要程度依次降低。</li>
|
||
|
||
</ul>
|
||
|
||
<p>最后一个原则说明前面四个原则是依次递进的：功能正确，减少重复，代码可读是简单设计的根本要求。一旦满足这些要求，就不能创建更多的代码元素去迎合未来可能并不存在的变化，避免过度设计。</p>
|
||
|
||
<h3>简单设计的量化标准</h3>
|
||
|
||
<p>在满足需求的基本前提下，简单设计其实为代码的重构给出了三个量化标准：重复性、可读性与简单性。重复性是一个客观的标准，可读性则出于主观的判断，故而应优先考虑尽可能消除代码的重复，然后在此基础上保证代码清晰地表达设计者的意图，提高可读性。只要达到了重用和可读，就应该到此为止，不要画蛇添足地增加额外的代码元素，如变量、函数、类甚至模块，保证实现方案的简单。</p>
|
||
|
||
<p>第四个原则是“奥卡姆剃刀”的体现，更加文雅的翻译表达即“如无必要，勿增实体”。人民大学的哲学教授周濂在解释奥卡姆剃刀时，如是说道：</p>
|
||
|
||
<blockquote>
|
||
|
||
<p>作为一个极端的唯名论者，奥卡姆的威廉（William of Occam，1280—1349）主张个别的事物是真实的存在，除此之外没有必要再设立普遍的共相，美的东西就是美的，不需要再废话多说什么美的东西之所以为美是由于美，最后这个美，完全可以用奥卡姆的剃刀一割了之。</p>
|
||
|
||
</blockquote>
|
||
|
||
<p>这个所谓“普遍的共相”就是一种抽象。在软件开发中，那些不必要的抽象反而会产生多余的概念，实际会干扰代码阅读者的判断，增加代码的复杂度。因此，简单设计强调恰如其分的设计，若实现的功能通过了所有测试，就意味着满足了客户的需求，这时，只需要尽可能消除重复，清晰表达了设计者意图，就不可再增加额外的软件元素。若存在多余实体，当用奥卡姆的剃刀一割了之。</p>
|
||
|
||
<h3>一个实例</h3>
|
||
|
||
<p>让我们通过重构一段 FitNesse 代码来阐释简单设计原则。这段代码案例来自 Robert Martin 的著作《代码整洁之道》。Robert Martin 在书中给出了对源代码的三个重构版本，这三个版本的演化恰好可以帮助我们理解简单设计原则。</p>
|
||
|
||
<p>重构前的代码初始版本是定义在 HtmlUtil 类中的一个长函数：</p>
|
||
|
||
<pre><code class="language-java"> public static String testableHtml(PageData pageData, boolean includeSuiteSetup) throws Exception {
|
||
|
||
WikiPage wikiPage = pageData.getWikiPage();
|
||
|
||
StringBuffer buffer = new StringBuffer();
|
||
|
||
if (pageData.hasAttribute("Test")) {
|
||
|
||
if (includeSuiteSetup) {
|
||
|
||
WikiPage suiteSetupPage = PageCrawlerImpl.getInheritedPage(SuiteResponder.SUITE_SETUP_NAME, wikiPage);
|
||
|
||
if (suiteSetupPage != null) {
|
||
|
||
WikiPagePath pagePath = wikiPage.getPageCrawler().getFullPath(suiteSetupPage);
|
||
|
||
String pagePathName = PathParser.render(pagePath);
|
||
|
||
buffer.append("\n!include -setup .")
|
||
|
||
.append(pagePathName)
|
||
|
||
.append("\n");
|
||
|
||
}
|
||
|
||
}
|
||
|
||
WikiPage setupPage = PageCrawlerImpl.getInheritedPage("SetUp", wikiPage);
|
||
|
||
if (setupPage != null) {
|
||
|
||
WikiPagePath setupPath = wikiPage.getPageCrawler().getFullPath(setupPage);
|
||
|
||
String setupPathName = PathParser.render(setupPath);
|
||
|
||
buffer.append("\n!include -setup .")
|
||
|
||
.append(setupPathName)
|
||
|
||
.append("\n");
|
||
|
||
}
|
||
|
||
}
|
||
|
||
buffer.append(pageData.getContent());
|
||
|
||
if (pageData.hasAttribute("Test")) {
|
||
|
||
WikiPage teardownPage = PageCrawlerImpl.getInheritedPage("TearDown", wikiPage);
|
||
|
||
if (teardownPage != null) {
|
||
|
||
WikiPagePath tearDownPath = wikiPage.getPageCrawler().getFullPath(teardownPage);
|
||
|
||
String tearDownPathName = PathParser.render(tearDownPath);
|
||
|
||
buffer.append("\n")
|
||
|
||
.append("!include -teardown .")
|
||
|
||
.append(tearDownPathName)
|
||
|
||
.append("\n");
|
||
|
||
}
|
||
|
||
if (includeSuiteSetup) {
|
||
|
||
WikiPage suiteTeardownPage = PageCrawlerImpl.getInheritedPage(SuiteResponder.SUITE_TEARDOWN_NAME, wikiPage);
|
||
|
||
if (suiteTeardownPage != null) {
|
||
|
||
WikiPagePath pagePath = wikiPage.getPageCrawler().getFullPath(suiteTeardownPage);
|
||
|
||
String pagePathName = PathParser.render(pagePath);
|
||
|
||
buffer.append("\n!include -teardown .")
|
||
|
||
.append(pagePathName)
|
||
|
||
.append("\n");
|
||
|
||
}
|
||
|
||
}
|
||
|
||
}
|
||
|
||
pageData.setContent(buffer.toString());
|
||
|
||
return pageData.getHtml();
|
||
|
||
}
|
||
</code></pre>
|
||
|
||
<p>假定这一个函数已经通过了测试，按照简单设计的评判步骤，我们需要检查代码是否存在重复。显然，在上述代码的 6~13 行、15~22 行、26~34 行以及 36~43 行四个地方都发现了重复或相似的代码。这些代码的执行步骤像一套模板：</p>
|
||
|
||
<ul>
|
||
|
||
<li>获取 Page</li>
|
||
|
||
<li>若 Page 不为 null，则获取路径</li>
|
||
|
||
<li>解析路径名称</li>
|
||
|
||
<li>添加到输出结果中</li>
|
||
|
||
</ul>
|
||
|
||
<p>这套模板的差异部分可以通过参数差异化完成，故而可以提取方法：</p>
|
||
|
||
<pre><code class="language-java"> private static void includePage(WikiPage wikiPage, StringBuffer buffer, String pageName, String sectionName) {
|
||
|
||
WikiPage suiteSetupPage = PageCrawlerImpl.getInheritedPage(pageName, wikiPage);
|
||
|
||
if (suiteSetupPage != null) {
|
||
|
||
WikiPagePath pagePath = wikiPage.getPageCrawler().getFullPath(suiteSetupPage);
|
||
|
||
String pagePathName = PathParser.render(pagePath);
|
||
|
||
buildIncludeDirective(buffer, sectionName, pagePathName);
|
||
|
||
}
|
||
|
||
}
|
||
private static void buildIncludeDirective(StringBuffer buffer, String sectionName, String pagePathName) {
|
||
|
||
buffer.append("\n!include ")
|
||
|
||
.append(sectionName)
|
||
|
||
.append(" .")
|
||
|
||
.append(pagePathName)
|
||
|
||
.append("\n");
|
||
|
||
}
|
||
</code></pre>
|
||
|
||
<p>在提取了 includePage() 方法后，就可以消除四段几乎完全相似的重复代码。重构后的长函数为：</p>
|
||
|
||
<pre><code class="language-java"> public static String testableHtml(PageData pageData, boolean includeSuiteSetup) throws Exception {
|
||
|
||
WikiPage wikiPage = pageData.getWikiPage();
|
||
|
||
StringBuffer buffer = new StringBuffer();
|
||
if (pageData.hasAttribute("Test")) {
|
||
|
||
if (includeSuiteSetup) {
|
||
|
||
includePage(wikiPage, buffer, SuiteResponder.SUITE_SETUP_NAME, "-setup");
|
||
|
||
}
|
||
|
||
includePage(wikiPage, buffer, "SetUp", "-setup");
|
||
|
||
}
|
||
|
||
buffer.append(pageData.getContent());
|
||
|
||
if (pageData.hasAttribute("Test")) {
|
||
|
||
includePage(wikiPage, buffer, "TearDown", "-teardown");
|
||
|
||
if (includeSuiteSetup) {
|
||
|
||
includePage(wikiPage, buffer, SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown");
|
||
|
||
}
|
||
|
||
}
|
||
|
||
pageData.setContent(buffer.toString());
|
||
|
||
return pageData.getHtml();
|
||
|
||
}
|
||
</code></pre>
|
||
|
||
<p>从重复性角度看，以上代码已经去掉了重复。当然，也可以将 pageData.hasAttribute("Test") 视为重复，因为该表达式在第 5 行和第 12 行都出现过，表达式用到的常量 "Test" 也是重复。不过，你若认为这是从代码可读性角度对其重构，也未尝不可：</p>
|
||
|
||
<pre><code class="language-java"> private static boolean isTestPage(PageData pageData) {
|
||
|
||
return pageData.hasAttribute("Test");
|
||
|
||
}
|
||
</code></pre>
|
||
|
||
<p>重构后的 testableHtml() 方法的可读性仍有不足之处，例如方法的名称，buffer 变量名都没有清晰表达设计意图，对 Test 和 Suite 的判断增加了条件分支，给代码阅读制造了障碍。由于 includePage() 方法是一个通用方法，未能清晰表达其意图，且传递的参数同样干扰了阅读，应该将各个调用分别封装为表达业务含义的方法，例如定义为 includeSetupPage()。当页面并非测试页面时， pageData 的内容无需重新设置，可以直接通过 getHtml() 方法返回。因此，添加页面内容的第 11 行代码还可以放到 isTestPage() 分支中，让逻辑变得更加紧凑：</p>
|
||
|
||
<pre><code class="language-java"> public static String renderPage(PageData pageData, boolean includeSuiteSetup) throws Exception {
|
||
|
||
if (isTestPage(pageData)) {
|
||
|
||
WikiPage testPage = pageData.getWikiPage();
|
||
|
||
StringBuffer newPageContent = new StringBuffer();
|
||
includeSuiteSetupPage(testPage, newPageContent, includeSuiteSetup);
|
||
|
||
includeSetupPage(testPage, newPageContent);
|
||
|
||
includePageContent(testPage, newPageContent);
|
||
|
||
includeTeardownPage(testPage, newPageContent);
|
||
|
||
includeSuiteTeardownPage(testPage, newPageContent, includeSuiteSetup);
|
||
pageData.setContent(buffer.toString());
|
||
|
||
}
|
||
|
||
return pageData.getHtml();
|
||
|
||
}
|
||
</code></pre>
|
||
|
||
<p>无论是避免重复，还是清晰表达意图，这个版本的代码都要远胜于最初的版本。Robert Martin 在《代码整洁之道》中也给出了他重构的第一个版本：</p>
|
||
|
||
<pre><code class="language-java"> public static String renderPageWithSetupsAndTeardowns(PageData pageData, boolean isSuite) throws Exception {
|
||
|
||
boolean isTestPage = pageData.hasAttribute("Test");
|
||
|
||
if (isTestPage) {
|
||
|
||
WikiPage testPage = pageData.getWikiPage();
|
||
|
||
StringBuffer newPageContent = new StringBuffer();
|
||
|
||
includeSetupPages(testPage, newPageContent, isSuite);
|
||
|
||
newPageContent.append(pageData.getContent());
|
||
|
||
includeTeardownPages(testPage, newPageContent, isSuite);
|
||
|
||
pageData.setContent(newPageContent.toString());
|
||
|
||
}
|
||
|
||
return pageData.getHtml();
|
||
|
||
}
|
||
</code></pre>
|
||
|
||
<p>对比我的版本和 Robert Martin 的版本，我认为 Robert Martin 的当前版本仍有以下不足之处：</p>
|
||
|
||
<ul>
|
||
|
||
<li>方法名称过长，暴露了实现细节</li>
|
||
|
||
<li>isTestPage 变量不如 isTestPage() 方法的封装性好</li>
|
||
|
||
<li>方法体缺少分段，不同的意图混淆在了一起</li>
|
||
|
||
</ul>
|
||
|
||
<p>最关键的不足之处在于第 7 行代码。对比第 7 行和第 6、8 两行代码，虽然都是一行代码，但其表达的意图却有风马牛不相及的违和感。这是因为第 7 行代码实际暴露了将页面内容追加到 newPageContent 的实现细节，第 6 行和第 8 行代码却隐藏了这一实现细节。这三行代码没有处于同一个抽象层次，违背了“单一抽象层次原则（SLAP）”。</p>
|
||
|
||
<p>Robert Martin 在这个版本基础上，继续精进，给出了重构后的第二个版本：</p>
|
||
|
||
<pre><code class="language-java"> public static String renderPageWithSetupsAndTeardowns(PageData pageData, boolean isSuite) throws Exception {
|
||
|
||
if (isTestPage(pageData))
|
||
|
||
includeSetupAndTeardownPages(pageData, isSuite);
|
||
|
||
return pageData.getHtml();
|
||
|
||
}
|
||
</code></pre>
|
||
|
||
<p>该版本的方法仍然定义在 HtmlUtil 工具类中。对比 Robert Martin 的两个重构版本，后一版本的主方法变得更加简单了，方法体只有短短的三行代码。虽然方法变得更简短，但提取出来的 includeSetupAndTeardownPages() 方法却增加了不必要的抽象层次。<strong>封装需要有度，引入太多的层次反而会干扰阅读。<strong>尤其是方法，Java 或大多数语言都不提供“方法嵌套方法”的层次结构（Scala 支持这一语法特性）。如果为一个方法的不同业务层次提取了太多方法，在逻辑上，它存在递进的嵌套关系，在物理上，却是一个扁平的结构。阅读这样的代码会造成不停的跳转，不够直接。正如 Grady Booch 所述：“整洁的代码从不隐藏设计者的意图，充满了</strong>干净利落</strong>的抽象和<strong>直截了当</strong>的控制语句。”干净利落，直截了当，可以破除对过度细粒度方法的迷信！与其封装一个用超长名称才能表达其意图的 includeSetupAndTeardownPages() 方法，不如直接“敞开”相同层次的代码细节，如：</p>
|
||
|
||
<pre><code class="language-java">includeSuiteSetupPage(testPage, newPageContent, includeSuiteSetup);
|
||
|
||
includeSetupPage(testPage, newPageContent);
|
||
|
||
includePageContent(testPage, newPageContent);
|
||
|
||
includeTeardownPage(testPage, newPageContent);
|
||
|
||
includeSuiteTeardownPage(testPage, newPageContent, includeSuiteSetup);
|
||
</code></pre>
|
||
|
||
<p>这五行代码不正是直截了当地表达了包含的页面结构吗？因此，我觉得 Robert Martin 提取出来的 includeSetupAndTeardownPages() 方法违背了简单设计的第四条原则，即增加了不必要的软件元素。事实上，如果一个方法的名称包含了 and，就说明该方法可能违背了“一个方法只做一件事情”的基本原则。</p>
|
||
|
||
<p>我并不反对定义细粒度方法，相反我很欣赏合理的细粒度方法，如前提取的 includePageContent() 方法。一个庞大的方法往往缺少内聚性，不利于重用，但什么才是方法的合适粒度呢？不同的公司有着不同的方法行限制，有的是 200 行，有的是 50 行，有的甚至约束到 5 行。最关键的不是限制代码行，而在于一个方法只能做一件事。</p>
|
||
|
||
<p>若发现一个主方法过长，可通过提取方法使它变短。当提取方法的逻辑层次嵌套太多，彼此的职责又高内聚时，就需要考虑将这个主方法和提取出来的方法一起委派到一个专门的类。显然，testableHtml() 方法的逻辑其实是一个相对独立的职责，根本就不应该将其实现逻辑放在 HtmlUtil 工具类，而应按照其意图独立为一个类 TestPageIncluder。提取为类还有一个好处就是可以减少方法之间传递的参数，因为这些方法参数可以作为单独类的字段。重构后的代码为：</p>
|
||
|
||
<pre><code class="language-java">public class TestPageIncluder {
|
||
|
||
private PageData pageData;
|
||
|
||
private WikiPage testPage;
|
||
|
||
private StringBuffer newPageContent;
|
||
|
||
private PageCrawler pageCrawler;
|
||
private TestPageIncluder(PageData pageData) {
|
||
|
||
this.pageData = pageData;
|
||
|
||
testPage = pageData.getWikiPage();
|
||
|
||
pageCrawler = testPage.getPageCrawler();
|
||
|
||
newPageContent = new StringBuffer();
|
||
|
||
}
|
||
public static String render(PageData pageData) throws Exception {
|
||
|
||
return render(pageData, false);
|
||
|
||
}
|
||
public static String render(PageData pageData, boolean isSuite) throws Exception {
|
||
|
||
return new TestPageIncluder(pageData).renderPage(isSuite);
|
||
|
||
}
|
||
private String renderPage(boolean isSuite) throws Exception {
|
||
|
||
if (isTestPage()) {
|
||
|
||
includeSetupPages(isSuite);
|
||
|
||
includePageContent();
|
||
|
||
includeTeardownPages(isSuite);
|
||
|
||
updatePageContent();
|
||
|
||
}
|
||
|
||
return pageData.getHtml();
|
||
|
||
}
|
||
private void includeSetupPages(boolean isSuite) throws Exception {
|
||
|
||
if (isSuite) {
|
||
|
||
includeSuitesSetupPage();
|
||
|
||
}
|
||
|
||
includeSetupPage();
|
||
|
||
}
|
||
|
||
private void includeSuitesSetupPage() throws Exception {
|
||
|
||
includePage(SuiteResponder.SUITE_SETUP_NAME, "-setup");
|
||
|
||
}
|
||
|
||
private void includeSetupPage() throws Exception {
|
||
|
||
includePage("SetUp", "-setup");
|
||
|
||
}
|
||
|
||
private void includeTeardownPages(boolean isSuite) throws Exception {
|
||
|
||
if (isSuite) {
|
||
|
||
includeSuitesTeardownPage();
|
||
|
||
}
|
||
|
||
includeTeardownPage();
|
||
|
||
}
|
||
|
||
private void includeSuitesTeardownPage() throws Exception {
|
||
|
||
includePage(SuiteResponder.SUITE_TEARDOWN_NAME, "-teardown");
|
||
|
||
}
|
||
|
||
private void includeTeardownPage() throws Exception {
|
||
|
||
includePage("TearDown", "-teardown");
|
||
|
||
}
|
||
private void updateContent() throws Exception {
|
||
|
||
pageData.setContent(newPageContent.toString());
|
||
|
||
}
|
||
private void includePage(String pageName, String sectionName) throws Exception {
|
||
|
||
WikiPage inheritedPage = PageCrawlerImpl.getInheritedPage(pageName, wikiPage);
|
||
|
||
if (inheritedPage != null) {
|
||
|
||
WikiPagePath pagePath = wikiPage.getPageCrawler().getFullPath(inheritedPage);
|
||
|
||
String pathName = PathParser.render(pagePath);
|
||
|
||
buildIncludeDirective(pathName, sectionName);
|
||
|
||
}
|
||
|
||
}
|
||
|
||
private void buildIncludeDirective(String pathName, String sectionName) {
|
||
|
||
buffer.append("\n!include ")
|
||
|
||
.append(sectionName)
|
||
|
||
.append(" .")
|
||
|
||
.append(pathName)
|
||
|
||
.append("\n");
|
||
|
||
}
|
||
|
||
}
|
||
</code></pre>
|
||
|
||
<p>引入 TestPageIncluder 类后，职责的层次更加清晰了，分离出来的这个类承担了组装测试页面信息的职责，HtmlUtil 类只需要调用它的静态方法 render() 即可，避免了因承担太多职责而形成一个上帝类。通过提取出类和对应的方法，形成不同的抽象层次，让代码的阅读者有选择地阅读自己关心的部分，这就是清晰表达设计者意图的价值。</p>
|
||
|
||
<p>对比 Robert Martin 给出的重构第二个版本以及这个提取类的最终版本，我赞成将该主方法的逻辑提取给专门的类，但不赞成在主方法中定义过度抽象层次的 includeSetupAndTeardownPages() 方法。二者同样都增加了软件元素，我对此持有的观点却截然不同。我也曾就 Robert Martin 给出的两个版本做过调查，发现仍然有一部分人偏爱第二个更加简洁的版本。这一现象恰好说明简单设计的第三条原则属于主观判断，不如第二条原则那般具有客观的评判标准，恰如大家对美各有自己的欣赏。但我认为，一定不会有人觉得重构前的版本才是最好。即使不存在重复代码，单从可读性角度判断，也会觉得最初版本的代码不堪入目，恰如大家对美的评判标准，仍具有一定的普适性。</p>
|
||
|
||
<p>Robert Martin 在《代码整洁之道》中也给出了分离职责的类 SetupTeardownIncluder。两个类的实现相差不大，只是 TestPageIncluder 类要少一些方法。除了没有 includeSetupAndTeardownPages() 方法外，我也未曾定义 findInheritedPage() 和 getPathNameForPage() 之类的方法，也没有提取 isSuite 字段，因为我认为这些都是不必要的软件元素，它违背了简单设计的第四条原则，应当用奥卡姆的剃刀一割了之。</p>
|
||
|
||
</div>
|
||
|
||
</div>
|
||
|
||
<div>
|
||
|
||
<div style="float: left">
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/083 测试优先的领域实现建模.md.html">上一页</a>
|
||
|
||
</div>
|
||
|
||
<div style="float: right">
|
||
|
||
<a href="/专栏/领域驱动设计实践（完）/085 案例 薪资管理系统的测试驱动开发（上）.md.html">下一页</a>
|
||
|
||
</div>
|
||
|
||
</div>
|
||
</div>
|
||
|
||
</div>
|
||
|
||
</div>
|
||
|
||
</div>
|
||
<a class="off-canvas-overlay" onclick="hide_canvas()"></a>
|
||
|
||
</div>
|
||
|
||
<script defer src="https://static.cloudflareinsights.com/beacon.min.js/v652eace1692a40cfa3763df669d7439c1639079717194" integrity="sha512-Gi7xpJR8tSkrpF7aordPZQlW2DLtzUlZcumS8dMQjwDHEnw9I7ZLyiOj/6tZStRBGtGgN6ceN6cMH8z7etPGlw==" data-cf-beacon='{"rayId":"70997ec05ebf3cfa","version":"2021.12.0","r":1,"token":"1f5d475227ce4f0089a7cff1ab17c0f5","si":100}' crossorigin="anonymous"></script>
|
||
|
||
</body>
|
||
|
||
<!-- Global site tag (gtag.js) - Google Analytics -->
|
||
|
||
<script async src="https://www.googletagmanager.com/gtag/js?id=G-NPSEEVD756"></script>
|
||
|
||
<script>
|
||
|
||
window.dataLayer = window.dataLayer || [];
|
||
function gtag() {
|
||
|
||
dataLayer.push(arguments);
|
||
|
||
}
|
||
gtag('js', new Date());
|
||
|
||
gtag('config', 'G-NPSEEVD756');
|
||
|
||
var path = window.location.pathname
|
||
|
||
var cookie = getCookie("lastPath");
|
||
|
||
console.log(path)
|
||
|
||
if (path.replace("/", "") === "") {
|
||
|
||
if (cookie.replace("/", "") !== "") {
|
||
|
||
console.log(cookie)
|
||
|
||
document.getElementById("tip").innerHTML = "<a href='" + cookie + "'>跳转到上次进度</a>"
|
||
|
||
}
|
||
|
||
} else {
|
||
|
||
setCookie("lastPath", path)
|
||
|
||
}
|
||
function setCookie(cname, cvalue) {
|
||
|
||
var d = new Date();
|
||
|
||
d.setTime(d.getTime() + (180 * 24 * 60 * 60 * 1000));
|
||
|
||
var expires = "expires=" + d.toGMTString();
|
||
|
||
document.cookie = cname + "=" + cvalue + "; " + expires + ";path = /";
|
||
|
||
}
|
||
function getCookie(cname) {
|
||
|
||
var name = cname + "=";
|
||
|
||
var ca = document.cookie.split(';');
|
||
|
||
for (var i = 0; i < ca.length; i++) {
|
||
|
||
var c = ca[i].trim();
|
||
|
||
if (c.indexOf(name) === 0) return c.substring(name.length, c.length);
|
||
|
||
}
|
||
|
||
return "";
|
||
|
||
}
|
||
</script>
|
||
</html>
|
||
|