这些天因为工作上的需求，一套代码部署到不同的环境里。
虽然说是一样的业务，但是在不同的环境里难免会有一些少许不同的业务。
刚开始的时候觉得没什么问题，分了几个分支。
但是后来感觉越来越不对劲了，不同的环境分不同的分支，以为是很简单的事情。
时间长了，分支之间的差异也越来越大，感觉应该分不同的仓库。
这分了仓库问题又来了，改了Bug需要再不同的仓库里重复的修改代码，审查代码，合并代码，测试...
把我忙的不亦乐乎。
这让我怀疑，是不是代码结构本身有问题？
虽然现在用的Go语言不是面向对象编程语言，
但是我觉得经典的面向对象编程思想应该能对我有帮助。
我就查查看看这些原则，当做自己的笔记简单的整理了一下。
代码架构的设计原则中最普遍的是solid原则。
SRP Single Responsibility Principle 单一责任原则
OCP Open Closed Principle 开放封闭原则
LSP Liskov Substitution Principle 里氏替换原则
ISP Interface Segregation Principle 接口分离原则
DIP Dependency Inversion Principle 依赖反转原则
◆ SRP:单一责任原则(Single Responsibility Principle)
一个类只完成它应该完成的职责。
任何一个软件模块都应该只对某一类行为者负责。
它的作用就是告诉我们在哪里划清边界。
◆ OCP:开放封闭原则(Open Closed Principle)
软件实体(类,模块,函数等等)应当对扩展开放，对修改闭合。
这其实就是要关注，增加新的功能的时候能不能不修改以前旧代码？
增加新功能，需要大改旧代码，说明没做好开放封闭原则。
◆ LSP:里氏替换原则(Liskov Substitution Principle)
模块之间应能自由替换。
其实就是替换别的模块的时候不应该影响别的模块，导致发生修改事项。
◆ ISP:接口分离原则(Interface Segregation Principle)
如果一个接口包含了过多的方法，应该通过分离接口将其拆分。
如果依赖和自己没有关系或不需要的东西，需要应该把他拆分，只依赖和自己有关系的不分。
◆ DIP:依赖反转原则(Dependency Inversion Principle)
上层(抽象)不应该依赖于下层(实体)，下层(实体)应该依赖于上层(抽象)。
换句话说上层策略性代码不应该依赖底层细节性代码，
底层细节性代码应该依赖上层策略性的代码。
包的内聚性三原則
◆ REP:复用/发布等同原则(Release Reuse Equivalency Principle)
复用的粒度就是发布的粒度，重用的包需要版本管理，使新版本发布后还可以继续使用老版本。
不应该通过复制粘贴代码来复用，应该通过能发布的包复用代码。
◆ CCP:共同闭包原则(Common Closure Principle)
将那些因相同原因同时发生变化的类集合到组件中。
有相同改变原因放入同一個组件。
告诉我们哪些应该放在一起，倾向于把组件个体变大。
◆ CRP:共同复用原则(Composite Reuse Principle)
不要强迫依赖他们不需要的东西，
一个包中的所有类应该是共同重用的，如果重用了包中的一个类，就应该重用包中的所有类。
为了不必要的发布，切分没有关联的功能。
告诉我们哪些不一应该放在一起，倾向于把组件个体变小。
包的耦合性三原则
◆ ADP:无依赖环原则(Acyclic Dependencies Principle)
组件或包的依赖关系图中不允许存在环。
不要出现以下情况 A -> B -> C -> A
◆ SDP:稳定依赖原则(Stable Dependencies Principle)
依赖关系必须指向更稳定的方向
不稳定的依赖稳定的，稳定的不要依赖不稳定的。
◆ SAP:稳定抽象原则(Stable Dependencies Principle)
组件或包的抽象程度应该和其稳定程度一致
越抽象的应该是越稳定的。
欢迎大家的意见和交流
email: li_mingxie@163.com
网友评论