爪哇缪斯的博客

通过上面的例子，我们可以看到小王遇到的问题就是，自己的车标不是宝马车标，所以不符合宝马公司允许停车的标准了。那么，我们可以这样认为：宝马汽车】是父类，它有一个方法是getLogo()，这个方法会返回BMW；3系、X3、5系、7系……】是子类，继承了父类的getLogo()，调用后也会返回BMW；所以宝马公司就有理由决定，只要调用getLogo()方法且返回“BMW”的车子，都可以被认为是宝马汽车，那么自然而然可以通过这个条件，来限制哪些车辆可以免费停到BMW的专属车位了。而小王自己把方法。

一个类或者模块只负责完成一个职责。子类对象能够替换父类对象，而程序逻辑不变。继承必须确保父类所拥有的性质在子类中仍然成立。下层模块引入上层模块的依赖，改变原有自上而下的依赖方向。要面向接口编程，不要面向实现编程。建立单一接口，不要建立臃肿庞大的接口。接口尽量细化，同时接口中的方法尽量少。单一职责原则和接口隔离的区别？它们的审视角度不同。单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分。接口隔离原则要求接口的方法尽量少。迪米特法则，也称为最少知识原则。描述的是领域划分的概念。。......

根据上面的故事，我们可以发现，我们最初的出租车强制要求是大众的桑塔纳了，那么就是我们常说的：依赖了具体的实例而后面，我们针对出租车总结出了N条特征，那么这个就是我们常说的：接口我们针对出租车的N条特征来全球征集符合特征的车辆，这些车辆都有机会成为出租车，那么就是我们常说的：基于接口开发好咧~ 故事就讲到这里了，今天你学会（fei）了嘛~ 期待我们下期再见~今天的文章内容就这些了：写作不易，笔者几个小时甚至数天完成的一篇文章，只愿换来您几秒钟的分享。更多技术干货，欢迎大家关注公众号“

通过上面的一个故事，大家可以看到，从之前一个员工要负责和面制馅包馅成型烘焙这一系列流程操作，到后来只负责其中的一件事，这其实就是单一职责原则了。除了可以提高生产力之外，还有一个非常重要的点就是——可替换性；我们假设其中有某位工人要离职不干了，那么他之前是负责包馅的，我们只需要再培训一个包馅的员工补充上去即可。而如果是一个全流程都要负责的员工离职了，这个培训和替换的代价就非常大了。其实在我们开发和架构上，也是这样的。从之前的单体架构，再到现在的微服务架构，我们会发现，

从上面的小故事，我们可以看到，小王没法玩这款游戏的主要原因就是显卡配置太低了，由于一体机对于硬件升级的“开闭原则“很不友好，所以，只能通过更换电脑这种高昂的代价还满足用户的需求了。而对于普通的电脑来说，显卡不行升级显卡就可以了；主板不行升级主板；硬盘不行升级硬盘……，我们发现，对于不同的需求，只需要进行小范围的调整，而不至于去更换整台电脑。那么，这就满足了我们即将要介绍的开闭原则了。下面，我们来看一下这个设计原则的定义：针对类、方法、模块应该对扩展开放，对修改关闭。

接口隔离原则（ISP使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。建立单一接口，不要建立臃肿庞大的接口。接口尽量细化，同时接口中的方法尽量少。单一职责原则和接口隔离的区别？答：它们的审视角度不同。单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分。接口隔离原则要求接口的方法尽量少。具体来说，实现接口隔离原则需要关注以下3点：接口要尽量小】不要违反单一职责原则，要适度的小，要适度。接口要高内聚】提高接口、类、模块的处理能力，减少对外的交互。

该模式将一个类的接口，转换成客户期望的另一个接口。适配器模式让原本接口不兼容的类可以合作无间。此时我们维护了一个员工管理系统，然后接入我们系统的第三方系统，我们都要求对方遵守我们的接口规范去开发，比如：提供方法名为的方法等等。但是，这次接入的系统已经有类似功能了，他们不希望因为两个系统的接入而重新开发新的接口，那么这对这种情况，我们就可以采用适配器模式，将接口做中间层的适配转换。