第 4 章接口隔离原则，前面都写英文名的，这章不写了，有点破坏美感，所以我网上查了一下，叫 Interface Segregation Principle(ISP)。
关键点就是接口要尽量简单，方法尽量少。和单一职责不同，单一职责说的是一个类或接口负责一个职责，但一个职责可能包括许多方法。
比如项目经理 PM 接口，作为 PM 既要激励成员，又要向上层汇报，即要跟踪进度，还要控制预算等等，这些可以看作不同的职责，分成更细的接口，而不是都用一个统一的 PM，因为可能有些小项目有些职责不需要负责。
但就是激励成员这一个职责，可能有组织团建方法，发红包方法，和成员谈心方法、惩罚方法等等，从单一职责看没问题，从接口隔离可能就有问题。可以正向激励方法放一个接口，负向的放另一个接口，因为有的项目经理只惩罚不奖励，有的项目经理只奖励不惩罚，有的项目经理两者都有，这样接口拆开，实现更为灵活。
第 5 章迪米特法则，Law of Demeter(LoD)，也叫 最少知识原则，Least Knowledge Principle(LKP)，说是来源于一个叫做“迪米特”的项目。
- 两个类没有直接联系，那就不要调用，书中举的例子看着就别扭，因为它是故意造了个错误的写法。A 类用到了 B 类，B 类需要用到 C 类，错误的例子是 A 类中构建了 C 类，传给 B 类。不清楚项目中是否会不经意用了这种错误的方法，但现在看是不会这么去写的
- 即便是有耦合关系的朋友，比如 A 和 B，也不要过于紧密，A 调用 B 的方法越多耦合越高，可能 B 的修改越容易引起 A 的修改，将 A 要调用的逻辑在 B 中封装，暴露的方法变少
- 如果一个方法放在自己的类里和放在其它类里都可以，如果放在本类中不增加类间关系，不产生负面影响，就放在自己的类里，倒也好理解，不过暂时没想出场景
