![](https://img-blog.csdnimg.cn/20201014180756780.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
《Head First 设计模式》
Roxas__
这个作者很懒,什么都没留下…
展开
-
《Head First 设计模式》笔记12 复合模式
认识模型 - 视图 - 控制器模式(MVC)你是用户——你和视图交互。 视图是模型的窗口。当你对视图做一些事时(比方说,按下“播放”按钮),视图就告诉控制器你做了什么。控制器会负责处理。**控制器要求模型改变状态。**控制器解读你的动作。如果你按下某个按钮,控制器会理解这个动作的意义,并告知模型如何做出对应的动作。**控制器也可能要求视图做改变。**当控制器从视图接收到某一动作,结果可能是它也需要告诉视图改变其结果。比方说,控制器可以将界面上的某些按钮或菜单项变成有效或无效。**当模型状态改变时,原创 2021-03-05 12:06:46 · 110 阅读 · 1 评论 -
《Head First 设计模式》笔记10 状态模式
糖果公司示例:这种弱智的代码写法在变更来临时:所以,我们要重新代码结构:使用状态模式重新设计糖果机器:状态模式:允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类。...原创 2021-03-02 00:28:52 · 75 阅读 · 0 评论 -
《Head First 设计模式》笔记9 迭代器与组合模式
迭代器模式:提供一种方法顺序访问一个聚合对象中的各个原色,而又不暴露其内部的表示。对象村餐厅&煎饼店的迭代器模式实例:迭代器模式类图:设计原则:一个类应该只有一个引起变化的原因。如果我们允许我们的聚合实现他们内部的集合,以及相关的操作和遍历的方法,又会如何?我们已经知道这会增加聚合中的方法个数,但又怎样呢?为什么这么做不好?我们知道避免类内的改变,因为修改代码很容易造成许多潜在的错误。如果有一个类具有两个改变的原因,那么这会使得将来该类的变化几率上升,而当它真的改变时,你的设计中同时有原创 2021-02-26 14:33:38 · 104 阅读 · 0 评论 -
《Head First 设计模式》笔记8 模板方法模式
模板方法带来的一些好处:上图中的几个好处持怀疑态度。首先代码复用是最无所谓的一件事,我到目前认为纯粹为了复用而使用模板方法是一件很愚蠢的事。这个模板方法的一个麻烦之处在于,如果茶和咖啡在boilWater()或pourInCup()两个方法上出现了分歧,即代码不再一模一样,那么茶和咖啡就需要重新在子类各自实现自己的方法。模板方法模式:在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下,重新定义算法中的某些步骤。问题:为什么“算法的结构”就必须不.原创 2021-02-25 12:47:39 · 66 阅读 · 0 评论 -
《Head First 设计模式》笔记5 单件模式
单件模式:确保一个类只有一个实例,并提供一个全局访问点。单件模式基本实现:单件模式类图:经典的单件模式在加入多线程后会失效,改善方法:原创 2021-02-25 12:09:06 · 86 阅读 · 0 评论 -
《Head First 设计模式》笔记7 适配器模式与外观模式
面向对象适配器:火鸡和鸭子示例:适配器模式:将一个类的接口转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。适配器模式类图:原创 2021-02-24 18:54:25 · 110 阅读 · 0 评论 -
《Head First 设计模式》笔记6 命令模式
一个命令模式示例:示例类图:类图中包含一个遥控器类、一个Command接口、一个LightOnCommand具体命令类和一个Light灯设备类。Light的每一个操作对应实现一个Command具体类,Command具体类遵循Command接口。遥控器类的实现也仅针对Command接口编写。这样就做到了遥控器类和具体命令类均只依赖于Command接口,而不依赖彼此的实现,从而遥控器和命令解耦。结果就是任何具体的Command类,只要遵循Command接口,都可以直接插入遥控器中使用。真正执行命原创 2021-02-23 19:35:57 · 88 阅读 · 0 评论 -
《Head First 设计模式》笔记4 工厂模式
问题:实现的代码里不能有new,一出现new,一旦加入新的具体类,就必须改变代码。也就是说,你的代码并非”对修改关闭”。想用新的具体类型来扩展代码,必须重新打开它。由此提出一个疑问:如何将实例化具体类的代码从应用中抽离,或者封装起来,使他们不会干扰应用的其他部分?...原创 2021-02-22 17:14:30 · 123 阅读 · 0 评论 -
《Head First 设计模式》笔记3 装饰者模式
开放—关闭原则:类应该对扩展开放,对修改关闭。对扩展开放:欢迎用任何你想要的行为来扩展我们的类。如果你的需要或需求有所改变,那就来吧!动手扩展吧!对修改关闭:我们花了许多时间得到了正确的代码,还解决了所有的bug,所以不能让你修改现有代码。我们必须关闭代码以防止被修改。简单说就是,在不修改代码的情况下,进行功能扩展。在上一章学到的观察者模式即遵循了这个原则:通过加入新的观察者,我们可以再任何时候扩展Subject,而且不需要向主题中添加代码。星巴兹遇到的问题:类数量爆炸、基类加入的新功能并不适用于所原创 2021-02-21 17:12:28 · 136 阅读 · 0 评论 -
《Head First 设计模式》笔记2 观察者模式
观察者模式:定义了对象之间的一对多依赖,这样一来,当一个对象改变状态时,它的所有依赖者都会收到通知并自动更新。主题(subject)只知道观察者(observer)实现了某个接口(也就是observer接口)。主题不需要知道观察者的具体类是谁、做了些什么或其他任何细节。任何时候我们都可以增加新的观察者。因为主题唯一依赖的东西是一个实现observer接口的对象列表,所以我们可以随时增加观察者。事实上,在运行时我们可以随意增删观察者,主题不会受到任何影响。优点:有新类型的观察者出现时,主题的代码不需原创 2021-02-21 12:12:51 · 72 阅读 · 0 评论 -
《Head First 设计模式》笔记1 设计模式入门
设计原则1:找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起。换句话说,如果每次新的需求一来,都会使某方面的代码发生变化,那么你就可以确定,这部分的代码需要被抽出来,和其他稳定的代码有所区别。设计原则2:针对接口编程,而不是针对实现编程。在新的设计中,鸭子的子类将使用接口(FlyBehavior与QuackBehavior)所表示的行为,所以实际的“实现”不会被绑死在鸭子的子类中。当某一种行为需要修改时,我们仅修改一次该行为所对应的行为类即可,而不用把每个使用该种行为原创 2021-02-20 17:26:50 · 73 阅读 · 0 评论