- 1、本文档共81页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
设计模式-Proxy 结构 设计模式-Proxy 核心思想归纳:构造一个具有相同接口的代理对象,然后将操作请求转发给真实对象,其目的是向客户隐藏“转发过程”的细节(如远程网络交互、智能决策、选择性转发等),提供对真实对象的透明访问。 设计模式-Iterator 动机与实例:支持遍历的列表设计。 设计方案1 内部迭代 外部迭代 设计模式-Iterator 动机与实例:支持遍历的列表设计。 设计方案1的问题: 其一,这种设计只能描述一种遍历方式,如向前遍历或向后遍历,但不能同时描述多种遍历方式。或许,大家觉得只需要再向List里面增加一些表示遍历的接口函数和表示位置的成员变量即可,但这样一来众多关系不紧密的功能混放在一个类里,会使得内聚程度变低,容易导致类膨胀,同时也给函数命名等带来不便。 其二,这种设计不支持在一个列表上同时进行多个相同类型的遍历(如都是向后遍历,只是对元素的处理方式不同),而这种情况可能出现在并行程序中。 设计模式-Iterator 设计方案2: 在一个列表上同时进行多个相同类型的遍历。 使用Iterator模式,将负责遍历的部分功能从List中分离出来,单独形成一个类ListIterator 设计模式-Iterator 设计方案2: 在一个列表上同时进行多个相同类型的遍历 Class ListIterator {… Private: const ListItem *list; … } ListIterator增加指向原列表的指针。因此,一个ListIterator实例记录了与列表的一次遍历相关的所有信息,通过定义ListIterator的多个实例变量,就可以在一个列表上同时进行多个相同类型的遍历。 设计模式-Iterator 设计方案3: 以多种方式遍历一个列表,再定义一个迭代器类型 设计模式-Iterator 适用场合:当需要以多种方式灵活地遍历一个聚合对象中的各个元素时,适用本模式。 结构: 设计模式-Iterator 核心思想归纳:通过将与遍历有关的部分从聚合对象的描述中分离出来、单独成类,能够将遍历的状态信息用一个独立对象记录,从而可有效处理多种遍历和并发遍历。另外,本模式可与Factory Method模式配合使用,支持从聚合对象直接创建相应的聚合器。 设计模式-Observer 动机与实例:Word软件的“窗口拆分”功能。 设计模式-Observer 动机与实例:Word软件的“窗口拆分”功能。 设计模式-Observer 动机与实例:Word软件的“窗口拆分”功能。 设计模式-Observer 动机与实例:Word软件的“窗口拆分”功能。 设计模式-Observer 适用场合:如果对象之间存在一对多的数据依赖关系、且当被依赖对象的数据改变时所有依赖于它的对象都应得到通知并自动更新,那么可使用本模式。被依赖的对象称为发布者,负责发布数据并通知所有的订阅者(即依赖于该发布者的对象),以便订阅者与发布者的状态保持一致。 前面的例子中,Document对象为发布者,而Window对象为订阅者。因此,本模式也称为发布-订阅(Publish-Subscribe)模式。订阅者也可称为观察者(Observer),它似乎在时刻观察发布者的状态,并及时更新自己。 设计模式-Observer 结构: 设计模式-总结、分类 总体来说设计模式分为三大类: 创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。 结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。 行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。 设计模式-总结、原则 1、开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。 2、里氏代换原则(Liskov Substitution Principle) 里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象
文档评论(0)