架构与思想：Phal Api核心设计与思想解读.pdf

架构与思想：Phal Api核⼼设计和思想解读 设计软件有两种⽅法：⼀种是简单到明显没有缺陷，另外⼀种复杂到缺陷不那么明 显。 --托尼. 尔 5.1.1 前⾔ 在软件⼯程这⼀学科和⾏业⾥，关于软件⼯程的解说有很多。有⼈说开发是⼀门艺 术；有⼈说开发是⼀种技艺；也有⼈说开发是⼀门哲学。但个⼈认同从实⽤主义和理 性的⾓度去理解。 例如⼀个框架，我们之所以认为它好是因为我们发现这个框架遵循了编程规范、适当 地使⽤了设计模式、巧妙地结合了设计原则、有着稳定的依赖、代码复杂度低、并且 有着很⾼代码覆盖率的单元测试等等。 也就是说，好的框架都是可以被解释的。既然可以被解释量化，也就可以学习、参考 和借鉴。 5.1.2 共性和可变性分析 关于共性和可变性分析，在 《设计模式解析》⼀书中有着⾮常到位的讲解。 CVA是⼀种很容易的理念，按我的理解即： 抽离共性、隔离变化 。有点类似易经⾥ ⾯的“变”与“不变” 。 诚然，在过去的教育中 （包括⼤学在内的），对于软件开发都着重谈论⾯向对象开 发，即OOD ，以致于很多⼈都对⾯向对象开发产⽣了很⼤的误解。⽽这种误解所带来 的实际情况就是： 我们都在进 ⾯向对象开发，但却是标准呆板的⾯向对象开发，缺 少⽣⽓，缺少活⼒ 。 很多⼈，都没有把我们开发⼈员作为专业⼈⼠看待，甚⾄连我们⾃⼰都否认我们是专 业的。所以很多时候当产品提出需求时，我们提供的开发周期往往会被外界以讲价的 ⽅式削减。何以？为什么医⽣给出的⼿术时间病⼈没有讨价呢？因为很简单，在病⼈ 的眼⾥，医⽣是专业的。 若我们也想达到专业的层次时，何以为？学习、思考和实践，我认为⾄少这三者是必 不可少的。 所以，当我们在对PhalApi进⾏设计时，我们进⾏了⼀次又⼀次地酝酿、尝试、思考。 我们在思考：这些功能是否真的会在实际项⽬中被使⽤？开发⼈员是否可能很好地进 ⾏扩展？此种决策是否便于单元测试、从思路上减少代码异味？。。。 我们谨记敏捷开发，不过度设计。但我们也确实需要⼀种思想上的指导。正好，我们 看到了 共性和可变性的分析 （commonality and variability analysis, CVA ） 。 5.1.3 CVA和三种视⾓、抽象类之间的关系 引⽤⼀下 《设计模式解析》⼀书中的图表： 在这种理念的指导下，我们会更愿意将接⼜开发过程的共性抽离统⼀起来，⽽可变性 部分的则可以由开发⼈员根据不同的项⽬情况进⾏快速定制实现。 5.1.4 不稳定性与抽象度分布 除了常谈及到的“低耦合、⾼内聚”外，在对代码进⾏静态分析和衡量其可维护度时， 还有⼀个值得注意的值，即：不稳定的度量。 不稳定的度量可以根据以下公式计算获得： I = 离⼼耦合 / (离⼼耦合 + 向⼼耦合) 因此从宏观上，我们的代码结构，从上层到下层，应该向着稳定的⽅向递增，也就是 说越底层越应稳定。对应 稳定依赖原则的规则 （SDP），包之间的依赖应该朝着稳定 的⽅向：不稳定的包应该依赖于更稳定的包。 又结合不稳定性与抽象分布图，我们PhalApi框架的代码 应该⼤部分分布在上图中的 抽象稳定区以实现框架⾼层的建设、少部分分布在具体不稳定区以提供⼀些基础的功 能 。 5.1.5 创建和使⽤分离 在框架的特性中，包括：可重⽤、IoC Container 以及SOLID五条原则的运⽤等。这⾥ 就部分SOLID原则的运⽤简单说明⼀下。 (1)S ：单⼀职责原则 这是我们⼀直都坚持遵守的原则，因为，我们也坚持 短⽽美 的写法， 致⼒于编写优 雅的代码、编写⼈容易理解的代码 。 (2) ：开放-封闭原则 我们⾸先希望的是在进⾏接⼜开发过程中，当需要新增⼀个接⼜时是开放的，对已有 的响应调⽤流程是封闭的。即我们只需要实现新接⼜逻辑即可，不需要改动其他过程 的调⽤。因此在OCP原则的指导下，我们通过结合⼯⼚⽅法封装了对接⼜的初始化和 调⽤。 (3)D ：依赖倒置原则 PhalApi框架，最⼤的特⾊莫过于 它提供了⼀种如何快速进 接⼜开发的机制，但它 不强制你使⽤不必要的功能，甚⾄它还⿎励你通过它来尝试研发⾃⼰的框架 。更进⼀ 步，PhalApi引⼊了新颖明确的概念，⼀如服务。我们把客户端调⽤的接⼜称之为接⼜ 服务，把服务端⽤到的资源称之为资源服务。对于后者，PhalApi提供了灵活的DI机 制，以⽀持各项⽬定制化的开发。 5.1.6 PhalApi核⼼架构图 显然，到⽬前为⽌，从核⼼架构图所折射出PhalApi的结构和代码是如此的 简单明 了、统⼀规范。⾄少我是这么认为的，也是⼀直这样努⼒的。 从上图的核