接口隔离原则（Interface Segregation Principle，ISP）是面向对象编程中的一个基本原则。它强调应该将一个大接口划分成多个小接口，以便客户端只需依赖它们所需要的接口，而不需要依赖不必要的接口。ISP 的提出者是罗伯特·C·马丁（Robert C. Martin），他在《敏捷软件开发：原则、模式和实践》一书中首次提出了这一原则。
这两个定义可以归纳为一个意思：建立单一接口，不要建立臃肿庞大的接口。也就是说，接口尽量细化，同时接口中的方法尽量少。
接口隔离原则(Interface Segregation Principle，ISP)要求程序员尽量将臃肿庞大的接口拆分成更小的和更具体的接口，让接口中只包含客户感兴趣的方法。2002 年罗伯特·C·马丁给“接口隔离原则”的定义是：客户端不应该被迫依赖于它不使用的方法(Clients should not be forced to depend on methods they do not use)。该原则还有另外一个定义：一个类对另一个类的依赖应该建立在最小的接口上(The dependency of one class to another one should depend on the smallest possible interface)。以上两个定义的含义是：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。 有没有感觉与单一职责原则很像，接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的： ♞ 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。 ♞ 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建 简单来说接口隔离原则与单一职责的定义的规则是不相同的，单一职责要求的是类和接口职责单一，注重的是职责，没有要求接口的方法减少，例如一个职责可能包含 10个方法，这 10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束不使用的方法不要访问，按照单一职责原则是允许的，按照接口隔离原则是不允许的。
从功能上来看，接口隔离原则和单一职责原则都是为了提高类的内聚, 降低类之间的耦合, 体现了封装的思想。但二者还是有区别的。
我们要为类建立它们各自需要的接口，不要试图创建一个含有大量接口方法的万能接口给依赖它的类使用。
接口隔离原则 : 用 多个 专门的 接口 , 不使用 单一 的总接口 , 客户端 不应该依赖 它 不需要的 接口 ;
接口隔离原则，ISP，Interface Segregation Principle
接口隔离原则，客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。 判断标准 从接口调用方来判断，是否提供了多余的能力 也就是增加不必要的依赖，而且会造成调用方使用的困惑 与单一职责原则的区别 接口隔离原则跟单一职责原则有点类似，其区别在于， 单一职责原则针对的是模块、类、接口的设计 接口隔离原则更侧重于接口的设计，而且思考的角度不同。 接口隔离原则需要站在调用方来判断，是否被强迫依赖了不需要的接口 如何实现接口隔离原则 首先保证接口职责单一，符合单一职责原则 接口
接口隔离原则（Interface Segregation Principle）的定义是：类间的依赖关系应该建立在最小的接口上。
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。 问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必
随着需求的迭代, 业务越来越复杂, 再修改原有代码, 就很可能引入bug, 需要对整个服务进行测试. 而策略模式就是其中最常用的解决方式.
接口隔离原则（英语：interface-segregation principles， 缩写：ISP）指明客户（client）不应被迫使用对其而言无用的方法或功能。
boolean deleteUserByCellphone(String cellphone);
Interface Segregation Principle：客户端不应该被强迫依赖它不需要的接口。
接口隔离原则表示一个类对另一个类的依赖应该建立在最小的接口上。也就是说，一个接口应该尽可能的小，只包含它需要的方法，而不是包含一些不相关的方法。
接口隔离原则（ISP），The Interface Segregation Principle 定义 客户端不需要强迫依赖那些它们不需要的接口。 类与接口的依赖应该建议在最小的接口上，也就是说接口应该最小化，不能建立在一个庞大的接口之上，接口合理地按功能职能分成更细的几个单一的子接口。 如果一个接口定义并公布过多的方法，会导致所有的实现类必须要实现接口的方法，可能不同的业务场景不需要实现，所以接口隔离的原则就是只实现他们需要的接口。 像spring中的BeanFactory定义了bean的各种最基本的操
笔者作为一个菜鸟，会尝试以简单的代码和容易理解的语句去解释这几种原则的特性和应用场景。
如果有一天,他不在教书了,或者又有了新的职业,那我们还要修改调用该类的代码,更好的做法是将臃肿的接口变更为几个独立的接口
在程序设计领域， SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）是由罗伯特·C·马丁在21世纪早期 引入的记忆术首字母缩略字，指代了面向对象编程和面向对象设计的五个基本原则。
我们可以把这两个定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。
尽管大家都认为SOLID是非常重要的设计原则，并且对每一条原则都耳熟能详，但我发现大部分开发者并没有真正理解。要获得最大收益，就必须理解它们之间的关系，并综合应用所有这些原则。只有把SOLID作为一个整体，才可能构建出坚实(Solid)的软件。遗憾的是，我们看到的书籍和文章都在罗列每个原则，没有把它们作为一个整体来看，甚至提出SOLID原则的Bob大叔也没能讲透彻。因此我尝试介绍一下我的理解。
倒置了什么：面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。依赖倒置，倒置了模块或包的依赖关系（从上层以来下层，转变为下层依赖上层接口），倒置了开发顺序和职责
说到 SOLID 原则，相信有过几年工作经验的朋友都有个大概印象，但就是不知道它具体是什么。甚至有些工作了十几年的朋友，它们对 SOLID 原则的理解也停留在表面。今天我们就来聊聊 SOLID 原则以及它们之间的关系。
设计应用程序的时候，如果一个模块包含多个子模块，那么我们应该小心对该模块做出抽象。设想该模块由一个类实现，我们可以把系统抽象成一个接口。但是在需要添加新模块或者拓展功能时，新模块只包含原系统中的某一些子模块，那么系统就会强制我们实现接口中所以的方法，包括一些不需要的方法。这样一来，这些行为可能就会导致接口代码臃肿，冗余，导致资源的浪费。
设计模式原则是设计设计模式的原则，也就是设计模式应当如何设计所遵守的原则；换句话说，设计模式的设计是基于设计模式原则的。
所以我们需要将其解耦思想为自己所用，从而提升自己编码能力，使自己的代码更加容易维护、扩展。
接口隔离原则（Interface isolation principle，ISP）是指用多个专门的接口，而不是用单一的总接口，客户端不应该依赖它不需要的接口。 这个原则知道我们在设计接口时应当注意以下几点：
其实通俗来理解就是，不要在一个接口里面放很多的方法，这样会显得这个类很臃肿。接口应该尽量细化，一个接口对应一个功能模块，同时接口里面的方法应该尽可能的少，使接口更加灵活轻便。或许有的人认为接口隔离原则和单一职责原则很像，但两个原则还是存在着明显的区别。单一职责原则是在业务逻辑上的划分，注重的是职责。接口隔离原则是基于接口设计考虑。例如一个接口的职责包含10个方法，这10个方法都放在同一接口中，并且提供给多个模块调用，但不同模块需要依赖的方法是不一样的，这时模块为了实现自己的功能就不得不实现一些对其没有意义的方法，这样的设计是不符合接口隔离原则的。接口隔离原则要求"尽量使用多个专门的接口"专门提供给不同的模块。
这个原则本身与单一职责原则关系十分紧密，它意味着当你在定义你的抽象层代码时，不应当在客户端代码在实现抽象逻辑时，暴露一些客户端代码不需要使用或者关心的方法。
软件设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
SOLID是五个常见的面向对象设计原则的缩写，其目的是帮助开发者设计易于维护和扩展的软件系统
六原则一法则是指开闭原则、里氏替换原则、依赖倒置原则、单一职责原则、接口隔离原则、合成复用原则、迪米特法则。
开闭原则指导我们，当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。这里的“应该尽量”4个字说明OCP原则并不是说绝对不可以修改原始类的，当有这种修改的需求时，应该尽早地重构，而不是通过继承等方式添加新的实现，这会导致类型的膨胀以及历史遗留代码的冗余
大家好，我是光城，很久没发文章了，主要是工作上比较忙，希望大家理解，期待大家留言区交流，本节分享SOLID原则与抽象三原则。
在软件开发中，设计原则是非常重要的，它们可以帮助我们编写出高质量、易于维护和扩展的代码。本文将介绍6个常见的设计原则，包括单一职责原则、里氏替换原则、接口隔离原则、依赖倒置原则、迪米特原则和开闭原则。
软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的，我们要为不可预料的变化做好准备，这本身是一件非常痛苦的事情，但好在有大师们已经给我们提出了非常好的六大设计原则和23种设计模式来“封装”未来的变化。
我的女朋友小肉是一名光荣的辅导班老师，说来惭愧，我上初中那会儿最讨厌辅导班老师了，每天上学都这么累了，晚上还得去见辅导班老师，神烦，奈何目前的教育机制下，很多家长认为辅导班是提高成绩比较靠谱的方式，导致这个行业市场很大。
在实际的业务开发中往往会因为初期的设计不合理，使得接口中定义了众多方法，而这些接口在实现类中又并不需要全部实现。这样的接口定义是不利于扩展的，也将对后期的维护带来困扰，我们将通过示例来演示符合接口隔离原则带来的好处。
接口是一种特殊的抽象类，它用来定义一组行为规范，不同于抽象类的是，接口只能定义方法，并且只能定义抽象方法。类用继承来描述子类和父类之间的关系，而接口用实现来描述接口和类的关系。
作为开发人员，或多或少都会熟悉或了解一些设计模式，如单例模式、工厂模式、观察者模式等等。但并非都能理解这些设计模式背后的本质，从而可能会导致对模式单纯的套用或滥用的情况出现。不要为了模式而模式，要明白使用模式的目的，要正确理解模式背后的设计原理，要理解背后的基本设计原则。
一个类或模块只负责完成一个独立的功能或任务，就能帮助我们将复杂的系统拆分成独立的组件，使得每个组件都具有清晰的责任和功能。
1.外观模式（Facade) 一层一层向上封装，灵活性会降低，功能完成度高，和python的模块比较像，但对于封装好了的类，将会变得很简单,简洁。 2.六大设计原则 单一职责原则 (Single Responsibility Principle) 一个类直负责一项职责（操作）。一个类，只应该有一个引起它变化的原因。 里氏替换原则 (Liskov Substitution Principle) 所有引用基类的地方必须能透明地使用其子类的对象。（子类父类） 子类可以实现父类的抽象方法，但不能
里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。需要注意以下几点：
学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助我们设计出更加优雅的代码结构。
转载自https://www.cnblogs.com/HigginCui/p/6195318.html
无论是软件系统设计，还是代码实现，遵循有效和明确的设计原则，都利于系统软件灵活可靠，安全快速的落地，更重要的是能灵活地应对需求，简化系统扩展和维护，避免无效的加班。本文主要讨论面向对象软件开发中最流行的设计原则- SOLID，它是五个设计原则为了方便记忆而组成的首字母缩写：
1. Clients should not be forced to depend upon interfaces that they don't use.（客户端不应该依赖它不需要的接口。）
不知道大家是否看过这样一个短视频——“姐姐去找她的弟弟，因为她的弟弟想要当rapper而荒废了学业，姐姐多番劝导也没有用，最后一怒一下，把弟弟的rapper发型剃了。没有了帅气的rapper发型，弟弟也放弃了当rapper的想法了。”
单一职责原则定义：一个对象应该只包含单一的职责，并且该职责被完整地封装在一个类中。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
