设计模式
讲述软件设计过程中常用到的设计模式,为有更好的设计打下扎实的基础
carson0408
热衷于编程,喜欢研究算法,挑战难题,享受AC的过程,希望自己能够不断进步,不断成长。
展开
-
设计模式总结
前面的文章已经把每一种设计模式都进行了介绍。接下来对每种模式进行简要的概括总结,便于记忆。我就从创建型、结构型和行为型三个大类进行概括。、1.创建型模式1.单例模式 一个类只需创建一次对象,而后只需要使用第一次创建的对象即可,利用一个类变量来存储该对象。特殊情况:多线程下,则需要使用double-check,即volatile和synchronized的配合使用。原创 2018-01-27 22:08:29 · 334 阅读 · 0 评论 -
设计模式之访问者模式
之前我们介绍过观察者模式,是用于数据发生更新时,可以统一通知数据相关的对象进行相应的更新。而本文介绍的访问者模式,则是面对有许多对象需要进行某些操作时,如果在相应类中完成,则会污染类,因为这些操作会发生改变,那么类也会相应改变。如果有一个访问者类,负责统一访问各个对象,即在访问者类中为每一个对象设置访问方法,并且在每一个被访问的类中构建一个接受方法,即接受访问者类访问的方法。那么,如果对某一个被访原创 2018-01-27 19:46:03 · 402 阅读 · 0 评论 -
设计模式之享元模式
如果一个程序需要使用大量对象,但这些对象中有好多重复的对象,如果对其进行重复的创建对象,那么必然会造成很大的开销,其中这里面有很大一部分开销是不必要的。我们之前讲单例模式的时候,讲过单例模式就是严格控制单个进程只有一个实例对象,而且对于该实例对象不重复创建,这样可以节省系统开销。其实,本文提到的享元模式也是使用同样的思想,使得创建过对象不再重复创建,并且在使用过程中创建有需要的对象,如果对象已经创原创 2018-01-26 15:54:13 · 325 阅读 · 0 评论 -
设计模式之迭代器模式
如果我们需要遍历一个集合中的对象,但是又不想暴露该集合中的内部表示的时候,我们可以考虑迭代器模式。迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露其内部的表示。我们在遍历过程中把游走的任务放在迭代器上,而不是聚合上,这样简化了聚合的接口和实现,也让责任各得其所。1.适用性和优缺点1.适用性a.访问一个聚合对象的内容而无需暴露它的内部表示。b.支持对聚合对象的多种遍原创 2018-01-26 11:45:09 · 409 阅读 · 0 评论 -
设计模式之生成器模式
如果我们要出去旅游都需要制定旅游计划,包括旅游天数、定酒店等等,如果这时候你去专业的公司去定制你的旅游行程。这时候公司就如同一个生成器,根据游客需求定制一个合适的计划。我们发现旅游计划中有公共部分,那么我们设计一个大类,把所有可能会在计划中的项目都在这大类中构造创建方法。同时这个大类应该传入一个旅游计划对象,用于存储这个旅游计划。那么相对应的旅游计划类,则是一个标准的JavaBean,拥有sett原创 2018-01-25 10:52:41 · 863 阅读 · 0 评论 -
设计模式之备忘录模式
平时如果我们工作繁忙的时候都有写备忘录的习惯,如果我们认真写了备忘录的话,我们可以看看之前干了什么,之后又要干什么。而备忘录模式则是让对象返回之前的状态,例如需要将用户请求撤销,返回上一个状态,则应该使用备忘录模式。因此,备忘录的定义就是在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样就可以将该对象恢复到原先保存的状态。1.适用性和优缺点1.适用性a.必原创 2018-01-24 21:06:02 · 423 阅读 · 0 评论 -
设计模式之桥接模式
我们平时去面馆吃面,点面的时候有的人喜欢吃辣的面,有的喜欢微辣,有的喜欢无辣。对于面的种类还有的喜欢猪肉面、牛肉面等等。那么厨师肯定根据大家的点的情况进行煮。厨师肯定依据大家点的面种类,先将同类的进行煮,然后再进行添加辣的程度,这样有助于效率的提高。如果厨师一开始就煮辣的牛肉面,不辣的牛肉面。。。。。那么这样厨师肯定得忙不过来而且效率极低,可能还会被老板炒鱿鱼。而先将面先煮好,再决定辣的口味。这相原创 2018-01-24 14:47:46 · 358 阅读 · 0 评论 -
设计模式之原型模式
我们都知道多利羊吧,世界上第一个克隆生物。自从有了克隆羊的出现之后,我们对克隆的认识更加深刻。其实原型模式就是通过复制现有的实例来创建新的实例。而且在Java中,原型模式更加体现了克隆的思想。通过使用clone()方法,复制现有实例来创建新的实例。客户可以不知道现有实例是何种类的实例的情况下,制造出新的实例。1.适用性和优缺点1.适用性a.当一个系统应该独立于它的产品创建、构成和表示时原创 2018-01-24 11:39:05 · 449 阅读 · 0 评论 -
设计模式之责任链模式
如果你在公司遇到了什么问题,求助于部门经理,如果在他职责范围之内,他会帮你解决;但是如果不在部门经理职责范围内,他会递交给总经理,同样的,如果总经理能解决,他会解决,如果解决不了他会往上提交。其实这也是责任链模式的体现。通过责任链模式,你可以为某个请求创建一个对象链。每个对象依序检查次请求,并对其进行处理,或者将它传给链中的下一个对象。上述讲的,向上级提交问题也是责任链形式,比如将部门经理、总经理原创 2018-01-24 10:20:40 · 339 阅读 · 0 评论 -
设计模式之代理模式
在某些情况下,客户端代码不想或不能够直接调用被调用者,代理对象可以在客户端和目标对象之间起到中介的作用。这种情况下,客户端实际上也不关心是否准确得到该对象,它只要一个能够提供该功能的对象即可,此时就可返回对象的代理。代理可以理解为一个对象代表另一个对象来采取行动。对客户端而言,它不能分辨出代理对象与真实对象的区别,它也无须分辨代理对象和真实对象的区别。客户端的代码并不知道真正的被代理对象,客户端代原创 2018-01-23 21:29:11 · 457 阅读 · 0 评论 -
设计模式之中介者模式
生活中有一个叫做中介公司的存在,有时候确实帮我们省却了不少功夫。比如买房什么的,我们只需要跟说明我们的需求,中介会跟相应的房源联系,这省却了我们盲目地寻找,挨家挨户的看房。这就是中介这个工作存在的好处。其实,这也是我们今天要讲的中介者模式存在的作用。在没有中介者的情况下,所有的对象都需要认识其它对象。也就是说,对象之间是紧耦合的。有了中介之后,对象之间彻底解耦。就像我们有了中介之后,不需要盲目地跑原创 2018-01-23 15:08:44 · 358 阅读 · 0 评论 -
设计模式之解释器模式
假如有一天,老师给一篇文章,需要对其进行不同的处理,我们可以在一个类中利用不同方法实现,但是这个类就显得冗余。我们在设计中,有一个设计原则叫做单一责任原则,即尽可能一个类代表一个功能。那么,我们这里需要将每一种处理都提取出来定义成一个类。可能老师会让你把中文文章翻译成日文,还要翻译成英文等等,那么我们可以将每一种语言变成一个类。这样方便统一操作。这也就是解释器的操作原理,将每种语言定义成一个解释器原创 2018-01-23 10:17:26 · 405 阅读 · 0 评论 -
设计模式之装饰器模式
生活中门是大家每天都可以见到的东西,我们以木门为例,一个木门主要是由木头组成的,如果有一天为了美观我们想在木门上面添加一些木材饰品,那么我们总不能直接换一个门吧,那多浪费啊。那么我们可以先选定一些木材饰品,然后装饰上去即可,这样门通过木材饰品的修饰更加美观了,而且也不会浪费资源。因此,这个装饰品起到了完善的功能,而且门对于装饰品有选择性,比如主人喜欢哪种饰品,那么门就装饰什么饰品。其实装饰器类就如原创 2018-01-23 09:02:57 · 468 阅读 · 0 评论 -
设计模式之外观模式
在生活中,我们如果需要自己动手做菜,那么需要经历买菜-->洗菜-->切菜-->烹饪等步骤,那么如果这些步骤都是独立的类,而客户端指的是做菜的人,那么客户端需要调用每一个类里相应的函数,那么这样会造成客户端里调用的类过多,一旦需要改变步骤,那么需要改动客户端代码,这是十分不友好的设计。我们可以提供一个类来负责这些步骤的调用,而客户端只需调用这个新加类的相应方法即可,而这个类就是相当于一个门面,能够将原创 2018-01-22 09:43:28 · 466 阅读 · 1 评论 -
设计模式之适配器模式
如果我们有一个方块,有一个圆孔,并且方块的外接圆半径大于圆孔的半径,现要求在不改变这两者自身尺寸的情况下,将这两者作为一个整体。按理说,因为方块的外接圆半径大于圆孔,硬塞是塞不进去了。那么我们可以换种思路,就是设计一个物体,既要能够和圆孔合为一个整体,又能够和方块合成一个整体,就像我们手机常用的转接口一样,这样三者合为一体,那么方块和圆孔间接的合为一体了,而且就算两者发生改变了,也互不干扰,只需要原创 2018-01-22 11:17:50 · 363 阅读 · 0 评论 -
设计模式之观察者模式
观察者模式定义了对象之间的一对多依赖,这样一来,当一个对象改变状态时,它的所有依赖者都会收到通知并自动更新。观察者模式中,subject是具有状态的对象,是真正拥有数据的对象。有许多观察者依赖着subject,依赖者subject的数据,一旦数据得到更新,subject便会通知各个观察者,并让观察者自动更新。这相当于数据只由subject控制,所有观察者并不知道具体数据,它们只是等待subject原创 2018-01-21 21:16:00 · 506 阅读 · 0 评论 -
设计模式之组合模式
我们在设计过程中会碰到类树的问题,比如一个类是树根,好多类是其子树,又有好多类是子树的子树,它们的关系分布就如同一棵树的关系。这时我们声明对象都以树根类来声明,那么我们操作所有整棵树所有对象都不需要进行类型转换,可以一视同仁。组合模式允许你将对象组合成树形结构来表现"整体/部分"层次结构。组合能让客户以一致的方式处理个别对象以及对象组合。使用了组合模式,我们可以忽略对象组合和个别对象之间的差别。原创 2018-01-21 13:31:08 · 400 阅读 · 0 评论 -
设计模式之状态模式
之前讲到的命令模式是将具体操作分离出来,而这里的状态模式也是相同的思路,将每种状态分离出来,建立状态类。状态模式的描述有很多种,比如状态模式封装基于状态的行为,并将行为委托到当前状态;又比如还有状态模式定义了对象的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新等等。无论状态模式的描述怎么变化,都是讲述了将对象的多种状态独立开来,即一个类代表一种状态。原创 2018-01-20 10:26:08 · 466 阅读 · 0 评论 -
设计模式之模板方法模式
模板方法模式在一个方法中定义一个算法骨架,而将一些步骤延迟到子类中,模板方法使得子类可以在不改变算法结构的情况下,重新定义算法的某些步骤。假设一些工厂生产一些产品,虽然生产的产品不同,但有些步骤是相同的,只是部分步骤不同,那么可以使用抽象类的形式,公共步骤则在抽象类中具体写出,而不同步骤则在抽象类中以抽象方法的形式表达。等到实际产品中再具体化这些抽象方法,而子类中不需要再重复那些公共方法,这样可以原创 2018-01-20 14:19:36 · 374 阅读 · 0 评论 -
设计模式之命令模式
命令模式将“请求”封装成对象以便使用不同的请求、队列或者日志来参数化其它对象。将不同命令接口的匿名实现类作为参数传入某个方法,这个只需要方法只需要调用该对象参数的某个方法即可,并不需要关心这个被调用方法的真正实现,所以这是避免某个对象的具体实现会发生变化造成需要修改该对象所对应的类。命令模式相当于将命令从类当中分离出来。1.适用性与优缺点1.适用性:a.抽象出待执行的动作以参数化某对象原创 2018-01-19 13:18:00 · 475 阅读 · 0 评论 -
设计模式之策略模式
首先我们了解一下策略模式的定义:策略模式定义了算法族,分别封装起来,让它们之间可以互相替换,此模式让算法的变化独立于使用算法的客户。通俗来说就是定义了一堆算法族,客户需要什么算法直接使用相应的算法即可。 接下来,通过举个例子来加深对策略模式的理解。举的例子是商场打折扣的例子,一般逛商场都会看到好多种折扣,七五折、八八折什么的。那么如果将它们放在一个折扣类实现的话,等到有新的折扣的原创 2018-01-19 09:48:59 · 443 阅读 · 0 评论 -
设计模式之抽象工厂模式
工厂方法模式一文中提到工厂方法模式的缺点很明显,就是客户端与工厂类之间的耦合,而且如果有无数工厂类,那么便会出现原问题,耦合严重。现在引入抽象工厂,就是为了将客户端与工厂类分离,采用简单工厂模式的思路,再建立一个工厂类,不过这个工厂类是工厂的工厂。这样就可以让客户端的代码与被调用的对象以及工厂类分离,降低耦合。 本文仍然是电脑连接打印设备的例子。首先对于先建立一个打印设备的接口原创 2018-01-18 20:18:47 · 501 阅读 · 0 评论 -
设计模式之工厂方法模式
简单工厂模式一文中介绍了简单工厂模式的原理以及优缺点。根据简单工厂模式的特点可以知道简单工厂模式就是引入一个工厂来降低耦合,系统使用工厂类生产所有产品实例,且该工厂类决定生产哪个类的实例,即该工厂类负责所有的逻辑判断、实例创建等动作。但是,这样工厂类就过于复杂,如果不想在工厂类中实现复杂的逻辑判断,可以给工厂提供接口,然后为每个产品都设置一个工厂,所有工厂都实现工厂接口。 还是举原创 2018-01-18 19:41:08 · 481 阅读 · 0 评论 -
设计模式之简单工厂模式
如果有两个类,分别为A和B,如果A要调用B,那么最简单的方法便是直接在A用利用new创建B的对象,然后调用相应的方法即可。这样的话,A和B便是硬编码耦合了,如果B需要作出修改,那么A类也要作出相应的修改。单纯一个类调用的话,修改并不是特别多,但是如果有千千万万个类需要调用B类呢?一旦B类作出修改,那么这千千万万个类都需要作出修改,工作量极其大。那么有什么方式能够减轻工作量呢?那么就是引入一个简单工原创 2018-01-18 17:35:59 · 526 阅读 · 0 评论 -
设计模式之单例模式
我们初始学面向对象编程的时候,都是用new开始生成对象,哪里需要对象的时候直接一个new。即使几次传入构造函数的参数都是相同的,其实两个对象是不同的(当然重写equal()函数和hashcode()函数的那是例外),这样便会造成对象满天飞的情况,这样相当于栈里面的一个对象引用名都会指向一个堆里面的一个对象,这样导致堆里面出现过多重复的对象,会使性能下降。这时候,如果使用了单例模式,在相应类中声明一原创 2018-01-18 10:32:32 · 399 阅读 · 0 评论