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、多用表形式、常量形式、小函数、设计模式等编写代码,可以更好的分离关注点
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 206,839评论 6 482
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 88,543评论 2 382
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 153,116评论 0 344
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 55,371评论 1 279
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 64,384评论 5 374
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 49,111评论 1 285
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,416评论 3 400
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 37,053评论 0 259
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 43,558评论 1 300
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 36,007评论 2 325
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 38,117评论 1 334
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,756评论 4 324
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,324评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 30,315评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,539评论 1 262
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,578评论 2 355
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,877评论 2 345

推荐阅读更多精彩内容