![](https://img-blog.csdnimg.cn/20201014180756724.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
设计模式
文章平均质量分 58
丁真的小马
这个作者很懒,什么都没留下…
展开
-
设计模式 - 领域规则之解析器模式
一、领域规则模式在特定领域中,某些变化虽然频繁,但可以抽象为某种规则。这时候,结合特点领域,将问题抽象为语法规则,从而给出在该领域下的一般性解决方案。典型模式:Interpreter二、动机在软件构建过程中,如果某一特点领域的问题比较复杂,类似的结构不断重复出现,如果使用普通的编程方式来实现将面临非常频繁的变化。在这种情况下,将特点领域的问题表达为某种语法规则下的句子,然后构建出一个解释器来解释这样的句子,从而达到解决问题的目的。三、模式定义给定一个语言,定义它的文法的一种表示,原创 2022-05-16 22:22:11 · 143 阅读 · 0 评论 -
设计模式 - 行为变化之访问器模式
一、动机在软件构建过程中,由于需求的改变,某些类层次结构中常常需要增加新的行为(方法),如果直接在基类中做这样的更改,将会给子类带来很繁重的变更负担,甚至破坏原有设计。如何再不更改类层次结构的前提下,在运行时根据需要透明地为类层次结构上的各个类动态增加新的操作,从而避免上述问题?二、模式定义表示一个作用于某个对象结构中的各元素的操作。使得可以在不改变(稳定)各元素的类的前提下定义(扩展)作用于这些元素的新操作(变化)。三、结构四、要点总结Visitor 模式通过所谓的双重分发原创 2022-05-16 19:06:13 · 88 阅读 · 0 评论 -
设计模式 - 行为变化之命令模式
一、行为变化模式在组建的构建过程中,组件行为的变化经常导致组件本身剧烈的变化。“行为变化”模式将组件的行为和组件本身进行解耦,从而支持组件行为的变化,实现两者之间的松耦合。典型模式:Command、Visitor二、动机在软件构建过程中,“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重(undo/redo)、事务”等处理,这种无法抵御变化的紧耦合是不合适的。在这种情况下,如何将“行为请求者”与“行为实现者”解耦?将一组行为抽象为对象原创 2022-05-16 17:55:21 · 125 阅读 · 0 评论 -
设计模式 - 数据结构之职责链模式
一、动机在软件构建过程中,一个请求可能被多个对象处理,但是每个请求在运行时只能有一个接收者,如果显式指定,即将必不可少地带来请求发送者与接受者的紧耦合。如何使请求的发送者不需要指定具体的接收者?让请求的接受则自己在运行时决定来处理请求,从而使二者解耦。二、模式定义使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递请求,知道有一个对象处理它为止。三、结构四、要点总结职责链模式的应用场合在于“一个请求可能有多个接受者,但原创 2022-05-16 16:53:56 · 113 阅读 · 0 评论 -
设计模式 - 数据结构之迭代器模式
一、动机在软件构建过程中,集合对象内部结构常常变化各异。但对于这些集合对象,我们希望在不暴露其内部结构的同时,可以让外部客户代码透明地访问其中包含的元素;同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方式二、模式定义提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露(稳定)该对象的内部表示。三、结构四、要点总结迭代抽象:访问一个聚合对象的内容而无需暴露原创 2022-05-15 22:06:45 · 133 阅读 · 0 评论 -
设计模式 - 数据结构之组合模式
一、数据结构模式常常有一些组件在内部具有特定的数据结构,如果让客户程序依赖这些特定的数据结构,将极大地破坏组件的复用。这时候,将这些特定数据结构封装在内部,在外部提供统一的结构,来实现与特定数据结构无关的访问,是一种行之有效的解决方案。典型模式:Composite、Iterator、Chain of Resposibility二、动机在软件的某些情况下、客户代码过多地依赖于对象容器复杂的内部实现结构,对象容器内部实现结构(而非抽象接口)的变化将引起客户代码的频繁变化,带来了代码的维护性、扩展原创 2022-05-15 19:06:42 · 194 阅读 · 0 评论 -
设计模式 - 状态变化之备忘录模式
一、动机在软件构建过程中,某些对象的状态在转化过程中,可能由于某种需求,要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态,变化暴露对象的细节实现。如何实现对象状态的良好保存与恢复?但同时又不会因此而破坏对象本身的封装性。二、模式定义在不破坏封装性的前提下,捕捉一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。三、结构四、要点总结备忘录(Memento)存储原发器(Originator)对象的原创 2022-05-15 18:25:05 · 134 阅读 · 0 评论 -
设计模式 - 状态变化之状态模式
一、状态变化模式在组件构建过程中,某些对象的状态经常面临变化,如何对这些变化进行有效的管理?同时又维持高层模块的稳定?“状态变化”模式为这一问题提供了一种解决方案。典型模式:State、Memento二、动机在软件构建过程中,某些对象的状态如果改变,其行为也会随之而发生变化,比如文档处于只读状态,其支持的行为和读写状态支持的行为就可能完全不同。如何在运行时根据对象的状态来透明地更改对象的行为?而不会为对象操作和状态转化之间引入紧耦合?三、模式定义允许一个对象在其内部状态改变时改变它原创 2022-05-15 02:00:25 · 154 阅读 · 0 评论 -
设计模式 - 接口隔离之中介者模式
一、动机在软件构建过程中,经常会出现多个对象互相关联交互的情况,对象之间常常会维持一种复杂的引用关系,如果遇到一些需求的更改,这种直接的引用关系将面临不断地变化。在这种情况下,我们可使用一个”中介对象“来管理对象间的关联关系,避免相互交互的对象之间的紧耦合引用关系,从而更好地抵御变化。二、模式定义用一个中介对象来封装(封装变化)一系列的对象交互。中介者使各对象不需要显示的相互引用(编译时依赖 -> 运行时依赖);从而使其耦合松散(管理变化),而且可以独立地改变它们之间的交互三、结构原创 2022-05-15 00:48:23 · 130 阅读 · 0 评论 -
设计模式 - 接口隔离之适配器模式
一、动机在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象所不满足的。如何应对这种“迁移的变化”?如何既能利用现有对象的良好实现,同时又能满足新的应用环境所要求的接口?二、模式定义将一类的接口转换成客户希望的另一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。三、结构四、要点总结适配器模式主要应用于“希望复用一些现存的类,但是接口又与复用环境要求不一致的情况“,在遗留代码复用、类库迁原创 2022-05-14 23:24:56 · 116 阅读 · 0 评论 -
设计模式 - 接口隔离之代理模式
一、动机在面向对象系统中,有些对象由于某种原因(比如对象创建的开销很大,或者某些操作需要安全控制,或者需要进程外的访问等),直接访问会给使用者、或者系统结构带来很多麻烦如何在不是去透明操作对象的同时来管理/控制这些对象特有的复杂性?增加一层简介层时软件开发中常见的解决方式。为什么使用代理模式?第一个,客户端有时无法直接操作某些对象。比如,在分布式应用中,你需要调用的对象可能是运行在另外一台服务器上的,当你访问它时,就必须要通过网络才能访问。如果你让客户端直接去调用,那么就意味着客户端需要处.原创 2022-05-14 01:13:01 · 188 阅读 · 0 评论 -
设计模式 - 接口隔离之门面模式
一、接口隔离模式在组件构建过程中,某些接口之间的直接依赖常常会带来很多问题、甚至根本无法实现。采用加一层间接(稳定)接口,来隔离本来就紧密关联的接口时一种常见的解决方案。典型模式:Facade、Proxy、Adapter、Mediator二、系统间耦合的复杂度三、动机上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化,这种过多的耦合面临很多变化的挑战。如何简化外部客户程序和系统间的交互接口?如何将外部客户程序的演化和内部子系统的原创 2022-05-14 00:16:07 · 71 阅读 · 0 评论 -
设计模式 - 对象性能之单例模式
一、对象性能模式面向对象很好地解决了”抽象“的问题,但是必不可免地要付出一定的代价。对于通常情况来讲,面向对象的成本大都可以忽略不计。但是某些情况,面向对象所带来的成本必须谨慎处理。典型模式:Singleton、Flyweight二、动机在软件系统中,经常有这样一些特殊的类,必须保证它们再系统中只存在一个实例,才能确保它们的逻辑正确性,以及良好的效率如何绕过常规的构造器,提供一种机制来保证一个类只有一个实例?这应该是设计者的责任,而不是使用者的责任三、模式定义保证一个类仅有一原创 2022-05-13 01:14:14 · 143 阅读 · 0 评论 -
设计模式 - 对象创建之构建器模式
一、动机在软件系统中,有时候面临着“一个复杂对象”的创建工作,其通常由各个部分的子对象用一定的算法构成;由于需求的变化,这个复杂对象的各个部分经常面临着剧烈的变化,但是将它们组合在 一起的算法却相对稳定。如何应对这种变化?如何提供一种“封装机制”来隔离出“复杂 对象的各个部分”的变化,从而保持系统中的“稳定构建算法”不 随着需求改变而改变?二、模式定义将一个复杂对象的构建与其表示相分离,使得同样的构建过程(稳定)可以创建不同的表示(变化)。三、结构四、要点总结Builde原创 2022-05-12 22:57:31 · 98 阅读 · 0 评论 -
设计模式 - 对象创建之原型模式
一、动机在软件系统中,经常面临着“某些结构复杂的对象”的创建工作;由于需求的变化,这些对象经常面临着剧烈的变化,但是条目却拥有比较稳定一致的接口如何应对这种变化?如何向“客户程序(使用这些对象的程序)”隔离出”这些易变对象“,从而使得”依赖这些易变对象的客户程序“不会随着需求改变而改变二、模式定义使用原型示例指定创建对象的种类,然后通过拷贝这些原型来创建新的对象。三、结构四、要点总结Prototype模式同样用于隔离类对象的使用和具体类型(易变类)之间的耦合关系,它同样要求这原创 2022-05-12 19:24:15 · 78 阅读 · 0 评论 -
设计模式 - 对象创建之抽象工厂
一、动机在软件系统中,经常面临着“一系列相互依赖的对象”的创建工 作;同时,由于需求的变化,往往存在更多系列对象的创建工作。如何应对这种变化?如何绕过常规的对象创建方法(new),提供一 种“封装机制”来避免客户程序和这种“多系列具体对象创建工作” 的紧耦合?二、模式定义提供一个接口,让该接口负责创建一系列“相关或者相互依赖的对象”,无需指定它们具体的类。三、结构四、要点总结如果没有应对“多系列对象构建”的需求变化,则没有必要使用 Abstract Factory 模式,原创 2022-05-12 16:40:13 · 59 阅读 · 0 评论 -
设计模式 - 对象创建之工厂方法
一、对象创建模式通过“对象创建”模式绕开 new ,来避免对象创建(new)过程中所导致的紧耦合(依赖具体类),从而支持对象创建的稳定。它是接口抽象之后的第一步工作。典型模式:Factory Method、Abstract Factory、Prototype、Builder二、工厂方法动机在软件系统中,经常面临创建对象的工作;由于需求的变化,需要创建的对象的具体类型经常变化。如何应对这种变化?如何绕过常规的对象创建方法(new),提供一种“封装机制”来避免客户程序和这种“具体对象创建工作原创 2022-05-12 15:38:46 · 85 阅读 · 0 评论 -
设计模式 - 单一职责之桥模式
一、动机由于某些类型的固有的实现逻辑,使得它们具有两个变化的维度, 乃至多个纬度的变化。如何应对这种“多维度的变化”?如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化,而不引入额外的复杂度?桥接模式与装饰模式的区别:桥接模式侧重于横向宽度的扩展,而装饰模式侧重于纵向深度的扩展。二、模式定义将抽象部分(业务功能)与实现部分(平台实现)分离,使它们都可以独立地变化。 换句话说,抽象的分离间接完成了具体类与具体类之间的解耦,它们之间使用抽象来进行组合或聚合,而不再使用继原创 2022-05-12 01:35:55 · 95 阅读 · 0 评论 -
设计模式 - 单一职责之装饰模式
一、单一职责模式在软件组件的设计中,如果责任划分的不清晰,使得继承得到的结果往往是随着需求的变化,子类极具膨胀,同时充斥着重复代码,这时候的关键是划清责任。二、装饰模式动机在某些情况下我们可能会“过度地使用继承来扩展对象的功能”, 由于继承为类型引入的静态特质,使得这种扩展方式缺乏灵活性; 并且随着子类的增多(扩展功能的增多),各种子类的组合(扩展 功能的组合)会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现?同时避免“扩展功能的增多”带来的子类膨胀问题?从而使得任何“原创 2022-05-12 01:03:51 · 86 阅读 · 0 评论 -
设计模式 - 组件协作之观察者模式
一、动机在软件构建过程中,我们需要为某些对象建立一种“通知依赖关系” 。一个对象(目标对象)的状态发生改变,所有的依赖对象(观察者对象)都将得到通知。如果这样的依赖关系过于紧密,将使软件不能很好地抵御变化。使用面向对象技术,可以将这种依赖关系弱化,并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。二、模式定义定义对象间的一种一对多(变化)的依赖关系,以便当一个对象(Subject)的状态发生改变时,所有依赖于它的对象都得到通知并自动更新。三、结构四、要点总结使用面向对象原创 2022-05-11 17:43:03 · 133 阅读 · 0 评论 -
设计模式 - 组件协作之策略模式
一、动机在软件构建过程中,某些对象使用的算法可能多种多样,经常改变,如果将这些算法都编码到对象中,将会使对象变得异常复杂;而且有时候支持不使用的算法也是一个性能负担。如何在运行时根据透明的更改对象的算法?将算法与对象本身解耦,从而避免上述的问题?二、模式定义定义一系列算法,把它们一个个封装起来,并且使它们可以互相替换(变化)。该模式使得算法可独立使用于他们的客户程序(稳定)而变化(扩展,子类化)。三、结构四、要点总结Strategy及其子类为组件提供了一系列可重用的算法,从而原创 2022-05-11 14:56:35 · 80 阅读 · 0 评论 -
设计模式 - 组件协作之模板方法
一、什么是组件协作模式现代软件专业分工之后的第一个结果是“框架与应用程序的划分”,“组件协作”模式通过晚期绑定,来实现框架与应用程序之间的松耦合,是二者之间的协作时常用的模式。二、Template Method 动机在软件构建过程中,对于某一项任务,它常常有稳定的整体操作结构,但各个子步骤却有很多改变的需求,或者由于固有的原因 (比如框架与应用之间的关系)而无法和任务的整体结构同时实现。结构化软件设计流程面向对象软件设计流程早绑定与晚绑定早绑定:后开发的代码调用之前开原创 2022-05-11 01:00:55 · 102 阅读 · 0 评论 -
设计模式 - 面向对象设计原则
一、依赖倒置原则(DIP)高层模块(稳定)不应该依赖于底层模块(变化),二者都应该依赖于抽象(稳定) 抽象(稳定)不应该依赖于实现细节(变化),实现细节应该依赖于抽象(稳定)二、开放封闭原则(OCP)对扩展开放,对更改封闭 类模块应该是可以扩展的,但是不可以修改三、单一职责原则(SRP)一个类应该仅有一个引起它变化的原因 变化的方向隐含着类的责任四、Liskov替换原则(LSP)子类必须能够替换他们的基类(IS-A) 继承表达类型抽象五、接口隔离原则(ISP)不应该强原创 2022-05-03 23:04:16 · 59 阅读 · 0 评论