如何理解DCI模式

Question

根据维基百科的数据，上下文和交互(DCI)是计算机软件中用于对通信对象系统进行编程的一种范式。在这里，我不清楚DCI试图解决的问题。你能用简单的例子解释一下吗？在您的示例中，数据、上下文和交互是什么？

Answer 1

DCI架构的关键方面是：

• 将系统是什么(数据)和它所做的事情(功能)分开。数据和函数有不同的变化率，因此它们应该分开，而不是像现在这样放在类中。
• 创建从用户的心智模型到代码的直接映射。计算机应该以用户的身份思考，而不是相反的方式，而代码应该反映这一点。
• 使系统行为成为一个一流的实体。
• 良好的代码可读性，在运行时没有惊喜。

我突出强调了用户的心理模型，因为这正是它真正的意义所在。系统架构应该基于用户的思维过程，而不是工程师。

当然，与项目有关的每个人都应该讨论和制作心理模型，但这是很少见的。通常，工程师将根据模式、分解、继承、多态性编写代码，而对用户来说有意义的代码部分则被混淆在层层结构后面。

这就是DCI试图补救的地方。这些年来，它遇到了一些阻力，在我看来，因为工程师们喜欢他们的结构和阶级，所以他们主要关注这一点。

一个说明性的代码示例会太长，无法在这里发布，但思维方式无论如何更重要。它是关于对象动态地协同工作，以解决特定的问题。我在这里做了一个更大的教程，其中包含了一些代码：https://github.com/ciscoheat/haxedci-example

另外，我强烈推荐Trygve一瞥视频作为进一步解释，由DCI作者之一James作进一步解释。

Answer 2

如果你从原始作者那里读到本论文，特别是“我们哪里出错了？”一章，作者们给出了一些他们觉得需要一种新方法的理由。

简而言之:作者抱怨说，正确的面向对象方法导致了业务逻辑的“分裂”。这是真的，因为这是我们分解问题的主要原因，这样我们就不必一蹴而就地处理整个逻辑了。

作者争辩说(在上面的同一章中)，以前的程序方法更好(给出FORTRAN代码的例子)，因为我们可以顺序阅读代码并决定它是否做了它应该做的事情。

他们还认为(在下一章:回到用户的头脑中)，开发人员更容易先考虑“数据”，然后再考虑过程(例如交互)。

作者基本上主张至少部分回归过程编程，清楚地将数据和逻辑分开，而不是将“数据和逻辑”捆绑在一起的面向对象。

我个人的观点是，称这种方法为面向对象的方法有点误导，因为它是对它的强烈批评，并有明显的偏离它的意图。但是，不要相信我的话，读这篇文章。