软件的复杂性与构造定律

快看!看!深入研究自然,你就会明白一切。 - 爱因斯坦

复杂性是被低估的。复杂越高,开发人员会感到不安。对其的理解认知负荷代价就越高,我们就更不快乐。真正的挑战是在构建我们的系统时要保持其有序以及工程师的生产方式。对于这一点,一个简单的物理规律可以帮助我们:构造定律 the Constructal Law.

当我们拥有臃肿大量的组件和类时,其中每一个又由大量的职责行为功能组成,我们不会在系统层面去思考,相反,我们只是将大量脂肪性质类进行组群,从外表看,你是无法找出这个系统做什么用的,这个系统代表的,业务需求或用户案例是什么。因为我们的应用程序进行了隐藏。

Neil Johnson, 在其a big proponent of Complexity Science中对复杂系统的定义如下:

(复杂的)系统表现出是一种复杂的有序和无序行为的混合。

对于软件来说,这种复杂的系统一般不是偶然发生的,它它是人类人为的结果。是工程师在以有序和可持续的方式构建组件和系统。    

最聪明的人自从60年代开始在计算机科学已经进行了不少最佳实践。然而,这是不够的。虽然我们已经从自然中得到启发解决了我们的不少困难问题,如神经网络、能源发电和液压。令人惊讶的是,当谈到复杂性,自然也有一种复杂的方法来解决这一问题:在有序和无序中平衡。

有序和无序

软件设计者应该是分离应该分离事物,而不是将本应一起考虑的事情进行分离。-Kent Beck

当我们决定打破臃肿的组件分离成小和孤立的部分时,我们面临着一个巨大的编程悖论:起初,一切都是彩虹和独角兽。但是后来,缺非如此。也就是说,事情并没有我们起初想得那么简单。

最初,我们第一次努力隔离后,我们会很高兴。一切看起来是有些紧张的和美丽的。然而,很快事情开始分崩离析,我们最终得到的东西比我们最初的组件要差得多。组件和类变得很大复杂了如下图:

那么下面最自然的事情是什么?放弃,回到我们当初的,继续臃肿的类。这样我们会感觉更好,但实际上我们是在倒退。这些组件不是问题。问题是复杂性,它是一个活着的野兽,会尽一切可能增长,你需要学会驯服它。(Quoting Neil Johnson)

(复杂的)系统似乎是"活着"。系统是在一个高度不平凡的且经常复杂的方式演进发展,这是由一个代理的生态驱动着,这些代理相互作用交互,且在对不断的反馈下不断地适应。

复杂性会增加

让我们将系统的复杂性看成是两个组件之间的许多交互,在两个组件情况下,复杂度是1,如下图:

如果增加一个组件,复杂度将从1增加到3:

复杂度以指数级的增长是惊人的,当我们增加到六个组件,复杂度将是15。

显然,这种拓扑可能是一个极端,但却能公平地明复杂性需要驯服。老实说,这个极端的例子并不少见,这正是人们做的事情,复杂性感染一切。什么出错了吗?

构造定律Constructal Law

自然界是如何应对这复杂呢?这在物理中被称为构造定律 Constructal Law, 仅有的我们知晓的大自然是如何指导复杂演化的规律(可以说是上帝创造万物的方式),是由Adrian Bejan于1995创立的构造定律:

For a finite-size system to persist in time (to live), it must evolve in such a way that it provides easier access to the imposed currents that flow through it.

对于一个有限大小的持续活动的系统,它必须以这种方式发展演进:它提供了一种在自身元素之间更容易访问的流动方式。

这个定理在自然中比比皆是,典型的是树的生长,先有根,再有枝,枝上再生枝叶。这种自发性质的设计反映了这一趋势:他们允许实体或事物更容易地流动 - 以最少的能量消耗到达最远的地方,就连街道和道路这些人为地构建物体,往往也是有排序的模式,以提供最大的灵活性。

构造定律致力于描述能量和物质在物理网络(如河流)和生物网络(如血管)中的流动,这个理论提出,如果一个流体系统(flow system)要继续存在(比如,生存),那么他必须始终提供更容易的方式来获得这个系统中的流体。换句话说,系统应该致力于将能量消耗减少到最低限度,而同时将消耗单位能量产生的熵提高到最大限度

Bejan相信,进化实质上是这么一个过程,即生物体不断的重组他们自身,以使能量和物质能够尽可能迅速高效的通过他们。更好的流体结构(flow structure),不管它们是动物还是河流,将取代那些较差的结构。。

构造定律作为第二个时间箭头,将和热力学第二定律一道将宇宙推向无序。

用构造定律进行有序化

回到我们这个复杂系统案例,我们可以使用构造定律降低复杂度,增加第7个组件后,将系统复杂度从15降低到8。

为了实现这种方式开发,你需要了解你的对象不是隔离的实体,而是一个大概念的一部分,比如这个大概念是你的webservice 客户端, 由很多对象组成包括连接 授权和XML文本 响应等。另外一个概念是你的数据库组件,它是由许多对象组成,如ORM Active Record类,校验类 连接类或它们之间的关系,这个大概念是一个聚合群组,聚合了很多子对象于其中,是一个集合概念。

下面以一种模块化分离关注是更加有意义:

与构造定律共存

在开发,不要让你的直觉欺骗你以至于产生马虎的代码。不要让一个模块的一部分调用另一个模块的内部组成部分。如下图:

对于一个组件A和X个组件之间的交互,每一次A的改变将需要1+ x 改变。

组件之间的交互越少,越好,远离扁平,用模块进行封装,我们能确保我们的系统增加时不会被复杂性淹没。

英文原文:Complexity in Software 3: The Constructal Law

加法是自然之道

ORM和Rails的问题

原文地址:https://www.cnblogs.com/feng9exe/p/8232655.html

时间: 2024-10-18 18:21:48

软件的复杂性与构造定律的相关文章

构造定律

构造定律作为第二个时间箭头,将和热力学第二定律一道将宇宙推向无序. 宇宙遵循的神秘定律! 编辑 在宇宙中,各个天体的尺寸可谓相差十万八千里,就算是在我们的太阳系之内,各大行星的大小的差异就足以让人惊叹.为什么各个行星.各个恒星乃至各个星系之间的尺寸会存在差异,而不是完美的均匀呢? 研究者们相信,充满不同尺寸的天体将比充满尺寸相近的天体更有利于宇宙缓解由引力造成的紧绷状态. 据杜克大学的热力学专家Adrian Bejan教授称,这种多样性(diversity)或多层次性(hierarchy)都是因

设计模式是在运用构造定律

大家看这些模式图片,是不是树?http://www.dofactory.com/net/design-patterns所有的都是树,下面都是构造定律.那些设计模式就是在研究如何构建树和如何在树上运动的.事实上应该是创建型模式.行为型模式,没有结构型模式.因为它的结构只有一个:树.如果看到了图,肯定是因为少识别出了某个节点或者错误的识别出来了某个节点.添加上少识别的节点纠正识别错误的节点后就一切都是树了.比如这个抽象工厂模式是怎么运用构造定律的,它的树大概是这样: 其实树就是对一个集合中的所有元素

领域驱动设计 软件核心复杂性应对之道 读书笔记

问题: 1.  何为领域驱动设计(DOMAINDriven DESIGN)? 2.  UBIQUITOUS LANGUAGE(领域通用语言)应该是如何去描述 3. 作者:Eric Evans 第二部分 模型驱动设计的构造块   第四章 分离模型 分层架构如图: 而主要的业务模型及在领域层. 第五章 软件中所表示的模型 模型主要包括Entity.Value Object和service 问题: Entity.Value Object和Service是如何定义的? 它们是如何进行区分和划分的? EN

《领域驱动设计 软件核心复杂性应对之道》 - 书摘精要

(序) 领域模型的最大价值是它提供了一种通用语言,这种语言是将领域专家和技术人员联系在一起的纽带: (P2) 模型是一种知识形式,他对知识进行有选择的简化和有目的的结构化: (P33) 面向对象编程之所以功能强大,是因为它基于建模范式,并且为模型构造提供了实现方式: (P48) 领域驱动设计只有应用在大型项目上才能产生最大的收益,而这也确实需要高超的技巧: (P70) 在大型系统中,中等粒度的.无状态的 Service 更容易被重用,因为它们在一个简单的接口背后封装了重要的功能: 细粒度的对象可

读书笔记--领域驱动设计:软件核心复杂性应对之道-1

2015–6-28 第一章 消化知识 有效建模的要素 1. 模型和实现的绑定 模型要基于现实的业务,不能和用户现实的业务脱节 2. 获得一种基于模型的语言 通过一种统一的语言(业务人员和开发人员都能理解的)去描述所建立的模型,如UML图,基于业务的术语,无奇异的,作者的意思是业务人员和开发人员建立基于模型一个沟通的桥梁. 3.开发一个蕴含丰富知识的模型 灵活的,适应变化的的模型,模型不能简单等同于类图,而是解决复杂业务问题的方案.包含各种类型的知识 4. 提炼模型 对业务的描述要抽象,从场景的分

领域驱动设计:软件核心复杂性应对之道-2

2015-06-29 第二章 语言的交流和使用 模式: UBIQUITOUS LANGUAGE(通用语言) 开发在于领域专家沟通时,需要建立一个通用语言,来减少沟通的成本 基于业务,开发和业务达成共识,用双方都能理解的黑话来讨论序曲 强调了专业术语的差异,带来沟通和理解的成本,为了降低成本,必须使用一种共同的术语来建模. 这个术语更偏重于业务,而不是开发,但开发对于术语所代表的意义和业务要达成共识. 领域语言在描述业务场景或者是构建领域模型时,如果有歧义,则需要领域专家向开发人员澄清,清除歧义,

经验_思想_方法_总结

感谢: 感谢每一个打开这篇文章的人,听我在这里瞎扯!至于我为什么会有闲情写这篇文章呢?因为我每天想的是为什么要给我这样的需求,背后的人性是什么,我能再做些什么能让他更好.久而久之,我也稍微有了些自己的思维,善于去思考事物的本质,然后,我就有了点感悟,一些我觉得正能量的东西,一些我觉得值得传递的东西,如果我的磁场吸引了你的话,我很高兴,但请你以开放的心态来看待我所讲的东西,不要陷入我的思维里,你该有你的思维,读完我的文章后,你应该从中得到一些启迪,避免全盘接收,抛弃你传统的中国填鸭式的思维方式吧!

我的第二次(四则运算、构建之法、三个软件)

一.代码的coding地址:https://coding.net/u/xuchunxiao119/p/homework_count/git#user-content-homeworkcount 二.<构建之法>读后问题以及感言: 1. 对于7.3MSF团队模型,7.2.6保持敏捷,预期和适应变化,中的"我们是预期变化,不是期望变化"我们如何让自己的软件处于不断的变化之中?换言之,我们如果推出了一款软件之后,如何给软件预留足够的更新空间,这些空间的具体位置我们如何得知呢? 2

现代软件工程作业4-7(龙秋娴)

4.Dijkstra曾经提到:“Software engineering, of course,presents itself as another worthy cause,but that is eyewash: if you carefully read its literature and analyse what its devotees actually do,you will discover that software engineering has accepted as it