回想自己学习《大话设计模式》的旅程。有一种飘忽不定的感觉,单个进入一个模式。很好理解。但随着模式的增多。越来越发现各个设计模式之间联系紧密,又有差别。
于是慢慢学着总结……
【模式归类】
在书的结尾处,为23个设计模式(不包括简单工厂模式)做了一个系统的分类:
个人觉得这种分类方式事实上跟企业的建立过程是一样的。首先一个project的建立必须遵循一个整体的设计模式,就好像企业要有整体的战略目标对企业行为的指导作用一样,对project的整体建立过程提供一个建设模式--建设型。然后将project细分,必须依赖各个类,子项目的结构联系,也就是企业的各个短期目标的建设过程所要考虑的各时间段内所存在的制约--结构型!最后考虑怎样让各个子项目可以更加高效的执行--行为型。
【作用分析】
不论什么设计模式都是针对某一类问题而存在的,仅仅有在了解它作用的基础上才干学会怎样使用?何时使用?
模式名称 | 英文 | 举例 | 作用 |
简单工厂模式 | SimpleFactory | “加减乘除”运算工厂调用 | 工厂详细实例化方法,决定使用哪一个方法!(switch)详细实例类不影响其它 |
工厂方法模式 | Factory | 加减乘除 | 好的分工,就像一个公司依赖不同的机器运行不一样的操作 |
建造者模式 | Builder | 小人的画法(胖子和瘦子) | 有一个指导类来指导操作顺序详细实现,避免发生错误 |
抽象工厂模式 | Ifactory | 基本数据库使用(数据库分类型) | 通过抽象工厂解除依赖(解耦) |
装饰模式 | Decorator | 对人的装饰过程 | 动态给一个对象加入方法 |
代理模式 | Proxy | 通过第三者送礼物 | 远程代理,虚拟代理,安全代理。智能指引等隐藏真实操作者 |
外观模式 | Façade | 投资基金取代各种股票 | 为外界定义接口。用户不用关系详细实现哪个类的方法。仅仅要知道汇总类的方法 |
组合模式 | Component | 子公司和部门加入 | 保证组合对象与加入的对象保持一致,不断添加 |
桥接模式 | Bridge | 手机依照软件和品牌的分类 | 实现系统可能多角度分类,减少耦合 |
享元模式 | Flyweight | 站点共享代码 | 运用共享技术有效的支持大量细粒度的对象 |
策略模式 | Strategy | 商场收银採用的活动策略(如打折) | 定义算法家族(可与简单工厂模式相结合) |
模板方法模式 | Template | 问题试卷的提出 | 不变行为搬移到超类,去除掉反复 |
观察者模式 | Observers | 观察老板回来 | 去除掉两个联系紧密类之间的耦合(与托付一起起作用) |
状态模式 | State | 小菜1天工作状态 | 将状态逻辑分布到子类之间,降低相互间依赖。一个对象的行为取决于他的状态 |
备忘录模式 | Memento | 保存游戏进度 | 恢复一个状态前的某一状态,撤销功能,复原操作 |
迭代器模式 | Iterator | 客车售票员收票过程 | 每次都遍历每个类成员,不easy丢失,但操作时间长 |
命令模式 | Command | 小摊和饭店烤羊肉串的差别 | 设计命令队列,将命令计入日志,可实现撤销 |
职责链模式 | COR | 加薪 | 避免发送者和接受者之间的耦合关系(像筛子一样) |
中介者模式 | Meditor | 安理会 | 降低了各个Colleague之间的耦合,把对象怎样协作进行了抽象 |
解释器模式 | Interprter | 音符的输出 | 提供一个翻译相应表,得到相应的翻译结果 |
就像工厂模式。仅仅有再接触了一个大的实例时。才干真正理解为什么使用工厂模式,而不是用简单工厂。
【六大原则】
设计原则是各个模式应该考虑实现的因素。正是基于这些原则的指导,设计模式才科学的应用到project的设计建立过程中。
原则分类 | 简称 | 概念 |
单一职责原则 | SRP | 就一个类而言,应该仅有一个引起该类变化的原因,多原则必将导致效率下降 |
开放封闭原则 | OCP | 软件实体能够扩展不能够改动(软件更新),许进不许改 |
依赖倒转原则 | DIP | 细节依赖抽象(针对接口编程)。能够不断给接口加入实例类,但不能为了类加入接口 |
里氏代换原则 | LSP | 子类可替换掉父类(继承所有非private属性和方法),结果全然不受影响 |
迪米特法则 | LoD | 类的结构设计,每一个成员应该尽量减少訪问权限,减少耦合性 |
合成复用原则 | CARP | 可以採用简单聚合,组合关系时不要用继承(继承的耦合程度非常高) |
【总结】
理论学习贵在总结。对照!接受课本想法的同一时候也要转换成自己的理解!相信这样学习在日后的实践中会给自己提供极大的帮助的!