接口隔离原则（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个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束不使用的方法不要访问，按照单一职责原则是允许的，按照接口隔离原则是不允许的。
这两个定义可以归纳为一个意思：建立单一接口，不要建立臃肿庞大的接口。也就是说，接口尽量细化，同时接口中的方法尽量少。
从功能上来看，接口隔离原则和单一职责原则都是为了提高类的内聚, 降低类之间的耦合, 体现了封装的思想。但二者还是有区别的。
我们要为类建立它们各自需要的接口，不要试图创建一个含有大量接口方法的万能接口给依赖它的类使用。
随着需求的迭代, 业务越来越复杂, 再修改原有代码, 就很可能引入bug, 需要对整个服务进行测试. 而策略模式就是其中最常用的解决方式.
接口隔离原则（Interface Segregation Principle）的定义是：类间的依赖关系应该建立在最小的接口上。
接口隔离原则（ISP），The Interface Segregation Principle 定义 客户端不需要强迫依赖那些它们不需要的接口。 类与接口的依赖应该建议在最小的接口上，也就是说接口应该最小化，不能建立在一个庞大的接口之上，接口合理地按功能职能分成更细的几个单一的子接口。 如果一个接口定义并公布过多的方法，会导致所有的实现类必须要实现接口的方法，可能不同的业务场景不需要实现，所以接口隔离的原则就是只实现他们需要的接口。 像spring中的BeanFactory定义了bean的各种最基本的操
接口隔离原则，客户端不应该被强迫依赖它不需要的接口。其中的“客户端”，可以理解为接口的调用者或者使用者。 判断标准 从接口调用方来判断，是否提供了多余的能力 也就是增加不必要的依赖，而且会造成调用方使用的困惑 与单一职责原则的区别 接口隔离原则跟单一职责原则有点类似，其区别在于， 单一职责原则针对的是模块、类、接口的设计 接口隔离原则更侧重于接口的设计，而且思考的角度不同。 接口隔离原则需要站在调用方来判断，是否被强迫依赖了不需要的接口 如何实现接口隔离原则 首先保证接口职责单一，符合单一职责原则 接口
接口隔离原则，ISP，Interface Segregation Principle
接口隔离原则 : 用 多个 专门的 接口 , 不使用 单一 的总接口 , 客户端 不应该依赖 它 不需要的 接口 ;
设计模式原则是设计设计模式的原则，也就是设计模式应当如何设计所遵守的原则；换句话说，设计模式的设计是基于设计模式原则的。
说到 SOLID 原则，相信有过几年工作经验的朋友都有个大概印象，但就是不知道它具体是什么。甚至有些工作了十几年的朋友，它们对 SOLID 原则的理解也停留在表面。今天我们就来聊聊 SOLID 原则以及它们之间的关系。
笔者作为一个菜鸟，会尝试以简单的代码和容易理解的语句去解释这几种原则的特性和应用场景。
boolean deleteUserByCellphone(String cellphone);
在程序设计领域， SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）是由罗伯特·C·马丁在21世纪早期 引入的记忆术首字母缩略字，指代了面向对象编程和面向对象设计的五个基本原则。
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。 问题由来：类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必
Interface Segregation Principle：客户端不应该被强迫依赖它不需要的接口。
倒置了什么：面向过程的开发，上层调用下层，上层依赖于下层，当下层剧烈变动时上层也要跟着变动，这就会导致模块的复用性降低而且大大提高了开发的成本。依赖倒置，倒置了模块或包的依赖关系（从上层以来下层，转变为下层依赖上层接口），倒置了开发顺序和职责
尽管大家都认为SOLID是非常重要的设计原则，并且对每一条原则都耳熟能详，但我发现大部分开发者并没有真正理解。要获得最大收益，就必须理解它们之间的关系，并综合应用所有这些原则。只有把SOLID作为一个整体，才可能构建出坚实(Solid)的软件。遗憾的是，我们看到的书籍和文章都在罗列每个原则，没有把它们作为一个整体来看，甚至提出SOLID原则的Bob大叔也没能讲透彻。因此我尝试介绍一下我的理解。
接口隔离原则（英语：interface-segregation principles， 缩写：ISP）指明客户（client）不应被迫使用对其而言无用的方法或功能。
软件设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。
大家好，我是光城，很久没发文章了，主要是工作上比较忙，希望大家理解，期待大家留言区交流，本节分享SOLID原则与抽象三原则。
面向对象设计的六大原则 : 单一职责原则, 里氏替换原则, 依赖倒置原则, 接口隔离原则, 迪米特法则, 开闭原则;
在Spring Boot中实现解耦、隔离和异步的原则，能够提升应用程序的可维护性、可扩展性和性能。下面我会先介绍这三个原则的基本概念和意义，然后通过实战示例展示如何在Spring Boot应用中应用这些原则。
如果有一天,他不在教书了,或者又有了新的职业,那我们还要修改调用该类的代码,更好的做法是将臃肿的接口变更为几个独立的接口
接口隔离原则表示一个类对另一个类的依赖应该建立在最小的接口上。也就是说，一个接口应该尽可能的小，只包含它需要的方法，而不是包含一些不相关的方法。
常见的软件设计原则分为：单一职责、开闭原则、接口隔离、里式替换、迪米特原则、依赖倒置原则。
所以我们需要将其解耦思想为自己所用，从而提升自己编码能力，使自己的代码更加容易维护、扩展。
这个原则的意思是：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。
无论是软件系统设计，还是代码实现，遵循有效和明确的设计原则，都利于系统软件灵活可靠，安全快速的落地，更重要的是能灵活地应对需求，简化系统扩展和维护，避免无效的加班。本文主要讨论面向对象软件开发中最流行的设计原则- SOLID，它是五个设计原则为了方便记忆而组成的首字母缩写：
设计应用程序的时候，如果一个模块包含多个子模块，那么我们应该小心对该模块做出抽象。设想该模块由一个类实现，我们可以把系统抽象成一个接口。但是在需要添加新模块或者拓展功能时，新模块只包含原系统中的某一些子模块，那么系统就会强制我们实现接口中所以的方法，包括一些不需要的方法。这样一来，这些行为可能就会导致接口代码臃肿，冗余，导致资源的浪费。
六原则一法则是指开闭原则、里氏替换原则、依赖倒置原则、单一职责原则、接口隔离原则、合成复用原则、迪米特法则。
原则一：若 o1 是 C1 的一个实例化对象， o2 是 C2 的一个实例化对象，如果在使用 C1 的程序中将o1 替换为 o2 而程序行为没有发生变化，那么 C2 应该是 C1 的子类。
在架构之路上和代码设计上，我们一定要明白上面的几个原则，在这几个原则的指导下，才能设计出优良的架构，才能经得住撕逼。
SOLID是五个常见的面向对象设计原则的缩写，其目的是帮助开发者设计易于维护和扩展的软件系统
学习设计原则，学习设计模式的基础。在实际开发过程中，并不是一定要求所有代码都遵循设计原则，我们要考虑人力、时间、成本、质量，不是刻意追求完美，要在适当的场景遵循设计原则，体现的是一种平衡取舍，帮助我们设计出更加优雅的代码结构。
设计模式介绍 设计模式(Design Patterns): 一套被反复使用,多数人知晓,经过分类编目,代码设计的总结 使用设计模式是为了可重用代码,让代码更容易理解,保证代码可靠性 项目中合理运用设计模式可以完美的解决很多问题,每种模式都有相应的原理与之对应, 每个模式描述了一个在我们周围不断重复发生的问题,以及该问题的核心解决方案 设计模式分类 总体来说,设计模式分为三大类: 创建型模式(5种): 工厂方法模式 抽象工厂模式 单例模式 建造者模式 原型模式 结构型模式(7种): 适配器模式 装饰器
所谓封装（Encapsulation），也就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。封装是面向对象的特征之一，是对象和类概念的主要特性。简单的说，一个类就是一个封装了数据以及操作这些数据的代码的逻辑实体。在一个对象内部，某些代码或某些数据可以是私有的，不能被外界访问。通过这种方式，对象对内部数据提供了不同级别的保护，以防止程序中无关的部分意外的改变或错误的使用了对象的私有部分。
我们可以把这两个定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。
1.开闭原则（Open Close Principle） 定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。 开放-封闭原则的意思就是说，你设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。这个原则有两个特性，一个是说“对于扩展是开放的”，另一个是说“对于更改是封闭的”。面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。这就是“开放-封闭原则”的精神所在 比如，刚开始需求只是写加法程序，很快在client类中完成后，此时变化没有发生，需求让再添加一个减法功能，此时会发现增加功能需要修改原来这个类，这就违背了开放-封闭原则，于是你就应该考虑重构程序，增加一个抽象的运算类，通过一些面向对象的手段，如继承、动态等来隔离具体加法、减法与client耦合，需求依然可以满足，还能应对变化。此时需求要添加乘除法功能，就不需要再去更改client及加减法类，而是增加乘法和除法子类即可。 绝对的修改关闭是不可能的，无论模块是多么的‘封闭‘，都会存在一些无法对之封闭的变化，既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。在我们最初编写代码时，假设变化不会发生，当变化发生时，我们就创建抽象来隔离以后发生同类的变化。 我们希望的是在开发工作展开不久就知道可能发生的变化，查明可能发生的变化所等待的时候越长，要创建正确的抽象就越困难。开放-封闭原则是面向对象设计的核心所在，遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出现频繁变化的那些部分做出抽象，然而对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意，拒绝不成熟的抽象和抽象本身一样重要。开放-封闭原则，可以保证以前代码的正确性，因为没有修改以前代码，所以可以保证开发人员专注于将设计放在新扩展的代码上。 简单的用一句经典的话来说：过去的事已成历史，是不可修改的，因为时光不可倒流，但现在或明天计划做什么，是可以自己决定(即扩展)的。
作为开发人员，或多或少都会熟悉或了解一些设计模式，如单例模式、工厂模式、观察者模式等等。但并非都能理解这些设计模式背后的本质，从而可能会导致对模式单纯的套用或滥用的情况出现。不要为了模式而模式，要明白使用模式的目的，要正确理解模式背后的设计原理，要理解背后的基本设计原则。
开闭原则指导我们，当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。这里的“应该尽量”4个字说明OCP原则并不是说绝对不可以修改原始类的，当有这种修改的需求时，应该尽早地重构，而不是通过继承等方式添加新的实现，这会导致类型的膨胀以及历史遗留代码的冗余
说到数据库，以前我老师有一句很经典的话。你可以不会写SQL，但是一定不能不知道ACID。
单一职责原则（Single Responsibility Principle）：类应该仅具有一种单一功能，并且该功能应该由这个类完全封装起来。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化就可能抑制或者削弱这个类完成其他职责的能力。
软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的，我们要为不可预料的变化做好准备，这本身是一件非常痛苦的事情，但好在有大师们已经给我们提出了非常好的六大设计原则和23种设计模式来“封装”未来的变化。
接口隔离原则：（ISP ：Interface Segregation Principle）。
迪米特法则来自于1987年美国东北大学一个名为“Demeter”的研究项目。 迪米特法则要求一个软件实体应当尽可能少地与其他实体发生相互作用 应用迪米特法则可降低系统的耦合度，使类与类之间保持松散的耦合关系。 迪米特法则要求在设计系统时，应当尽量减少对象之间的交互 。如果两个对象之间不必彼此直接通信，那么这两个对象就不应该发生任何直接的相互作用 。如果其中一个对象需要调用另一个对象的方法，可以通过“第三者”转发这个调用 * 通过引入一个合理的“第三者”(中间类)来降低现有对象之间的耦合度。
一个类或模块只负责完成一个独立的功能或任务，就能帮助我们将复杂的系统拆分成独立的组件，使得每个组件都具有清晰的责任和功能。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
对象存储
云直播
