DDD如何写出代码白话文

https://www.info.ucl.ac.be/~pvr/PrincipleOfLeastExpressiveness.pdf

前言

上面的链接就是本篇博客的主题，最小表达力原则。之前有看过很多代码设计相关的书籍，比如《重构》、《代码整洁之道》并且也切实遵循了这些规范，最近也亲身实践了DDD领域驱动设计，总是恍惚之间觉得这些个设计之间有一些共通性，但是也说不清楚到底是什么。阅读了上边这篇论文之后也没有通透的理解，不过感觉像是快要捅破了这层窗户纸了。

概念

The least expressive model means that if you can express your idea
with a constant, use that,and similarly for lookup tables, state machines, and so on. You should only use a Turing-complete language when you cannot
use something simpler—with the caveat not to contortthe code.

简单理解就是能用常量、表格、状态机等直观形式表现出来的逻辑，就不要用编程语言中各种特性来表现。

例子1
  • 使用图灵完备的编程语言实现的解码器，每当阅读这部分代码的时候我们脑子里想的首先是按照编程语言解析这些if else，然后再理解不同文件与解码器的对应关系。如果再多一些解码器，你可能得拿出纸笔或者建一个Excel来理解不同文件类型与解码器之间的对应关系。
  • 后续对代码的修改可以轻松的在花括号之间加上任意“相关” 的逻辑，比如如果是GIF格式的文件，那么先检查下file大小再决定是否解码。加上这部分代码是非常容易的，而且也不需要过多思考的，如果你有个好的编程习惯，那么你会考虑检查file大小的代码放到这个分支下是否合适，但是你保不齐别人也有和你一样的习惯。
  • 抛异常这部分逻辑本就和文件-解码器对应关系 的逻辑没有关系，但是由if else这部分呢控制逻辑给混在了一起，没有分离关注点。
if (file.format() == JPG
|| file.format() == PNG) {
return new DecoderA().decode(file);
} else if (file.format() == GIF) {
return new DecoderB().decode(file);
} else {
throw new IllegalStateException();
}
例子2
  • 使用了更加直观的表格的形式直接表达了文件格式与解码器之间的对应关系。当阅读代码的时候我们首先考虑的是文件格式与解码器的各种关系，然后会批判的考虑一个解码器是对应多个格式还是一个格式，反过来呢？这样更加能在写代码过程中提前暴露一些逻辑上的问题。
  • 除了直观，异常处理也和对应关系的逻辑区分开来
  • 代码的圈复杂度也直接降下来了。相同行数的代码，控制逻辑越多，代码执行时可能性就越多，代码表达力也越强，信息量就越大，代码执行出错的可能性也就越大，理解起来也就越需要动脑子花时间。
Map<Format, Decoder> decoders=new HashMap<>();
map.add(JPG, new DecoderA());
map.add(PNG, new DecoderA());
map.add(GIF, new DecoderB());
return getOptional(decoders, file.format())
.map(Decoder::decode)
.orElseThrow(IllegalStateException::new);
例子3
  • 在例子2的基础上，构成了一块铁板，代码除了可读性，别人根本不能轻易的在多个hashmap实例中间做一些什么事情。相当于让代码变得不可修改，越是不变的事物越是稳定。按作者的话说是nail down，不给代码更多的可变性，出错的概率也就更小。
final Map<Format, Decoder> DECODERS =
ImmutableMap.builder()
.add(JPG, new DecoderA())
.add(PNG, new DecoderA())
.add(GIF, new DecoderB())
.build();
...

理解

  • 道
    1、让代码能够直观的反应业务的同时，不需要大脑过多的思考解析，也就是说代码最好只表现了业务，除此之外不应该有过多的表现力。这和DDD的设计思想也是一致的。
    2、尽量做到让控制逻辑和业务逻辑分离，控制逻辑会增加代码出错的可能性，并且控制代码与业务本身关系不大。
  • 术
    1、构建整体性更好、不可变的代码，比如采用函数式编程
    2、多用表形式、常量形式、小函数、设计模式等编写代码，可以更好的分离关注点