《实现模式》读书思考（1）

1. 类是昂贵的设计元素，因此减少类的数量便是对系统的改进。

2. override其实是一种设计上的屈服，abstract除外。换句话说，virtual实际上就是一种屈服。

3. 尽量用一个单词为基类命名，这样比较简单。比较容易为子类命名。

4. 表达“这是我要完成的任务，除此之外的细节不归我操心”，这个是interface的使用范畴。如果无权改变实现，大量使用interface会严重拖累日后的设计调整。

5. 如果程序只是小范围使用，让设计元素的可见性略高还不是什么问题。但如果把接口发布给很多人使用，那么最好是准确地指定希望让他们看到哪些操作。

6. 抽象类和接口的选择还有一点就是要取决于抽象的变化。

7. 用新接口继承原有接口来发布接口新的版本。

8. 如果你面对一个可能只是暂时静止的情景，随后的操作或者查询都针对这个情景来进行，那么函数式的风格比较合适。

9. 通过只提供get方法来构造一个不可变对象。也成值对象。

10. 多态的优美之处实际上是在于它给系统开启了变化的机会。

11. 如果对象的逻辑完全由类来决定，阅读者只要看类的方法名就会知道发生什么。一旦各个实例有不同的行为，就需要在运行时观察或分析数据流才能理解一个对象的行为。

12. 要实现实例特有的行为,if-else是最简单的方式。这样的好处在于所有的逻辑都在同一个类里。缺点是除了修改对象本身的代码之外，没有其他的办法能够修改它的逻辑。

13. 程序中的执行路径越多，整个程序正确无误的可能性就越低。也就是说，条件语句的增加会降低可靠性。

14. 用条件语句来分发，但是要保证条件语句只有最简单的逻辑，而把主要代码放到子类中。

15. 另一种实现特定实例的办法是把部分工作委派给不同类型的对象。不变的逻辑放在发起委派的类中，变化的逻辑交给被委派的对象。

16. 尽管库类相当常见，但它不适合大量使用，把所有逻辑都放在静态方法中就错过了对象的最大好处。