深入浅出设计模式（影印版）读书笔记

读书笔记--Head First Design Patterns

昨天刚刚把深入浅出设计模式这本书看完，可以说，这是我看过的最好的一本寓教于乐的书。正如作者说的那样，设计模式在软件行业中应用及其广泛，许多已经出去工作的学长都把设计模式看的极其重要。

由于是读了第一遍，而且是英文版，所以可能有很多没有掌握的地方。光理论肯定是不行的，设计模式这东西需要靠实践才能慢慢成为大脑中的一部分，我想以后这本书肯定要读上很多遍。为了加深一点印象，在这里列举一下书中最简单的一个部分--面向对象的设计原则。

原则1：Encapsulate what varies(封装变化)

Identify the aspects of your application that vary and separate them from what stays the same(发现系统中变化的部分并把其与系统中不变的部分相分离)
这个原则很简单，把变的部分和不变的部分进行隔离，针对变化的需要对其进行封装，当在后续对系统进行增加和拓展功能时，只需要修改这些变化的部分，而无需修改那些不变的部分，这样使得系统更加灵活并且能避免出现未知错误。

原则2：Program to an interface,not an implementation(针对接口而不是针对实现编程)

在策略模式中，如果针对特定的鸭子进行编程，当系统不断增加鸭子的时候代码要进行极大的变化，这里所说的实现相当于C++中的子类，而接口相当于C++中的抽象类，很显然如果改变抽象类中的方法，子类继承后无需修改就可以使用，子类甚至不需要知道具体实现细节，只知道调用接口也就是抽象类实现自己的方法即可。

原则3：Favor composition over inheritance(相比继承而言更倾向于使用组合)

面向对象中一个很重要的思想就是继承，但是在设计模式中则不提倡过多使用继承，这一点在策略模式中能体现出来。如果通过继承子类实现了某些不属于自己的方法，那明显是不合逻辑的，并且使用过多继承会让程序变得不灵活。如果使用组合，程序不仅能灵活应用而且能在运行时动态修改行为状态等。从策略模式中来看，这里用到的最多的是接口，虽然算不上继承，但放到C++中就算是具体类继承抽象类了，这一点需要注意。

原则4：Strive for loosely coupled designs between objects that interact(在交互的对象中进行低耦合设计)

很显然，对于纠缠在一起的程序模块，如果不是低耦合，当一个模块要进行修改，那另一个模块也要进行修改，这样不断循环下去结果可想而知。低耦合也就是尽量减少对象之间的联系，这样保持系统更加灵活以应对各种变化。试想一个最坏的情况，两个系统共享一些值，就好像两个进程共享一块资源，这样的系统改动起来实在太费事了。

原则5:Classes should be open for extension,but closed for modification(类应该对拓展开放而对修改关闭)

翻译起来也许不太懂，其实道理很简单，一个类应该具有易拓展性质，对于那些调用该类的新操作来说，类无须修改就能加以应用。对于修改来说，由于该类已经应用了一段时间，正确性得到了验证，代码不应该被随意修改，否则会出现不可估计的错误。
在装饰者模式中，这个原则得到了具体的展示。但是作者也提到，如果把该原则用于任何方面是无意义的，这可能会导致复杂的代码，所以需要进行权衡。我认为和拓展性相比，封装性才是类更重要的特性，所以宁可关闭也不需要被拓展。

原则6：Depend upon abstractions.Do not depend upon concrete classed(依赖抽象类而不是具体类)

在工厂模式中，比萨店依赖于比萨的种类，当添加一种比萨的时候就需要对其进行修改，这正是依赖实体类的体现。而应用该原则后，比萨店只需要依赖比萨这个抽象类即可，这样代码就无需进行多次修改。总而言之，高层类不需要依赖低层类。

原则7：Principle of Least Knowledge- talk only to your immediate friends(最小知道原则，只和直接朋友交流)

这个原则和之前的原则4有类似的地方，也就是要求低耦合，在进行类的交互时需要对类进行改变，如果涉及到的类很多，对一个类进行修改时会影响到其他类。在Facade模式中，用户想直接交流的并不是具体的类而是整个大类，这正是原则应用之处。

原则8：Don't call us, we'll call you(别叫我们，我们会通知你)

听起来有点像观察者模式，应用之处在于上层决定下层什么时候加以应用。在模板类模式中，上层的算法正是通过调用下层的具体操作加以实现，而下层无须知道上层是怎么回事。

原则9：A class should have only one reason to change(类只有一个理由加以改变)

该原则让我们让一个类专注于一个职责，而不是把很多职责加到一个类中也不是把一个职责加到若干个类中，也就是人们常说的内聚性。一个类只负责做一件事情，这样就能在很大程度上避免修改，或者引入不必要的问题。

以上就是书中提到的面向对象的原则，很显然，这才是这本书很小的一部分，暂时先写这么多，等下次有时间真想把书中的设计模式一个一个用C++实现一遍。