solid原则简单笔记

这些天因为工作上的需求，一套代码部署到不同的环境里。
虽然说是一样的业务，但是在不同的环境里难免会有一些少许不同的业务。

刚开始的时候觉得没什么问题，分了几个分支。
但是后来感觉越来越不对劲了，不同的环境分不同的分支，以为是很简单的事情。
时间长了，分支之间的差异也越来越大，感觉应该分不同的仓库。
这分了仓库问题又来了，改了Bug需要再不同的仓库里重复的修改代码，审查代码，合并代码，测试…
把我忙的不亦乐乎。

这让我怀疑，是不是代码结构本身有问题？
虽然现在用的Go语言不是面向对象编程语言，
但是我觉得经典的面向对象编程思想应该能对我有帮助。
查到了一个很有趣的原则：solid原则。

当做自己的笔记简单的整理了一下solid原则。

SRP	    The Single Responsibility Principle	    单一责任原则
OCP	    The Open Closed Principle	            开放封闭原则
LSP	    The Liskov Substitution Principle	    里氏替换原则
ISP	    The Interface Segregation Principle	    接口分离原则
DIP	    The Dependency Inversion Principle	    依赖倒置原则

◆ 单一责任原则(The Single Responsibility Principle)

一个类只完成它应该完成的职责。

这一原则其实项目刚开始的时候很容易遵守。
但是项目久了后，你会发现你的项目越来越变味儿。
需要不断的重构中，维持单一责任原则。

◆ 开放封闭原则(The Open Closed Principle)

软件实体(类,模块,函数等等)应当对扩展开放，对修改闭合。

好难好难。
尤其是api的版本不断的升级，老版本的api又不能弃用的时候，
而且结构在不断的变化的时候…ㅠㅠ

◆ 里氏替换原则(The Liskov Substitution Principle)

只有在确定是 is-a 的关系时才能使用继承。

这一原则我刚开始的时候还真不理解。其实很简单。
我们创建一个[人]的抽象类， [老人]，[孩子]，[女人] 的类可以都继承[人]这个抽象类。
那[猩猩]也走路，用手。很像人，它能不能继承[人]？
不行！[猩猩] is [人] 是不能成立的。

还有网上有个这样的例子也举得很不错。
有个[鸟]的抽象类。那[鸵鸟]能继承[鸟]这个抽象类吗？
这要看业务对[飞]这方法怎么处理?
如果是放到[鸟]里，那[鸵鸟]就不应该继承[鸟]。
如果[飞]这方法不太重要，不需要放在[鸟]的抽象类里，
那[鸵鸟]可以继承[鸟]了。

[鸵鸟] is [鸟]。 如果说这命题不成立，有点牵强。
但是[鸵鸟]能否继承[鸟]，这得看具体业务场景了。

◆ 接口分离原则(The Interface Segregation Principle)

如果一个接口包含了过多的方法，应该通过分离接口将其拆分。

拆分后怎么管理和监控，又是一门学问…^^

◆ 依赖倒置原则(The Dependency Inversion Principle)

上层(抽象)不应该依赖于下层(实体)，下层(实体)应该依赖于上层(抽象)。

这道理其实都懂，但是有意的事情是，如果定期做重构的话，你会发现有些代码还真这样。

另外多提一下2个原则
◆ 迪米特法则，又称最少知道原则（Demeter Principle）

一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

◆ 合成复用原则（Composite Reuse Principle）

合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。

其实也没有什么内容，就当自己的笔记整理了一下。

---

欢迎大家的意见和交流

email: li_mingxie@163.com