江苏龙网

  1. 主页 > 生活百科 > >

阿里技术大牛：一份架构师成神路线图( 五 )

架构师


 

阿里技术大牛：一份架构师成神路线图

文章插图
 
 
⑧项目视点 PV
项目视点(PV)集中反映了项目是如何有机地组织成一个釆办项目的有序组合 。
描述多个采办项目之间关联关系 ， 每个采办项目都负责交付特定系统或能力 。
 
阿里技术大牛：一份架构师成神路线图

文章插图
 
 
TOGAF ， Zachman ， ITSA 和 DODAF 是非常不错的架构框架 ， 尤其前两者应用很广泛 ， TOGAF 还有专门的架构认证 。
当我们掌握了这些框架 ， 我们是不是需要一些架构原则来指导更具体的设计?请看下文 。
架构原则
设计原则就是架构设计的指导思想 ， 它指导我们如何将数据和函数组织成类 ， 如何将类链接起来成为组件和程序 。
反向来说 ， 架构的主要工作就是将软件拆解为组件 ， 设计原则指导我们如何拆解、拆解的粒度、组件间依赖的方向、组件解耦的方式等 。
设计原则有很多 ， 我们进行架构设计的主导原则是 OCP(开闭原则) ， 在类和代码的层级上有：SRP(单一职责原则)、LSP(里氏替换原则)、ISP(接口隔离原则)、DIP(依赖反转原则) 。
在组件的层级上有：REP(复用、发布等同原则)、CCP(共同闭包原则)、CRP(共同复用原则) ， 处理组件依赖问题的三原则：无依赖环原则、稳定依赖原则、稳定抽象原则 。
①OCP(开闭原则)：设计良好的软件应该易于扩展 ， 同时抗拒修改 。这是我们进行架构设计的主导原则 ， 其他的原则都为这条原则服务 。
②SRP(单一职责原则)：任何一个软件模块 ， 都应该有且只有一个被修改的原因 ， “被修改的原因“指系统的用户或所有者 ， 翻译一下就是 ， 任何模块只对一个用户的价值负责 ， 该原则指导我们如何拆分组件 。
举个例子 ， CTO 和 COO 都要统计员工的工时 ， 当前他们要求的统计方式可能是相同的 ， 我们复用一套代码 ， 这时 COO 说周末的工时统计要乘以二 ， 按照这个需求修改完代码 ， CTO 可能就要过来骂街了 。
当然这是个非常浅显的例子 ， 实际项目中也有很多代码服务于多个价值主体 ， 这带来很大的探秘成本和修改风险 ， 另外 ， 当一份代码有多个所有者时 ， 就会产生代码合并冲突的问题 。
③LSP(里氏替换原则)：当用同一接口的不同实现互相替换时 ， 系统的行为应该保持不变 。该原则指导的是接口与其实现方式 。
你一定很疑惑 ， 实现了同一个接口 ， 他们的行为也肯定是一致的呀 ， 还真不一定 。
假设认为矩形的系统行为是：面积=宽*高 ， 让正方形实现矩形的接口 ， 在调用 setW 和 setH 时 ， 正方形做的其实是同一个事情 ， 设置它的边长 。
这时下边的单元测试用矩形能通过 ， 用正方形就不行 ， 实现同样的接口 ， 但是系统行为变了 ， 这是违反 LSP 的经典案例 。
Rectangle r = ... r.setW(5); r.setH(2); assert(r.area() == 10); ④ISP(接口隔离原则)：不依赖任何不需要的方法、类或组件 。该原则指导我们的接口设计 。
当我们依赖一个接口但只用到了其中的部分方法时 ， 其实我们已经依赖了不需要的方法或类 ， 当这些方法或类有变更时 ， 会引起我们类的重新编译 ， 或者引起我们组件的重新部署 ， 这些都是不必要的 。所以我们最好定义个小接口 ， 把用到的方法拆出来 。
⑤DIP(依赖反转原则)：指一种特定的解耦(传统的依赖关系创建在高层次上 。而具体的策略设置则应用在低层次的模块上)形式 ， 使得高层次的模块不依赖于低层次的模块的实现细节 ， 依赖关系被颠倒(反转) ， 从而使得低层次模块依赖于高层次模块的需求抽象 。
跨越组建边界的依赖方向永远与控制流的方向相反 。该原则指导我们设计组件间依赖的方向 。
依赖反转原则是个可操作性非常强的原则 ， 当你要修改组件间的依赖方向时 ， 将需要进行组件间通信的类抽象为接口 ， 接口放在边界的哪边 ， 依赖就指向哪边 。


推荐阅读


上一篇：今天是四九第几天2020年 2022年四九第一天是几号

下一篇：吃完辣的喝水会怎么样 吃完辣椒喝水能补救吗