面一家很老的电力公司问到的，那个四十多岁的戴金丝框眼镜的老头盯着一个面试文档一句一字的问概念，就问到这个问题，我真的是服气了，他自己都肯定记不住，但是却要求面试者完全背熟这些概念性的问题。

说句实在的，在实际项目开发中，没人会抠着这八大原则的字眼去写业务代码，我们都会大概知道有这么个约束，就自然而然地写，并且很多大公司的接口设计，也是有一定程度上打破这些原则的。

（1）单一职责原则

每一个类甚至每一个接口都只负责完成一个业务操作。比如我们一开始写demo时候，deleteById（int id ）就是严格遵循了这个原则。
打破：
那么我要根据名称删除或者根据性别删除，难道还要写多个？但是这样明显不太符合实际开发，于是就有了deleteByType(int type , Param)这种，根据type来区分要删除的内容。截止到目前，这个接口还是遵循的，只负责‘删除‘的操作。
再次升级：新增一个用户，updateUser(id , param) ,这个之所以不写add，是因为我们把update也放进去了，nest.js的一个持久层就是这么做的，先根据这个ID找，由于是主键索引，速度非常快，如果找到，就代表是更新，如果找不到，就代表是新增用户，那么这个接口或者类，就是完全打破了单一职责原则。

（2）里氏替换原则

就是父类可以存在的地方，替换成子类也可以。
子类存在的地方，父类不一定可以替换。
打破：
试想一下，子类可以定义自己的一些特有的方法，假如父类中不存在，那么在替换后如何使用呢？所以就有个条件是：所有子类的方法，都必须在父类中声明（你可以不实现），这也要求父类要以抽象类或者接口的形式出现。

（3）面向接口编程而非面向实现

尽量依赖抽象，而不依赖于具体的实现类
打破：
…理想是好的，但是敲代码还是根据实际业务场景来，对吧大佬们…

（4）接口隔离原则

提供的接口，应该是小而独立的多个功能接口，不能是一个总的大接口。
打破：
背到这个原则，很想笑，我做过腾讯广告系统对接和公众号开发，例如公众号开发中的那唯一一个事件通知的回调地址，就是赤裸裸打破这个原则，所有的EventType，Msg，都传到唯一个通过验证的接口，在Switch方式发散出去。你能说这种设计模式不好吗？难道你想100种EventType写100个对接接口？

（5）迪米特洛原则（最少知识原则）

类与类相互调用，传递的参数越少越好，提高每个类之间的相互独立性，减低耦合度。
…嗯…噗嗤哈哈哈哈哈，看业务场景吧

（6）开闭原则

面向扩展开发，对修改关闭，一句话总结不要改正常运行的老代码。
打破：
这个原则是我很赞同的，之前改过老旧代码，由于Node没有继承和抽象关系（现在新版本的有了，虽然Node不是面向对象，但是深入做过的人都知道，它最近几年不断向Java靠拢，各种模仿抄袭），很多业务代码都是基于原来的基础改，日积月累，改到改不动，被迫重构。以后写代码，还是要牢牢遵守这个开闭原则。

（7）组合复用原则（聚合复用原则）

这个是部分基于开闭原则基础之上，新增扩展功能的时候，能新增一些类来组合，就不要用继承关系。目的是通过一种新的关联关系来减低耦合度。
你我都知道，理想化的乌托邦不存在～

（8）依赖倒置原则

说白了就是让你多Abstract，interface，不要死板板的一个个Service调用另外一个Service。