本期精读文章是《the dci architecture》，让我们一起来探索和复习这种设计思想。
引言
随着前端技术如ES6和ES7的发展，我们大前端借鉴了各种其他编程语言中的概念、特性和模式。我们可以使用函数式编程、面向对象编程、面向接口的思想、AOP、注解、代理、反射以及各种设计模式。在大前端和数据时代的发展背景下，我们重新阅读了这篇关于设计的老文《The DCI Architecture》，以探索和复习相关的设计和思想。
内容摘要
DCI是数据（Data）、场景（Context）和交互（Interactions）的简称，重点关注数据在不同场景中的交互行为，是面向对象系统状态和行为的一种范式设计。DCI在许多方面统一了过去的多种范式，这些模式多年来已成为面向对象编程的辅助工具。
尽管面向切面编程（AOP）也有其他用途，但DCI满足了许多AOP的应用以及Aspects在解决问题方面的许多目标。根据AOP的基本原理，DCI基于深层次的反射或元编程。与Aspects不同，角色聚合并组合得很好。Context提供角色集之间的关联范围关闭，而Aspect仅与应用它们的对象配对。虽然混合本身缺乏我们在Context语义中发现的动力，但DCI反映了混合风格策略。DCI实现了多范式设计的许多简单目标，能够将过程逻辑与对象逻辑分开。然而，DCI具有比多范式设计提供的更强大的技术更好的耦合和内聚效果。
结合ATM汇款场景案例，讲解了DCI角色提供了与用户相关的自然边界。以转账为例，我们实际谈论的是钱的转移，以及源账户和目标账户的角色，算法（用例角色行为集合）应该是这样：
账户拥有人选择从一个账户到另一个账户的钞票转移。系统显示有效账户。用户选择源账户。系统显示存在的有效账户。账户拥有人选择目标账户。系统需要数额。账户拥有人输入数额。钞票转移账户进行中（确认金额、修改账户等操作）。
设计者的工作就是把这个用例转化为类似交易的算法，如下：
源账户开始交易事务。源账户确认余额可用。源账户减少其账目。源账户请求目标账户增加其账目。源账户请求目标账户更新其日志。源账户结束交易事务。源账户显示给账户拥有人转账成功。
代码语言：javascript代码运行次数：0
template class TransferMoneySourceAccount: public MoneySource {private: ConcreteDerived *const self() { return static_cast(this); } void transferTo(Currency amount) { // This code is reviewable and // meaningfully testable with stubs! beginTransaction(); if (self()->availableBalance() >= amount) { self()->decreaseBalance(amount); recipient()->increaseBalance(amount); self()->updateLog("Transfer Out", DateTime(), amount); recipient()->updateLog("Transfer In", DateTime(), amount); } gui->displayScreen(SUCCESS_DEPOSIT_SCREEN); endTransaction(); }};
精读
本次提出独到观点的同学有：@ascoders、@TingGe、@zy，精读由此归纳。
尝试从人类思维角度出发理解DCI，即数据（data）、场景（context）和交互（interactive）。
DCI之所以被提出，是因为传统MVC代码在越来越丰富的交互需求中变得越来越难读。有人会觉得，复杂的需求MVC也可以cover住，诚然如此，但很少有人能只读一遍源码就能理解程序处理了哪些事情，这是因为人类思维与MVC的传统程序设计思想存在鸿沟，我们需要脑补内容很多，才会觉得难度。
现在仍有大量程序使用面向对象的思想表达交互行为，当我们把所有对象之间的关联记录在脑海中时，可能对象之间交互行为会比较清楚，但仍然无法轻松理解，因为对象的封装会导致内聚性不断增加，交互逻辑会在不同对象之间跳转，对象之间的嵌套关系在复杂系统中无疑是一个理解负担。
DCI尝试从人类思维角度出发，举一个例子：为什么在看电影时会轻轻松松地理解故事主线呢？回想一下我们看电影的过程，看到一个画面时，我们会思考三件事：
居然设计家
居然之家和阿里巴巴共同打造的家居家装AI设计平台
64 查看详情 画面里有什么人或物？人或物发生了什么行为、交互？现在在哪？厨房？太空舱？或者原始森林？
很快把这三件事弄清楚，我们就能快速理解当前场景的逻辑，并且轻松理解该场景继续发生的状况。即便是盗梦空间这种烧脑的电影，当我们搞清楚这三个问题后，就算街道发生了180度扭曲，也不会存在理解障碍，反而可以吃着爆米花享受，直到切换到下一个场景为止。
当我们把街道扭曲180度的能力放在街道对象上时，理解就变得复杂了：这个函数什么时候被调用？为什么不好好承载车辆而自己发生扭曲？这就像电影开始时，把电影里播放的所有关于街道的状态都走马灯过一遍：我们看到街道通过了车辆、又卷曲、又发生了爆炸，实在觉得莫名其妙。
理解代码也是如此，当交互行为复杂时，把交互和场景分别抽象出来，以场景为切入点交互数据。
举个例子，传统的MVC可能会这么组织代码：
UserModel:
代码语言：javascript代码运行次数：0
class My { private name = "ascoders"; // 名字 private skills = ["javascript", "nodejs", "切图"]; // 技能 private hp = 100; // 生命值？？ private account = new Account(); // 账户相关}
UserController:
代码语言：javascript代码运行次数：0
class Controller { private my = new My(); private account = new Account(); private accountController = new AccountController(); public cook() { // 做饭 } public coding() { // 写代码 } public fireball() { // 搓火球术。。？ } public underAttack() { // 受到攻击？？ } public pay() { // 支付，用到了 account 与 accountController }}
这只是我自己的行为，当我这个对象，与文章对象、付款行为发生联动时，就发生了各种各样的跳转。到目前为止我还不是非常排斥这种做法，毕竟这样是非常主流的，前端数据管理中，不论是redux，还是mobx，都类似MVC。
不论如何，尝试一下DCI的思路吧，看看是否会像看电影一样轻松地理解代码：
以上就是14. 精读《架构设计之 DCI》的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/456890.html
微信扫一扫 
支付宝扫一扫 
