JavaHead First design pattern 学习感想

设计者模式很重要，不需要我多说。你瞧，程序员几乎人手一本四人组(ErichGamma、Richard Helm、Talph Johnson、John Vlissides)所著的是《JavaHead First design pattern》。打个比喻:信耶稣的人都要读圣经，而信OO的人都要读四人组的《JavaHead First design pattern》，这就是OO的圣经。
这是我看的第一本设计模式方面的书 惊为天书
目前看到的觉得写的最棒的一本技术书籍
作者通过各种方式与读者形成了互动 使读书不再是个枯燥的过程
书上写了23种设计模式中更为常见的14种设计模式
让我做个小小的回顾

1. 设计模式的本质，就是针对具体问题，以某种方式将变化的部分抽取并封装起来，使其独立于其他不变的部分，不对其造成影响。
2. 设计原则一：封装变化。找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起；
3. 设计原则二：针对接口编程，而不是针对实现编程；
4. 设计原则三：多用组合，少用继承；
5. OO基础：抽象，封装，多态，继承
6. OO原则：封装变化；多用组合，少用继承；针对接口编程，不针对实现编程
7. OO模式：在基础和原则基础上构建出来的一系列设计经验，具有可复用，可扩充和可维护三大特性
8. 策略模式定义了算法族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化独立于使用算法的客户
9. 观察者模式定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会收到通知并自动更新
10. 设计原则四：为了交互对象之间的松耦合设计而努力；
11. 设计原则五：对扩展开放，对修改封闭；
12. 装饰者模式：动态地将责任附加到对象上。想要扩展功能时装饰者提供有别于继承的另一种选择；
13. 工厂方法模式：定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个，工厂方法让类把实例化推迟到子类；
14. 依赖倒置原则：要依赖抽象，不要依赖具体类；
15. 代码里减少对具体类的依赖是件“好事”；
16. 不能让高层组件依赖低层组件，而且，不管高层或低层组件，“两者”都应该依赖于抽象（所谓高层组件，是由其他低层组件定义其行为的类）
17. 尽量遵循的指导方针
    1）变量不可以持有具体类的引用
    2）不要让类派生自具体类
    3）不要覆盖基类中已经实现的方法
18. 抽象工厂模式：提供一个接口，用于创建一组相关的或依赖的对象家族，而不需要明确指定具体类；
19. 工厂方法潜伏在抽象工厂内；
20. 抽象工厂的另一个优点在于可以把一群相关产品集合起来；
21. 工厂方法通过继承，抽象工厂通过对象组合；
22. 单例模式：确保一个类只有一个实例，并提供一个全局访问点；
23. 单例模式常被用于管理共享的资源；

24. 编写线程安全的单例有三种方式
    1）synchronized getInstance()方法，不是很好的方案，容易产生性能瓶颈，尽量别用；
    2）用static变量预初始化，JVM加载类的时候就会马上创建实例，适用于创建成本不高的场景，一般可用；
    3）double-checked locking，稍复杂，示例：
    public static Singleton getInstance() {
    if (instance == null) {
    synchronized(Singleton.class) {
    if (instance == null) {
    instance = new Singleton();
    }
    }
    }
    return instance;
    }

25. 适配器模式：将一个类的接口，转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。

26. 适配器模式将客户与接口绑定起来；
27. 适配器模式分为两种：类适配器和对象适配器；
28. 负责“包装”的三大模式：Decorator模式赋予新职责；Adapter模式将类接口转换成想要的接口；Facade模式提供子系统的一个简化接口。
29. Facade模式不只是简化了接口，也将客户从组件的子系统中解耦；
30. Facade模式提供了一个统一的接口，用来访问子系统中的一群接口。Facade定义了一个高层接口，让子系统更容易使用（客户和子系统之间避免紧耦合）；
31. 最少知识原则：只和你的密友谈话
32. 设计一个系统时，不管任何对象，你都要注意它所交互的类有哪些，并注意它和这些类是如何交互的，尽量减少对象之间的交互；
33. 模板方法模式：在一个方法中定义了一个算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以在不改版算法结构的情况下，重新定义算法中的某些步骤。
34. 模板方法中，抽象类把握大方向，具体类填充细节；
35. 模板方法中加入钩子函数，它是一种被声明在抽象类中的方法，在只有空的或者默认的实现。钩子的存在，可以让子类对算法的实现产生影响，要不要挂钩，由子类自行决定。
36. 抽象方法是算法中必须实现的部分；钩子是算法中可选的部分。钩子的另一个用法是让子类有机会对模板方法中的某些即将发生或刚刚发生的步骤作出反应。总的说来，钩子可以让子类有能力为抽象类做一些决定；
37. 好莱坞原则：别调用我们，我们会调用你。它告诉我们，将决策权放在高层模块中，以便决定如何以及何时调用低层模块；
38. 策略模式和模板方法模式的对比：策略模式定义了一组算法族，该算法族中的算法可以在运行时替换；模板方法模式则定义了一个框架，只是将某些步骤推迟到子类；
39. 迭代器模式：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部表示；
40. 单一职责原则：一个类应该只有一个引起变化的原因。
41. 对象范式
    1）程序是由对象组成的；
    2）对象之间互相发送消息，协作完成任务。
42. 组合模式：允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合；
43. 状态模式：允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它的类；
44. 策略模式和状态模式有相同类图，但是它们的意图不同。前者用行为或算法来配置Context类；后者允许Context随状态改变而改变行为。
45. 代理模式：为另一个对象提供一个替身或占位符以控制对这个对象的访问。
46. 使用代理模式创建代表对象，让代表对象控制某对象的访问，被代理的对象可以是远程的对象，创建开销大的对象或者需要安全控制的对象。
47. 代理分类：远程代理控制访问远程对象；虚拟代理控制访问创建开销大的资源；保护代理基于权限控制对资源的访问。
48. 模式通常被一起使用，并被组合在同一个设计解决方案中，称为复合模式。复合模式在一个解决方案中结合两个或多个模式，以解决一般或重复发生的问题。
49. 复合模式：结合两个或以上的模式，组成一个解决方案，解决一再发生的一般性问题。
50. 模式是在某情景（context）下，针对某问题的某种解决方案。
51. If you find yourself in a context with a problem that has a goal that is affected by a set of constraints, then you can apply a design that resolves the goal and constraints and leads to a solution.
52. 有用的设计模式在目标和约束上取得某种平衡；
53. 模式的一种分类方式：类模式和对象模式
54. 类模式描述类之间的关系如何通过继承定义。类模式的关系是在编译时建立的；
55. 对象模式描述对象之间的关系，而且主要是利用组合定义。对象模式的关系通常在运行时建立，而且更加动态，更有弹性；
56. KISS原则（keep it simple stupid）：尽可能用简单的方式解决问题，一开始要遵循设计原则，建立最简单的代码以完成工作。在这个过程中，看到有需要模式的地方，就使用模式。
57. 反模式：告诉你如何采用一个不好的解决方案解决一个问题。

中英文双版书籍下载地址:http://download.csdn.net/download/yw59792649/10214835