下划线学习频道Appearance
五大设计原则之间的关系 
首先，开闭原则是 SOLID 原则追求的最终目标。为什么这么说呢？因为修改代码非常容易引入 Bug，即便是很小的改动都有可能引起未知的 Bug。而一旦系统因为 Bug 出现故障，担责的一定是我们。没有人愿意担责，所以，我们都更喜欢写新代码而不是修改旧代码。除此之外，在设计之初就尽量以实现开闭原则为目标，它能为你在未来的实际开发中提供更高的代码扩展性。不过，这里需要注意一下，开闭原则不是封闭原则，千万不要把遵守开闭原则当作必要条件，如果代码需要适应现实的需求变化而必须要修改的话，那么这时就应该违反原则。当然尽量还是要做到开闭。
其次，单一职责原则是重要的基础原则，它帮助实现了里氏替换原则、接口隔离原则和开闭原则。你只要仔细分析各个原则的含义就能发现，它们都涉及了两个关键动作：分离和替换。那么是逻辑揉在一起、接口定义模糊的代码容易分离和替换，还是职责单一、接口抽象清晰的代码容易分离和替换呢？答案很明显是后者。之所以说单一职责原则是基础，就是因为要想实现代码的灵活扩展性需要更容易理解的模块。而职责单一的模块，更容易被组合起来用于更大的职责，也能进行快速替换和修改。
最后，依赖反转原则是一种指导原则，同样是用来分离和替换代码的。只不过它作用在更高层次、更广的范围内，因为它太重要了，下一讲我会专门详细介绍它
总结
当你使用 SOLID 越多，代码的可重用性变得越来越高的同时，代码逻辑却也相应地变得越复杂。之所以会变得复杂，是因为 SOLID 原则太过于重视分离与灵活替换，这就意味着我们可能需要创建很多单一的类和方法，再通过接口把它们连接起来，这样反而容易让模块和模块之间的调用关系变得更错综复杂，增加了整体的复杂性。这显然违背了 KISS 原则。
所以，当你想要兼顾 KISS 原则和 SOLID 原则时，最简单的办法就是控制接口的数量。尽量抽象某一个职责下的通用接口类（可以有多个实现类），而不是搞出很多的一个接口只对应一个实现类的模块，这看上去是在依赖抽象，实际上还是在依赖单个的实现。
SOLID 原则本质上就是为了在不修改原有模块的情况下有更好的扩展功能，也就是实现开闭原则，但是要想真正做到，一定不能忽略一个隐含的前提条件，那就是在设计时就要提前考虑模块的扩展性。如果一个系统在设计时就只有一个大模块，所有的功能都揉在里面，这样即便你想要应用 SOLID 原则，也是做不到的。
另外，在应用 SOLID 原则时一定要结合五个原则综合考虑，并结合实际业务进行合理取舍。千万不要在某个原则上过度解读，而误认为要满足所有 SOLID 原则才算是应用了 SOLID 原则。