18 | 理论四：接口隔离原则有哪三种应用？原则中的“接口”该如何理解？

老师可以每次课对上一次课的思考题做下解答吗

为什么觉得老师说的，对于接口的三种理解，第一种理解和第三种理解说的是同一件事情~

Java8 Interface有default method 这样新加的method不需要所有相关类再实现了。但对这些类而言 不就违背了接口隔离原则么？

接口隔离原则，如果是从API接口角度，我觉得应该是从实现方来看，比如我实现某个接口，我只想实现这个接口的部分功能，其他功能用不上，那么就要考虑这个接口是否符合隔离原则，能否进行粒度拆分，这样也更灵活，针对函数来讲，应该就是从调用者的角度来看，比如我只想统计商品总量，而其他的统计结果，你不要给我，其实我们现在做的项目，都是前后端分离的，让前端调用，很多时候，我们项目中，会有一个很大的用户接口，包括一大堆信息，但是实际上前端只想获取用户的姓名或则手机号。但是你却给我了一大堆，后端也是为了图方便，只写一个接口，反正所有用户的信息全部塞到里面，那从这个角度，是不是也不符合接口隔离原则呢

Java.util.concurrent.atomic包下提供了机器底层级别实现的多线程环境下原子操作，相比自己实现类似的功能更加高效。 AtomicInteger提供了 intValue() 获取当前值 incrementAndGet() 相当于++i getAndIncrement相当于i++ 从getAndIncrement实现“原子”操作的角度上来说，原子级别的给整数加一，返回未加一之前的值。它的职责是明确的，是符合单一职责的。 从接口隔离原则上看，也是符合的，因为AtomicInteger封装了原子级别的整数操作。 补充： 多线程环境下如果需要计数的话不需旧的值时，推荐使用LongAdder或者LongAccumulator（CoreJava上说更加高效，但我对比了AtomicLong和LongAdder，没感觉效率上有提高，可能是例子写的不够准确。测试代码见 https://github.com/gdhucoder/Algorithms4/tree/master/designpattern/u18 希望和小伙伴们一起讨论）

设计模式_18 纯理论分析，这么设计是不符合“接口隔离”原则的，毕竟，get是一个操作，increment是另一个操作。 结合具体场景，Atomic类的设计目的是保证操作的原子性，专门看了一下AtomicInteger的源码，发现没有单独的 increment 方法，然后思考了一下线程同步时的问题，场景需要保证 get 与 increment 中间不插入其他操作，否则函数的正确性无法保证，从场景的角度，它又是符合原则的。

老师此题大有深意，我们可以从此思考题中方法的设计来深化对单一职责和接口隔离的理解： 接口隔离，强调的是调用方，是否只使用了接口中的部分功能？若是，则违反接口隔离，应当细粒度拆分接口，从这个例子看，调用方诉求与方法名完全一致，通过方法内部封装两个操作，实现原子性，达成了调用方的最终目的，不多不少。 单一职责，不强调是否为调用方，只要能某一角度观察出，一个模块/类/方法，负责了多于一件事情，就可判定其破坏了单一职责，基于此经典理论，不假以深层次思考的角度出发，从方法本身的命名（做两件事）就可断定，它一定是破坏了单一职责的，应该拆分为两个操作。 但我们可以结合老师说的，判定职责是否单一，要懂得结合业务场景，业务需求，此方法，其实就是要通过JDK提供的CAS乐观自选锁（方法最终依赖硬件指令集原语，Compare And Swap）从“原语”这一词的含义看，其实也是同时、原子性地做了一件“完整”的事情，因此，考虑这一点，是可以判定它符合单一职责的。 而这其实正是单一职责判定结果，往往见仁见智的原因：基于不同的角度，不同的立场，不同的业务理解，往往可以得到不同的判定结果，但不必纠结，判定过程中用到的思想才是精髓。

总结成思维导图了，链接 https://blog.csdn.net/dingshuo168/article/details/103531805

接口隔离原则：我只要我想要的，不想要的别给我

思考题： 先看是否符合单一职责原则，这个函数的功能是加1然后返回之前的值，做了两件事，是不符合单一职责原则的！ 但是却符合接口隔离原则，从调用者的角度来看的话，因为这个类是Atomic类，需要的所有操作都是原子的，所以为了满足调用者需要原子性的完成加一返回的操作，提供一个这样的接口是必要的，满足接口隔离原则。