【19】读感 - 架构整洁之道(二)

概述

继上一篇文章讲了前两章的读感，已经归纳总结的重点，这章会继续跟进的看一下，深挖架构整洁之道。

编程范式

编程范式从早期到至今，提过哪些编程范式，结构化编程，面向对象编程，函数式编程。

结构化编程指的是条件选择，比如if/else/while等等具有跳转含义语句，它让程序的逻辑具有结构性，作者归结为对程序控制权的直接转移进行了限制和规范。

面向对象编程

而面向对象编程，这个在从事Android开发的我来说，太熟悉不过，面向对象的特性就是封装、继承、多态，其中多态的表达，就是对程序控制权的间接转移进行了限制和规范。

和以往我了解的Android的面向对象特性的解释有所不同的是，封装我们都知道是隐藏细节，对外暴露能力。继承则是在某个作用域内（类&接口）对外部定义的某一组变量和函数进行覆盖，这里解释的是覆盖，事实上还有使用。而多态，我们所理解的同一行为，有多种不同的实现，所表达的就是重载和重写，但在这里，行为抽离出来了，接口定义的就是行为，而对接口的不同实现类似我们所说的重载和重写。它抽离出来想要表达的是什么呢？就是插件特性，所有的实现都可以看成是插件。这点很重要！

再要说的一个点就是依赖关系和控制流。三层架构的软件是什么样子的，高层调用中层，中层调用底层，他们持有对方，可以看作是依赖，而且持有的是具体的实现。系统行为决定了控制流，所以依赖不可避免的跟随程序的控制流。当底层发生了改变，随之产生的就是中层改变，进而影响高层改变，这就是这种架构的弊端。

一旦我们使用多态（这里指接口的方式），依赖关系的方向和控制流的方向相反，这就是依赖反转

ML1和接口I在源代码上的依赖关系，或叫继承关系

面向对象编程的核心本质就是这样，依赖关系不再受控制流的限制。这种能力有什么作用呢？我们可以让数据库模块和用户界面模块都依赖于业务逻辑模块，而非相反。这是书中的原话。

回想到之前讲的多态体现的插件特性，用户界面和数据库都是作为业务逻辑模块的插件，可以随时替换。也就是说，业务逻辑模块的源代码不需要引入用户界面和数据库这两个模块

函数式编程

让我不解的是函数式编程，我最早接触函数式编程的时候，当时是看的第三方库Rxjava，一种函数式编程的概念提出，通过操作符，以及函数化的格式，简化了编程逻辑，后续又应用到kotin的开发中，有许许多多的操作符。而书中的函数式编程，让我不知其解。经过查询才发现，就是我所看到过的东西。书中归结为对程序中的赋值进行了限制和规范。这句话怎么理解呢，它指明函数式编程语言中应该是没有赋值语句的，即所有操作赋值，然后输出值的逻辑，就应该是将操作直接作为参数，传递给输出的方法。

未完待续！

而这三个编程范式，结构化、面向对象、函数式编程对应了软件架构的功能性、组件独立性以及数据管理。我不是很能对应的上，但是对于软件架构关注的点，我还是十分认可的。

总结

过去50年的开发历程当中，主要学到的东西是 ---- 什么不应该做！

原文地址：https://blog.csdn.net/mr_zengkun/article/details/140519297

免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！