15丨软件设计的接口隔离原则：如何对类的调用者隐藏类的公有方法？

慧哥，请教下，接口隔离原则，和上一节说的单一职责原则是否有点“冲突”。需要进行接口隔离的类，感觉必然是有多个引起变化的原因，如果这样，单一职责运用下，设计成两个类，就不需要接口隔离了。既然有这两个原则，问题出在哪里？

设计一个类大致和现实中设计一个职能部门差不多，需要考虑两方面需求：         （一）是优化资源调度、使用效率，提高效率，减少重复劳动。         （二）是便于对外提供功能服务，使功能的使用者能够清晰明确的使用到自己所需的功能，而不必纠缠其他不必要的功能。         为了满足第一条，软件设计上要注意代码的“高内聚”，就是将关联密切的功能放在一个类里面，以提高重用性；现实世界中，政府部门和企业内部需要将功能类似的组织合并，具体可以参照建国以来国务院下属部委的调整，当然这些调整的原因是多方面的，但其中有一些部门的合并确实考虑到了第一条，例如卫生健康委员会的设立和农业农村部的设立。         为了满足第二条，我们国家设置了“一个单位，两块牌子”的机构，例如今年频频亮剑的“中纪委国家监委”；在软件设计上，功能的调用者不直接通过依赖实现类的方式完成功能调用，而是依赖功能清晰，调用明确的接口，而多个功能接口可以由一个功能内聚的类提供实现。

老师 Iterable 为什么是属于接口隔离原则这个没太理解 能再详细讲一下吗

想起了,宝玉所说的道,术和器的概念 感觉"道"就是面向对象的的几个特性,封装,继承和多态 "术"就是以道为根基,为理论依据 发展而来的 各种模式, 用来解决软件开发中中的各种违背软件设计原则的方法. 所有的变换皆是"道"而引起的,没有道,就没有术比如少了多态这个道,各种设计模式将会减少大半甚至消亡.

问一下老师 最后的小结 如果使用者 调用CacheManageable这个接口的reBuild 不还是被访问到了吗

老师能加个代码么？自动锁门那块

接口隔离和单一职责是一体两面的，一个面向调用者，一个面向实现者

多思多想，代码设计里面有很多细节，建筑领域设计师与施工人员跟架构师跟码工有很多相似的工作内容，李老师在架构领域真的内功深厚，如果从哲学角度再进行一步抽象，那就是大师了

接口隔离原则看上去比较简单，但是比较依赖 Java 语言 interface 多重继承的特性。 试着写一下 TimerDoor 的代码，适配器模式： class DoorTimerAdapter implements TimerClient { Door door; Timer timer; int timeout; public DoorTimerAdapter(Door door, Timer timer, int timeout) { this.door = door; this.timer = timer; this.timeout = timeout; timer.register(timeout, this); } public void timeout() { door.lock(); } } 多重继承： class Timer { public Timer() { } void register(int timeout, TimerClient client) { } } interface TimerClient { public void timeout(); } class Door { public Door() { } void lock() { } void unlock() { } boolean isDoorOpen() { return false; } } class TimedDoor extends Door implements TimerClient { private int timeout; private Timer timer; public TimedDoor() { this.timer = new Timer(); this.timeout = 10; timer.register(timeout, this); } public void timeout() { lock(); } } 不知道写的对不对，抛砖引玉。 两次都把 timer.register() 写在了构造函数里面，有点别扭。

感觉go中的无侵入式的接口方式在这方面更显得自然和简单