阅读感悟
暂略
摘录笔记
《大话设计模式》
程杰
225个笔记
前言
- [插图]本书希望能给渴望了解OO世界的初学者、困惑于僵硬、脆弱、无法复用的代码编程体验者、一直打着OO编程的旗号，做着过程式开发的基于对象的编程实践者一些好的建议和提示。
本书起因
- 技术课的教学同样如此，除非学生是抱着极大的学习动机来参与其中，否则照本宣科的教学、枯燥乏味的讲解，学生一定会被庞杂的概念和复杂的逻辑搅晕了头脑，致使效果大打折扣。
本书读者
- GoF的《设计模式》好比是世界顶级足球射门集锦，《重构》、《敏捷软件开发》、《设计模式解析》好比是一场场最精彩的足球比赛。
- 可是我并不只是想做一个球迷（软件使用者），而是更希望自己能成为一个足球运动员（软件设计编程者），能够亲自上场比赛，并且最终能成为球星（软件架构师）
- 本书显然不是培养足球明星（软件架构师）的俱乐部，而是训练足球基本功的学校，培训的是初学足球的小球员（面向对象的程序员），本书希望的是读者阅读后可以打好面向对象的基础，从而更加容易并深入的去理解和感受GoF的《设计模式》以及其他大师作品的魅力。
本书研读方法
- 本书源代码下载地址：http://www.cnblogs.com/Files/cj723/BigTalkDesignPattenSourceCode.rar也可到清华大学出版社网站（www.tup.com.cn）查找并下载本书源代码。
- 我的电子邮箱是[email protected]，博客是http://cj723.cnblogs.com/。
关于本书学习的疑问解答
- 设计模式有四境界：1．没学前是一点不懂，根本想不到用设计模式，设计的代码很糟糕；2．学了几个模式后，很开心，于是到处想着要用自己学过的模式，于是时常造成误用模式而不自知；3．学完全部模式时，感觉诸多模式极其相似，无法分清模式之间的差异，有困惑，但深知误用之害，应用之时有所犹豫；4．灵活应用模式，甚至不应用具体的某种模式也能设计出非常优秀的代码，以达到无剑胜有剑的境界。
不是一个人在战斗
- 本书起源于本人在“博客园”网站的博客http://cj723.cnblogs.com/中的一个连载文章《小菜编程成长记》。
- 写作过程中，本人还参考了http://www.dofactory.com/关于23个设计模式的讲解，并引用了他们的结构图和基本代码
1.5 活字印刷，面向对象
- “第一，要改，只需更改要改之字，此为可维护；第二，这些字并非用完这次就无用，完全可以在后来的印刷中重复使用，此乃可复用；第三，此诗若要加字，只需另刻字加入即可，这是可扩展；第四，字的排列其实可能是竖排可能是横排，此时只需将活字移动就可做到满足排列需求，此是灵活性好。”
1.6 面向对象的好处
- 是呀是呀，你说得没错，中国古代的四大发明，另三种应该都是科技的进步，伟大的创造或发现。而唯有活字印刷，实在是思想的成功，面向对象的胜利。
1.11 UML类图
- 类图分三层，第一层显示类的名称，如果是抽象类，则就用斜体显示。第二层是类的特性，通常就是字段和属性。第三层是类的操作，通常是方法或行为。注意前面的符号，‘+’表示public，‘-’表示private，‘#’表示protected。”
- 它表示一个接口图，与类图的区别主要是顶端有\<\<interface\>\>显示。第一行是接口名称，第二行是接口方法
- 接口还有另一种表示方法，俗称棒棒糖表示法
- 继承关系用空心三角形+实线来表示。”
- 实现接口用空心三角形+虚线来表示
- 当一个类‘知道’另一个类时，可以用关联（association）。
- 聚合表示一种弱的‘拥有’关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分[DPE]（DPE表示此句摘自《设计模式》（第2版）
- 聚合关系用空心的菱形+实线箭头来表示
- 合成（Composition，也有翻译成‘组合’的）是一种强的‘拥有’关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样[DPE]。
- 合成关系用实心的菱形+实线箭头来表示
- 依赖关系（Dependency），用虚线箭头来表示。”
2.3 简单工厂实现
- 面向对象的编程，并不是类越多越好，类的划分是为了封装，但分类的基础是抽象，具有相同属性和功能的对象的抽象集合才是类
2.4 策略模式
- 策略模式定义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户
- 封装变化点是我们面向对象的一种很重要的思维方式
2.6 策略与简单工厂结合
- 你的意思是说，简单工厂模式我需要让客户端认识两个类， CashSuper和CashFactory，而策略模式与简单工厂结合的用法，客户端就只需要认识一个类CashContext就可以了。耦合更加降低。”
2.7 策略模式解析
- 策略模式是一种定义一系列算法的方法，从概念上来看，所有这些算法完成的都是相同的工作，只是实现不同，它可以以相同的方式调用所有的算法，减少了各种算法类与使用算法类之间的耦合[DPE]
- “当然。这个办法就是用到了反射技术，不是常有人讲，‘反射反射，程序员的快乐’，不过今天就不讲了，以后会再提它的。”
- （注：在抽象工厂模式章节有对反射的讲解）
3.4 单一职责原则
- 就一个类而言，应该仅有一个引起它变化的原因[ASD]
3.5 方块游戏的设计
- 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏[ASD]
- 软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离[ASD]
- 如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责[ASD]，就应该考虑类的职责分离。”
4.2 开放-封闭原则
- 开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改
4.3 何时应对变化
- 开放-封闭原则的意思就是说，你设计的时候，时刻要考虑，尽量让这个类是足够好，写好了就不要去修改了，如果新需求来，我们增加一些类就完事了，原来的代码能不动则不动。
- “在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化[ASD]
- 我们希望的是在开发工作展开不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难[ASD]。
- 开放-封闭原则是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分做出抽象，然而，对于应用程序中的每个部分都刻意地进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要[ASD]。
5.3 依赖倒转原则
- 因为CPU的对外都是针脚式或触点式等标准的接口。啊，我明白了，这就是接口的最大好处。CPU只需要把接口定义好，内部再复杂我也不让外界知道，而主板只需要预留与CPU针脚的插槽就可以了。
- 依赖倒转原则，原话解释是抽象不应该依赖细节，细节应该依赖于抽象，这话绕口，说白了，就是要针对接口编程，不要对实现编程
- 高层模块不应该依赖低层模块。两个都应该依赖抽象
- 抽象不应该依赖细节。细节应该依赖抽象
- 比如我们做的项目大多要访问数据库，所以我们就把访问数据库的代码写成了函数，每次做新项目时就去调用这些函数。这也就叫做高层模块依赖低层模块。
5.4 里氏代换原则
- “里氏代换原则是Barbara Liskov女士在1988年发表的[ASD]，具体的数学定义比较复杂，你可以查相关资料，它的白话翻译就是一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化，简单地说，子类型必须能够替换掉它们的父类型[ASD]。”
- 里氏代换原则（LSP）：子类型必须能够替换掉它们的父类型。[ASD]
- 只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。