注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

秒大刀 博客

好好学习 天天向上

 
 
 

日志

 
 
 
 

读《Head First 设计模式》  

2011-07-22 16:34:24|  分类: 读书 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
读《Head First 设计模式》 - 秒大刀 - 秒大刀的城堡
可能我还没有适应Head First这样的讲述方式,觉得乱乱的。

设计模式定义
  1. 策略模式:定义了算法族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化独立于使用算法的客户
  2. 观察者模式:定义了对象之间的一对多依赖,这样一来,当一个对象改变状态是,它的所有依赖都会收到通知并自动更新
  3. 装饰者模式:动态的将责任附加到对象上。若要扩展功能,装饰者提供了比继承更有弹性的替代方案
  4. 工厂方法模式:定义了一个创建对象的接口,但由于子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。
  5. 抽象工厂模式:提供了一个接口,用于创建相关或依赖对象的家族,而不需要明确指定具体类
  6. 单件模式:确保一个类只有一个实例,并提供一个全局访问点
  7. 命令模式:将“请求”封装成对象,以便使用不同的请求、队列或者日志来参数化其他对象。命令模式也支持撤销的操作
  8. 适配器模式:将一个类的接口,转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间
  9. 外观模式:提供了一个统一的接口,用来访问子系统中的一群接口。外观定义了一个高层接口,让系统更容易使用
  10. 模板方法模式:在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤
  11. 迭代器模式:提供一种方法顺序访问一个聚合对象中的各个元素,而不暴露其内部的表示
  12. 组合模式:允许你将对象组合成树形结构来表现“整体/部分”层次结构。组合能让客户以一致的方式处理个别对象以及对象组合
  13. 状态模式:允许对象在内部状态改变它的行为,对象看起来好像修改了它的类
  14. 代理模式:为另一个对象提供一个替身或占位符以控制对这个对象的访问
  15. 复合模式:复合模式结合两个或以上的模式,组成一个解决方案,解决一再发生的一般性问题
  16. 模式:模式是在某情境下,针对某问题的某种解决方案

设计原则
  1. 找出应用中可能需要变化之处,把他们独立出来,不要和那些不需要变化的代码混在一起
  2. 针对接口编程,而不是针对实现编程
  3. 多用组合,少用继承
  4. 为了交互对象之间的松耦合设计而努力
  5. 类应该对扩展开放,对修改关闭
  6. 要依赖抽象,不要依赖具体类——依赖倒置原则
  7. 最少知识原则:只和你的密友谈话
  8. 好莱坞原则:别打电话给我们,我们会打电话给你(别调用我们,我们会调用你)
  9. 一个类应该只有一个引起变化的原因

引子
  1. 正确的做法是讲故事,而不是作报告。要用通俗的语言,不要太严肃
  2. 如果你真的想学,而且想学得更快、更深入,就应该注意你怎样才能集中注意力
  3. 要让你的大脑认为你在学习的新东西确实很重要,对你的生活有很大影响。否则你将陷入旷日持久的拉锯战中,虽然你很想记住所学的新内容,但是你的大脑会竭尽全力把它们拒之门外
  4. 临渊羡鱼,不如退而结网
  5. 如果和人打交道,相对于东西而言,你的大脑会表示出更多的注意力
  6. 慢一点,你理解的越多,需要记的就越少
  7. 勤做练习,自己记笔记
  8. 上床睡觉之前不要再看别的书了,或者至少不再看其他有难度的东西。学习中有一部分是在你合上书之后。你的大脑需要有自己的时间来做一些处理。如果在这段处理时间内你又往大脑里灌输了新的知识,那么你刚学的一些东西就会被丢掉
  9. 要喝水,而且要多喝点水。如果能提供充足的体液,你的大脑才能有最佳表现。
  10. 大声说出来。说话可以刺激大脑的另一部分。
  11. 达到某个临界点时,如果还一味的向大脑里塞,这对加快学习速度根本没有帮助,甚至还可能影响正常的学习
  12. 要有点感觉!你的大脑需要知道这是很重要的东西
  13. 尽量应用知识,获取实践经验

第1章 设计模式入门
  1. 有些人已经解决你的问题了
  2. 把模式装进脑子,然后在你的设计和已有的应用中,寻找何处可以使用它们。以往是代码复用,现在是经验复用
  3. 当涉及“维护”时,为了“复用”目的而使用继承,结局并不完美
  4. 软件开发的一个不变真理——CHANGE
  5. 如果每次新的需求一来,都会使某方面的代码发生变化,那么你就可以确定,这部分的代码需要被抽出来,和其他稳定的代码有所区分
  6. “针对接口编程”真正的意思的“针对超类型编程”,关键在于利用多态
  7. “HAS-A”可能比"IS-A"更好
  8. 应该致力于提高可维护性和可扩展性上的复用程度
  9. 设计模式让你和其他开发人员之间有共享的词汇,一旦懂得这些词汇,和其他开发人员之间沟通就很容易,也会促使那些不懂的程序员想开始学习设计模式。设计模式也可以把你思考架构的层次提高到设计模式层面,而不是仅停留在琐碎的对象上。
  10. 共享模式词汇的威力:
    1. 共享的模式词汇“威力强大”。当你使用模式名称和其他开发人员或者开发团队沟通时,你们之间交流的不只是模式名称,而是一整套模式背后所象征的质量、特性、约束
    2. 模式能够让你用更少的词汇做更充分的沟通。当你用模式描述的时候,其他开发人员很容易的知道你对设计的想法
    3. 将说话的方式保持在模式层次,可让你待在“设计圈子”更久一点。使用模式谈论软件系统,可以让你保持在设计层次,不会被压低到对象与类这种琐碎的事情上面
    4. 共享词汇可帮你的开发团队快速充电。对于设计模式有深入了解的团队,彼此之间对于设计的看法不容易产生误解
    5. 共享词汇能帮助初级开发人员迅速成长。初级开发人员向有经验的开发人员看齐。当高级开发人员使用设计模式,初级开发人员也会跟着学。把你的组织建立成一个模式使用者的社区
  11. 我们全都使用别人设计好的库与框架。我们讨论库与框架、利用它们的API编译成我们的程序、享受运用别人的代码所带来的优点。
  12. 设计模式不会直接进入到你的代码中,而是先进入你的“大脑”中
  13. 设计是一门艺术,总是有许多可取舍的地方
  14. 知道OO基础,并不足以让你设计出良好的OO系统
  15. 良好的OO设计必须具备可复用、可扩充、可维护三个特性
  16. 模式可以让我们建造出具有良好OO设计质量的系统
  17. 模式被认为是经历验证的OO设计经验
  18. 模式不是代码,而是针对设计问题的通用解决方案。你可把它们应用到特定的应用中
  19. 模式不是被发明,而是被发现
  20. 大多数的模式和原则,都着眼于软件变换的主题
  21. 大多数的模式都允许系统局部改变独立于其他部分
  22. 我们常把系统中会变化的部分抽出来封装
  23. 模式让开发人员之间有共享的语言,能够最大化沟通的价值

第2章 观察者(Observer)模式
  1. 观察者中的Subject是真正拥有数据的人,Observer是Subject的依赖者,在数据变化时更新,这样比起让许多对象控制同一份数据,可以得到更干净的OO设计
  2. 不要依赖于观察者被通知的次序

第3章 装饰者模式
  1. 运行时扩展,远比编译时继承威力大
  2. 在每个地方都采用“开放-关闭”原则,是一种浪费,也没必要,还会导致代码变得复杂且难以理解
  3. 装饰者和被装饰者必须有相同的基类。利用继承达到“类型匹配”,而不是利用继承获得“行为”
  4. 如果依赖继承,那么类的行为只能在编译时静态决定;如果依赖继承,每当需要新行为时,就需要修改现在代码
  5. 利用装饰者模式,常常造成设计中有大量的小类
  6. 继承属于扩展形式之一,但不见得是达到弹性设计的最佳方式
  7. 在我们的设计中,应该允许行为可以被扩展,而无须修改现有的代码
  8. 组合和委托可用于在运行时动态的加上新的行为
  9. 除了继承,装饰者模式也可以让我们扩展行为
  10. 装饰者模式意味着一群装饰者类,这些类用来包装具体组件
  11. 装饰者类反映出被装饰的组件类型(事实上,他们具有相同的类型,都经过接口或继承实现) 
  12. 装饰者可以在被装饰者的行为前面与/或后面加上自己的行为,甚至将被装饰者的行为整个取代掉,而达到特定的目的
  13. 你可以用无数个装饰者包装一个组件
  14. 装饰者一般对组件的客户是透明的,除非客户程序依赖于组件的具体类型
  15. 装饰者会导致设计中出现许多小对象,如果过度使用,会让程序变得复杂

第4章 工厂模式
  1. 当使用“new”时,你的确是在实例化一个具体类,所以用的确实是实现,而不是接口
  2. 工厂方法模式通过让子类决定该创建的对象是什么,来达到将对象创建的过程封装的目的
  3. 不能让高层组件依赖于底层组件,“两者”都应该依赖于抽象
  4. 如何避免在OO设计中违反依赖倒置原则:
    1. 变量不可以持有具体类的引用
    2. 不要让类派生自具体类
    3. 不要覆盖基类中已实现的方法
  5. 利用工厂方法创建对象,需要扩展一个类,并覆盖它的工厂方法。工厂方法可以把客户代码从需要实例化的具体类中解耦。
  6. 抽象工厂用来创建一个产品家族的抽象类型,这个类型的子类定义了产品被产生的方法。要想使用这个工厂,必须先实例化它,然后将它传入一些针对抽象类型所写的代码中。抽象工厂的优点是可以将一群相关的产品集合起来。当需要创建产品家族或想让制造的相关产品集合起来时,可以使用抽象工厂。
  7. 所有工厂都是用来封装对象的创建
  8. 简单工厂,虽然不是真正的设计模式,但仍不失为一个简单的方法,可以将客户程序从具体类解耦
  9. 工厂方法使用继承:把对象的创建委托给子类,子类实现工厂方法来创建对象
  10. 抽象工厂使用对象组合:对象的创建被实现在工厂接口所暴露出来的方法中
  11. 所有工厂模式都通过减少应用程序和具体类之间的依赖促进松耦合
  12. 工厂方法允许类将实例化延迟到子类进行
  13. 抽象工厂创建相关的对象家族,而不需要依赖他们的具体类
  14. 依赖倒置原则,指导我们避免依赖具体类型,而要尽量依赖抽象
  15. 工厂是很有威力的技巧,帮助我们针对抽象编程,而不要针对具体类编程

第5章 单件模式
  1. 除非你有绝对的必要使用静态类单件,否则建议使用普通的对象单件
  2. 类应该做一件事,而且只做一件事
  3. 如果你的应用程序大量的使用了单件模式,那么你可能需要好好地检查涉及。因为通常适合使用单件模式的机会不多

第6章 命令模式
  1. 重视“空对象”的使用
  2. 命令模式将发出请求的对象和执行请求的对象解耦
  3. 在被解耦的两者之间是通过命令对象进行沟通的。命令对象封装了接收者和一个或一组动作
  4. 宏命令是一种简单的延伸,允许调用多个命令。宏方法也可以支持撤销
  5. 命令也可以用来实现日志和事务系统

第7章 适配器模式与外观模式
  1. 被解耦的客户才是快乐的客户
  2. 外观:让接口简单;装饰者:不改变接口,但加入责任;适配器:将一个接口转成另一个接口
  3. 外观只是提供更直接的操作,并未将原来的子系统阻隔起来。如果你需要子系统类的更高层功能,还是可以使用原来的子系统
  4. 外观不只是简化了接口,也将客户从组件的子系统中解耦
  5. 外观和适配器可以包装许多类,但是外观的意图是简化接口,而适配器的意图是将接口转换成不同接口
  6. 所有的原则都应该在有帮助的时候才遵守。所有的设计都不免需要折衷
  7. 虽然原则提供了方针,但在采用原则之前,必须全盘考虑所有的因素
  8. 外观将客户从一个复杂的子系统中解耦
  9. 适配器将一个对象包装起来以改变其接口;装饰者将一个对象包装起来以增加新的行为和责任;而外观将一群对象“包装”起来以简化其接口

第8章 模板方法模式
  1. 模板方法定义了一个算法的步骤,并允许子类为一个或多个步骤提供实现
  2. 在好莱坞原则之下,我们允许低层组件将自己挂钩到系统上,但是高层组件会决定什么时候和怎样使用这些低层组件
  3. 依赖倒置原则教我们尽量避免使用具体类,而多使用抽象。而好莱坞原则是用在创建框架或组件上的一种技巧,好让低层组件能够被挂钩进计算中,而且又不会让高层组件依赖低层组件。两者的目标都是在与解耦,但是依赖倒置原则更加注重如何在设计中避免依赖。好莱坞原则教我们一个技巧,创建一个有弹性的设计,允许低层结构能够互相操作,而又防止其他类太过依赖它们。
  4. “模板方法”定义了算法的步骤,把这些步骤的实现延迟到子类
  5. 模板方法模式为我们提供了一种代码复用的重要技巧
  6. 模板方法的抽象类可以定义具体方法、抽象方法和钩子
  7. 抽象方法由子类实现
  8. 钩子是一种方法,它在抽象类中不做事,或者制作默认的事情,子类可以选择要不要去覆盖它
  9. 为了防止子类改变模板方法中的算法,可以将模板方法声明为final、好莱坞原则告诉我们,将决策权放在高层模块中,以便决定如何以及何时调用低层模块
  10. 策略模式和模板方法模式都封装算法,一个用组合,一个用继承
  11. 工厂方法是模板方法的一个特殊版本

第9章 迭代器与组合模式
  1. 封装变化的部分

第10章 事物的状态
  1. 策略模式是围绕可以互换的算法来创建成功业务的。状态模式通过改变对象内部的状态来帮助对象控制自己的行为
  2. 状态模式允许一个对象基于内部状态而拥有不同的行为
  3. 和程序状态机(PSM)不同,状态模式用类代表状态
  4. Context会将行为委托给当前状态对象
  5. 通过将每个状态封装进一个类,我们把以后需要做的任何改变局部化了
  6. 状态模式和策略模式有相同的类图,但是他们的意图不同
  7. 策略模式通常会用行为或算法来配置Context类
  8. 状态模式允许Context随着状态的改变而改变行为
  9. 状态转换可以由State类或Context类控制
  10. 使用状态模式通常会导致设计中的类的数目大量增加
  11. 状态类可以被多个Context实例共享

第11章 代理模式
  1. 代理模式为另一个对象提供代表,以便控制客户对对象的访问,管理访问的方式有许多种
  2. 远程代理管理客户和远程对象之间的交互
  3. 虚拟代理控制访问实例化开销大的对象
  4. 保护代理基于调用者控制对对象方法的访问
  5. 代理模式有许多变体,例如:缓存代理、同步代理、防火墙代理和写入时复制代理
  6. 代理在结构上类似装饰者,但是目的不同
  7. 装饰者模式为对象加上行为,而代理则是控制访问

第12章 复合模式
  1. 模式通常被一起使用,并被组合在同一个设计解决方案中
  2. 采用模式时必须要考虑到这么做是否有意义。绝对不能为了使用模式而使用模式
  3. MVC是由数个设计模式结合起来的模式。视图和控制器实现了经典的策略模式;模型实现了观察者模式,当状态改变时,相关对象将持续更新
  4. MVC
    • 模型:模型持有所有的数据、状态和程序逻辑。模型没有注意到视图和控制器,虽然它提供了操作和检索状态的接口,并发送状态改变通知给观察者
    • 视图:用来呈现模型。视图通常直接从模型中取得它需要显示的状态与数据
    • 控制器:取得用户的输入并解读其对模型的意思。控制器把控制逻辑从视图中分离,让模型和视图之间解耦
  5. MVC是复合模式,结合了观察者模式、策略模式和组合模式
  6. 模型使用观察者模式,以便观察者更新,同时保持两者之间解耦
  7. 控制器是视图的策略,视图可以使用不同的控制器实现,得到不同的行为
  8. 视图使用组合模式实现用户界面,用户界面通常组合了嵌套的组件
  9. 适配器模式用来将新的模型适配成已有的视图和控制器

第13章 与设计模式相处
  1. 如果没有名字,一个模式就无法变成开发人员之间共享的词汇
  2. 你可以改变模式。模式不是法律或准则,模式只是指导方针,你可以改变模式来符合你的需要,但最好在文档中注明它与经典设计模式有何差异。
  3. 模式是被“发现的”,而不是被创建的
  4. 当你设计时,尽可能的用最简单的方式解决问题。如果你能够保持简单的设计,那么你将会得到其他开发人员的欣赏和尊敬。为了要让你的设计简单且有弹性,有时候使用模式是最好的办法
  5. 何时使用模式?当你在设计的时候,如果确定可以用某个模式来解决某个问题,那么就使用这个模式!如果有更简单的解决方案,那么在决定使用模式之前应该先考虑这个方案
  6. 找出你设计中会改变的区域,通常这是需要模式的迹象。加入模式是要应对可能发生的实际改变,而不是遐想的改变
  7. 并非只有在设计时才考虑引进模式,在重构时也要这样做
  8. 重构的目标是要改善其结构,而不是其行为
  9. 当你的系统变得非常复杂,而且并不需要预留任何弹性的时候,就不要使用模式。拿掉你所不需要的,不要害怕将一个设计模式从你的设计中删除
  10. 如果你现在不需要,就别做。设计模式威力很强大,你很容易就可以在当前设计中看到模式的各种应用方式。开发人员天生就热爱创建漂亮的架构以应对任何方向的改变。要抗拒这样的诱惑呀!如果你今天在设计中有实际的需求去支持改变,就放手采用模式处理这个改变吧!然而,如果说理由只是假象,就不要添加这个模式,因为这只会将你的系统越搞越复杂,而且很可能你永远不会需要它!别忘了“杀鸡焉用牛刀”的道理!
  11. 模式只是一种工具,只有在需要时才使用这种工具。“应用模式”绝对不是你开始设计时该有的目标,应该让模式在你的设计过程中自然而然的出现。
  12. 模式会带来复杂性,如果没有必要,我们绝不需要这样的复杂性。
  13. 当你确信你的设计中有一个问题需要解决的时候,或者当你确信未来的需求可能会改变时,都可以采用模式
  14. 学习管理软件的复杂度和变化,这是一生的课题
  15. 警告:过度使用设计模式可能导致代码被过度工程化。应该总是用最简单的解决方案完成工作,并在真正需要模式的地方才使用它。
  16. 设计模式不仅可以帮助你在大脑中装进这些解决方案,也可以让你和其他开发人员之间有共享的词汇
  17. 让设计模式自然而然的出现在你的设计中,而不是为了使用而使用
  18. 设计模式并非僵化的教条;你可以依据自己的需要采用或调整
  19. 总是使用满足需要的最简单的解决方案,不管它用不用模式
  20. 模式能够为你带来的最大好处之一是:让你的团队拥有共享的词汇

扩展阅读:
李建忠老师《C#面向对象设计模式纵横谈系列课程
  评论这张
 
阅读(2040)| 评论(0)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017