#整洁

《架构整洁之道》之组件耦合

组件依赖关系图不应该出现环。我们一定有过这样的经历:当你花了一整天的时间,好不容易搞定了一段代码,第二天上班时却发现这段代码莫名其妙地又不能工作。这通常是因为有人在你走后修改了你所依赖的某个组件。这种情况叫做”一觉醒来综合症”。这种综合症的主要病因是:多个程序员同时修改了同一个源代码文件。虽然在规模相对较小、人员较少的...
代码星球 ·2020-12-27

《架构整洁之道》之组件聚合

软件复用的最小粒度应等同于其发布的最小粒度。从软件设计与架构设计的角度来看,复用/发布原则就是指组件中的类与模块必须是彼此紧密相关的。也就是说,一个组件不能由一组毫无关联的类和模块组成,它们之间应该有一个共同的主题或者大方向。从另一个角度来看,这个原则就没有那么简单。因为根据该原则,一个组件中包含的类与模块还应该是可以...
代码星球 ·2020-12-27

《架构整洁之道》之组件

组件是软件的部署单元,是整个软件系统在部署过程中可以独立完成部署的最小实体。例如:对于Java来说,它的组件是jar文件。而在Ruby中,它们是gem文件。在.Net中,它们则是DLL文件,组件则是一组源代码文件的集合。无论采用什么编程语言来开发软件,组件都是该软件在部署过程中的最小单元。我们可以将多个组件链接成一个独...
代码星球 ·2020-12-27

《架构整洁之道》之依赖反转原则

依赖反转原则主要想告诉我们,如果想要设计一个灵活的系统,在源代码层次的依赖关系中就应该多引用抽象类型,而非具体实现。我们每次修改抽象接口的时候,一定也会去修改对应的具体实现。但反过来,当我们修改具体实现时,却很少需要去修改响应的抽象接口。所以我们可以认为接口比实现更稳定。也就是说,如果想要在软件架构设计上追求稳定,就必...

《架构整洁之道》之接口隔离原则

回顾一下ISP最初的成因:在一般情况下,任何层次的软件设计如果依赖于不需要的东西,都会是有害的。从源代码层次来说,这样的依赖关系会导致不必要的重新编译和重新部署,对更高层次的软件架构设计来说,问题也是类似的。接口隔离原则告诉我们:任何层次的软件设计如果依赖了它并不需要的东西,就会带来意料之外的麻烦。...

《架构整洁之道》之里氏替换原则

1988年,BarbaraLiskov在描述如何定义子类型时写下这样一段话:这样需要的是一种可替换性:如果对于每个类型是S的对象o1都存在一个类型为T的对象o2,能使操作T类型的程序P在用o2替换o1时行为保持不变,我们就可以将S称为T的子类型。在面向对象这场编程革命兴起的早起,我们的普遍认知正如上文所说,认为LSP只...

《架构整洁之道》之开闭原则

开闭原则是BertrandMeyer在1988年提出的,该设计原则认为:设计良好的计算机软件应该易于扩展,同时抗拒修改。换句话说,一个设计良好的计算机系统应该在不需要修改的前提下就可以轻易被扩展。如果A组件不想被B组件上发生的修改所影响,那么就应该让B组件依赖于A组件。软件架构师根据相关函数被修改的原因、修改的方式及修...
代码星球 ·2020-12-27

《架构整洁之道》之单一职责原则

SRP是SOLID五大设计原则中最容易理解的一个。很多程序员根据SRP这个名字想当然地认为这个原则就是指:每个模块都应该只做一件事。没错,后者的确也是一个设计原则,即确保一个函数只完成一个功能。将大型函数重构成小函数时经常会用到这个原则,但这只是一个面向底层实现细节的设计原则,并不是SRP的全部。历史上,我们曾经这样描...

《架构整洁之道》之设计原则

通常来说,要想构建一个好的软件系统,应该从写整洁的代码开始做起。毕竟,如果建筑所使用的砖头质量不佳,那么架构所能起到的作用也会很有限。反之亦然,如果建筑的架构设计不佳,那么其所用的砖头质量再好也没有用。这就是SOLID设计原则所要解决的问题。SOLID原则的主要作用就是告诉我们如何将数据和函数组织成为类,以及如何将这些...
代码星球 ·2020-12-27

《架构整洁之道》之函数式编程

函数式编程语言中的变量是不可变的。为什么不可变性是软件架构设计需要考虑的重点呢?为什么软件架构师要操心变量的可变性呢?答案显而易见:所有的竞争问题、死锁问题、并发更新问题都是由可变变量导致的。如果变量永远不会被更改,那就不可能产生竞争或者并发更新问题。如果锁状态是不可变的,那就永远不会产生死锁问题。换句话说,一切并发应...

《架构整洁之道》之面向对象编程

面向对象是封装、继承、多态三项的有机组成。通过采取封装特性,我们可以把一组相关联的数据和函数圈起来,使圈外面的代码只能看见部分函数,数据则完全不可见。譬如,在实际应用中,类中的公共函数和私有成员变量就是这样。继承的主要作用是让我们可以在某个作用域内对外部定义的某一组变量与函数进行覆盖。多态是函数指针的一种运用。综上,我...

《架构整洁之道》之结构化编程

Dijkstra很早就得出的结论是:编程是一项难度很大的活动。一段程序无论复杂与否,都包含了很多的细节信息。如果没有工具的帮助,这些细节的信息是远远超过一个程序员的认知能力范围的。而在一段程序中,哪怕仅仅是一个小细节的错误,也会造成整个程序出错。Dijkstra提出的解决方案是采用数学推导方法。他的想法是借鉴数学中的公...

《架构整洁之道》之两个价值维度

对于每个软件系统,我们都可以通过行为和架构两个维度来体现它的实际价值。软件研发人员应该确保自己的系统在两个维度上的实际价值都能长时间维持在很高的状态。不幸的是,他们往往只关注一个维度,而忽视了另外一个维度。更不幸的是,他们常常关注的还是错误的维度,这导致了系统的价值最终趋降为零。软件系统的行为是其最直观的价值维度。程序...

《架构整洁之道》之编程范式总览

结构化编程是第一个普遍被采用的编程范式(但是不是第一个被提出的),由EdsgerWybeDijkstra于1968年最先提出。与此同时,Dijkstra还论证了使用goto这样的无限制跳转语句将会损害程序的整体结构。结构化编程范式归纳:结构化编程对程序控制权的直接转移进行了限制和规范。编程领域中第二个被广泛采用的编程范...

《架构整洁之道》之设计与架构究竟是什么

二者没有任何区别。“架构”这个词往往使用于”高层级”的讨论中。这类讨论一般都把”底层”的实现细节排除在外。而”设计”一词,往往用来指代具体的系统底层组织结构和实现的细节。但是,从一个真正的系统架构师的日常工作来看,这样的区分是根本不成立的。举个例子说明:以给我设计新房子的建筑设计师要做的事情为例。新房子当然是存在着既定...
首页上一页12下一页尾页