《架构与思想：phalapi核心设计和思想解读》由会员分享，可在线阅读，更多相关《架构与思想：phalapi核心设计和思想解读（7页珍藏版）》请在金锄头文库上搜索。
1、架构与思想：Phal Api核设计和思想解读设计软件有两种法：种是简单到明显没有缺陷，另外种复杂到缺陷不那么明 显。 -托尼.霍尔5.1.1 前在软件程这学科和业，关于软件程的解说有很多。有说开发是门艺 术；有说开发是种技艺；也有说开发是门哲学。但个认同从实主义和理 性的度去理解。例如个框架，我们之所以认为它好是因为我们发现这个框架遵循了编程规范、适当 地使了设计模式、巧妙地结合了设计原则、有着稳定的依赖、代码复杂度低、并且 有着很代码覆盖率的单元测试等等。也就是说，好的框架都是可以被解释的。既然可以被解释量化，也就可以学习、参考 和借鉴。5.1.2 共性和可变性分析关于共性和可变性分析，在设
2、计模式解析书中有着常到位的讲解。CVA是种很容易的理念，按我的理解即： 抽离共性、隔离变化 。有点类似易经 的“变”与“不变”。诚然，在过去的教育中（包括学在内的），对于软件开发都着重谈论向对象开 发，即OOD，以致于很多都对向对象开发产了很的误解。这种误解所带来 的实际情况就是： 我们都在进向对象开发，但却是标准呆板的向对象开发，缺 少，缺少活 。很多，都没有把我们开发员作为专业看待，甚连我们都否认我们是专 业的。所以很多时候当产品提出需求时，我们提供的开发周期往往会被外界以讲价的 式削减。何以？为什么医给出的术时间病没有讨价呢？因为很简单，在病 的眼，医是专业的。若我们也想达到专业的层次时
3、，何以为？学习、思考和实践，我认为少这三者是必 不可少的。所以，当我们在对PhalApi进设计时，我们进了次又次地酝酿、尝试、思考。 我们在思考：这些功能是否真的会在实际项中被使？开发员是否可能很好地进 扩展？此种决策是否便于单元测试、从思路上减少代码异味？。我们谨记敏捷开发，不过度设计。但我们也确实需要种思想上的指导。正好，我们 看到了 共性和可变性的分析（commonality and variability analysis, CVA） 。5.1.3 CVA和三种视、抽象类之间的关系引下设计模式解析书中的图表：在这种理念的指导下，我们会更愿意将接开发过程的共性抽离统起来，可变性 部分的则
4、可以由开发员根据不同的项情况进快速定制实现。5.1.4 不稳定性与抽象度分布除了常谈及到的“低耦合、内聚”外，在对代码进静态分析和衡量其可维护度时， 还有个值得注意的值，即：不稳定的度量。不稳定的度量可以根据以下公式计算获得：I = 离耦合 / (离耦合 + 向耦合)因此从宏观上，我们的代码结构，从上层到下层，应该向着稳定的向递增，也就是 说越底层越应稳定。对应 稳定依赖原则的规则（SDP），包之间的依赖应该朝着稳定 的向：不稳定的包应该依赖于更稳定的包。又结合不稳定性与抽象分布图，我们PhalApi框架的代码 应该部分分布在上图中的 抽象稳定区以实现框架层的建设、少部分分布在具体不稳定区以提
5、供些基础的功 能 。5.1.5 创建和使分离在框架的特性中，包括：可重、IoC Container以及SOLID五条原则的运等。这 就部分SOLID原则的运简单说明下。(1)S：单职责原则这是我们直都坚持遵守的原则，因为，我们也坚持 短美 的写法， 致于编写优 雅的代码、编写容易理解的代码 。(2)O：开放-封闭原则我们先希望的是在进接开发过程中，当需要新增个接时是开放的，对已有 的响应调流程是封闭的。即我们只需要实现新接逻辑即可，不需要改动其他过程 的调。因此在OCP原则的指导下，我们通过结合法封装了对接的初始化和 调。(3)D：依赖倒置原则PhalApi框架，最的特莫过于 它提供了种如何快
6、速进接开发的机制，但它 不强制你使不必要的功能，甚它还励你通过它来尝试研发的框架 。更进 步，PhalApi引了新颖明确的概念，如服务。我们把客户端调的接称之为接服务，把服务端到的资源称之为资源服务。对于后者，PhalApi提供了灵活的DI机 制，以持各项定制化的开发。5.1.6 PhalApi核架构图显然，到前为，从核架构图所折射出PhalApi的结构和代码是如此的 简单明 了、统规范。少我是这么认为的，也是直这样努的。从上图的核架构图可以看出，中间红部分的DI处于汇点位置，提供各种资源服务 的定位、创建、管理和提供。左上的代码例则表达本系统框架运的主流程： 创建个接实例，运响 应。右上解黄
7、部分则为多变的接应开发的代码，这特意罗列了两组接，意在表 明可以在此框架下挂靠多套接。最下是接开发过程中所到的各种基础设施和技术，如志、配置读取、缓存、 加密、请求和响应等。同样，除各应项中形式多变的接开发外，这块的底层技 术亦撑不的需求。因为，PhalApi只是作了共性的抽离，即提供级抽象且稳 定的接或者抽象类，以约定规约视中接的函数签名，不作过多的具体实现。同 时以DI作为辅助，持快速扩展。5.1.7 PhalApi核执流程和其他框架不同，除了有档对基本使有说明外，我们还提供了我们框架核的设 计和思想，以便家洞明其中的原理从进步优化扩展。这，扼要说明下PhalApi框架中接请求背后的核执流
8、程。从上图的时序图中可以看出，在PhalApi中，个接的请求处理，只要分为两个环 节： 接服务初始化 和 接服务调 。(1)接服务初始化在Web Service中，往往需要对服务进注册发布后，才能开放请求。这免去这 层，但遵循 创建和使分离 的原则，我们将接服务的初始化进了封装，以便可 以统进初始化、异常处理和些权限ACL的控制，甚接访问的统计等操作，更为重要的是接开发员可以进绪开发，不 需要过多知道如何合法创建接服务。在1.2. 步骤中，UML时序图中的:generateService()表对静态函数的调，即对应代 码：PhalApi_ApiFactory:generateService()
9、;随后，可以看到（假设我们这次请求的服务为：?service=Demo.DoSth），我们创建了 个指定接的实例（此接类须继承于PhalApi_Api基类），并以变量a返回实例。如果请求的服务法，则会以 400法请求 返回给客户端。正确创建接服务a 后，则会进接的初始化，其中有接参数规则的解析和注册了过滤器服务后的检 测操作。当这系列的操作都成功执后，我们将会得到个接服务实例a返回。 因此，在接服务的创建过程中，我们没有过多地限制，是预留了很的空间给到接项定制开发。此，接服务的创建完成。(2)接服务调在完成复杂的创建作后，客户端（备注：这指的是服务端开发的开发客户端）只 需要简单调需要进的操作
10、即可。这块，则需要接项具体开发实现，也是我们项级的核部分。在获取接服务的背后，我们建议结合领域驱动设计的理念，对项代码进这样的 层级划分：Api接层：于接收参数并响应接的请求； Domain领域层：于处理复杂的领域业务逻辑，保证规则只出现次； Model数据源层：更义上的Model层，提供数据来源，不限于DB；最后，是我们客户端关的返回格式。 默认情况下，我们都是以JSON格式返回的， 但仍然可以轻松持其他格式的返回，如JSONP、XML等。只需要简单地开发实现， 然后重新注册即可。此，接服务的调完毕。5.1.8 DI持下的轻松扩展当使个开源框架时，我们既喜欢其强的，但盾的同时我们又害怕其中的
11、 复杂性，原因莫过于：学习成本、出现问题时怕驾驭不了。在这，在PhalApi这，这切都是这么简单，简单地又如此明了。当需要进资源服务的扩展时，我们可以：实现需要的服务实现指定资源服务在规约视约定的接，假设我们需要件来当作新的缓存存 储。则需：class MyCache_File implements PhalApi_Cache public function set($key, $value, $expire = 600) /.public function get($key) /.public function delete($key) /. 在重新注册当实现的功能后，只需要简单地在件重新注
12、册即可。如：DI()-cache = new MyCache_File();最后，另兴奋的是，原来全部的调代码都不需要改动，即可享受后期调整升级后 的新功能！完全避免了曾经那种“牵发动全”的痛苦。并且，定制开发出来的实 现类，还可以跨越业务在其他项中共。这不正是我们常常所说的代码重吗？如今，我们很优雅地做到了！然，我们在实际开发中收获到的远远不是代码重这么简单，是种更好的开发 实践。因为通过DI使得创建和使分离，所以我们可以让级的开发同学实现服务功 能的开发，然后再提供给普通的开发同学使，新亦然，因为对他们来说：会就 。当然，对于级的同学，还应该遵循开发的最佳实践，坚持单元测试，以保证我 们提供了可靠的接（义上的接，HTTP请求的接）给我们的“客户端”使 。若如此，我们的开发合作岂不是很更合理、更明朗、更愉快？哈哈，我想是的。作为个框架，我们应当以发散的式去设计；但为了能为应提供可的功能，我 们又应当以收敛的式去实现。 如果我们提供的功能不以满部分主流的业务场景，那么我们少需要提供可扩 展的空间。正是出于这样的考虑，我们虔诚地引了DI。W3Cschool（）最的技术知识分享与学习平台此篇内容来于站户上传并发布。
