北京住房建设官方网站,seo推广的公司,免费网络课程,上海公关公司排行榜一、什么是设计模式
设计模式#xff08;Design pattern#xff09;是一套被反复使用、多数人知晓的、经过分类编目的、代码设计…一、什么是设计模式
设计模式Design pattern是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问设计模式于己于他人于系统都是多赢的设计模式使代码编制真正工程化设计模式是软件工程的基石如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题每种模式在现在中都有相应的原理来与之对应每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的核心解决方案这也是它能被广泛应用的原因。简单说
比较常用的设计模式有十种单例模式、策略模式、代理模式、观察者模式、装饰模式、适配器模式、命令模式、组合模式、简单工厂模式、模板方法模式
模式在某些场景下针对某类问题的某种通用的解决方案。
场景项目所在的环境
问题约束条件项目目标等
解决方案通用、可复用的设计解决约束达到目标。
二、设计模式的三个分类
创建型模式对象实例化的模式创建型模式用于解耦对象的实例化过程。作用以代码复用为目标的技术专为创建高效繁复的对象而设计的。它的主要目的是减少创建对象的数量减少开发时间减少代码的复杂度提高软件质量和可维护性。
结构型模式把类或对象结合在一起形成一个更大的结构。作用改变代码结构来达到解耦的目的使得我们的代码容易维护和扩展
行为型模式类和对象如何交互及划分责任和算法。作用用于描述程序在运行时复杂的流程控制即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务它涉及算法与对象间职责的分配。
如下图所示 三、各分类中模式的关键点
单例模式某个类只能有一个实例提供一个全局的访问点。
简单工厂一个工厂类根据传入的参量决定创建出那一种产品类的实例。
工厂方法定义一个创建对象的接口让子类决定实例化那个类。
抽象工厂创建相关或依赖对象的家族而无需明确指定具体类。
建造者模式封装一个复杂对象的构建过程并可以按步骤构造。
原型模式通过复制现有的实例来创建新的实例。 适配器模式将一个类的方法接口转换成客户希望的另外一个接口。
组合模式将对象组合成树形结构以表示“”部分-整体“”的层次结构。
装饰模式动态的给对象添加新的功能。
代理模式为其他对象提供一个代理以便控制这个对象的访问。
亨元蝇量模式通过共享技术来有效的支持大量细粒度的对象。
外观模式对外提供一个统一的方法来访问子系统中的一群接口。
桥接模式将抽象部分和它的实现部分分离使它们都可以独立的变化。 模板模式定义一个算法结构而将一些步骤延迟到子类实现。
解释器模式给定一个语言定义它的文法的一种表示并定义一个解释器。
策略模式定义一系列算法把他们封装起来并且使它们可以相互替换。
状态模式允许一个对象在其对象内部状态改变时改变它的行为。
观察者模式对象间的一对多的依赖关系。
备忘录模式在不破坏封装的前提下保持对象的内部状态。
中介者模式用一个中介对象来封装一系列的对象交互。
命令模式将命令请求封装为一个对象使得可以用不同的请求来进行参数化。
访问者模式在不改变数据结构的前提下增加作用于一组对象元素的新功能。
责任链模式将请求的发送者和接收者解耦使的多个对象都有处理这个请求的机会。
迭代器模式一种遍历访问聚合对象中各个元素的方法不暴露该对象的内部结构。 四、概说23种设计模式
1.单例模式
单例模式它的定义就是确保某一个类只有一个实例并且提供一个全局访问点。
单例模式具备典型的3个特点1、只有一个实例。 2、自我实例化。 3、提供全局访问点。 因此当系统中只需要一个实例对象或者系统中只允许一个公共访问点除了这个公共访问点外不能通过其他访问点访问该实例时可以使用单例模式。
单例模式的主要优点就是节约系统资源、提高了系统效率同时也能够严格控制客户对它的访问。也许就是因为系统中只有一个实例这样就导致了单例类的职责过重违背了“单一职责原则”同时也没有抽象类所以扩展起来有一定的困难。其UML结构图非常简单就只有一个类如下图 2.工厂方法模式
作为抽象工厂模式的孪生兄弟工厂方法模式定义了一个创建对象的接口但由子类决定要实例化的类是哪一个也就是说工厂方法模式让实例化推迟到子类。
工厂方法模式非常符合“开闭原则”当需要增加一个新的产品时我们只需要增加一个具体的产品类和与之对应的具体工厂即可无须修改原有系统。同时在工厂方法模式中用户只需要知道生产产品的具体工厂即可无须关系产品的创建过程甚至连具体的产品类名称都不需要知道。虽然他很好的符合了“开闭原则”但是由于每新增一个新产品时就需要增加两个类这样势必会导致系统的复杂度增加。其UML结构图 3.抽象工厂模式
所谓抽象工厂模式就是提供一个接口用于创建相关或者依赖对象的家族而不需要明确指定具体类。他允许客户端使用抽象的接口来创建一组相关的产品而不需要关系实际产出的具体产品是什么。这样一来客户就可以从具体的产品中被解耦。它的优点是隔离了具体类的生成使得客户端不需要知道什么被创建了而缺点就在于新增新的行为会比较麻烦因为当添加一个新的产品对象时需要更加需要更改接口及其下所有子类。其UML结构图如下 4.建造者模式
对于建造者模式而已它主要是将一个复杂对象的构建与表示分离使得同样的构建过程可以创建不同的表示。适用于那些产品对象的内部结构比较复杂。
建造者模式将复杂产品的构建过程封装分解在不同的方法中使得创建过程非常清晰能够让我们更加精确的控制复杂产品对象的创建过程同时它隔离了复杂产品对象的创建和使用使得相同的创建过程能够创建不同的产品。但是如果某个产品的内部结构过于复杂将会导致整个系统变得非常庞大不利于控制同时若几个产品之间存在较大的差异则不适用建造者模式毕竟这个世界上存在相同点大的两个产品并不是很多所以它的使用范围有限。其UML结构图 5.原型模式
在我们应用程序可能有某些对象的结构比较复杂但是我们又需要频繁的使用它们如果这个时候我们来不断的新建这个对象势必会大大损耗系统内存的这个时候我们需要使用原型模式来对这个结构复杂又要频繁使用的对象进行克隆。所以原型模式就是用原型实例指定创建对象的种类并且通过复制这些原型创建新的对象。
它主要应用与那些创建新对象的成本过大时。它的主要优点就是简化了新对象的创建过程提高了效率同时原型模式提供了简化的创建结构。UML结构图 模式结构原型模式包含如下角色Prototype抽象原型类ConcretePrototype具体原型类Client客户类
6.适配器模式
在我们的应用程序中我们可能需要将两个不同接口的类来进行通信在不修改这两个的前提下我们可能会需要某个中间件来完成这个衔接的过程。这个中间件就是适配器。所谓适配器模式就是将一个类的接口转换成客户期望的另一个接口。它可以让原本两个不兼容的接口能够无缝完成对接。
作为中间件的适配器将目标类和适配者解耦增加了类的透明性和可复用性。 适配器模式包含如下角色Target目标抽象类Adapter适配器类Adaptee适配者类Client客户类
7.桥接模式
如果说某个系统能够从多个角度来进行分类且每一种分类都可能会变化那么我们需要做的就是讲这多个角度分离出来使得他们能独立变化减少他们之间的耦合这个分离过程就使用了桥接模式。所谓桥接模式就是讲抽象部分和实现部分隔离开来使得他们能够独立变化。
桥接模式将继承关系转化成关联关系封装了变化完成了解耦减少了系统中类的数量也减少了代码量。 桥接模式包含如下角色Abstraction抽象类RefinedAbstraction扩充抽象类Implementor实现类接口ConcreteImplementor具体实现类
桥接模式示例//假设系统接口
public interface DrawApi {public void DrawCircle(int redis,int x, int y);
}
//抽离的实现类 1
class RedisCircle implements DrawApi{Overridepublic void DrawCircle(int redis, int x, int y) {System.out.println(画出红色的圆 redis || x || y);}
}
//抽离的实现类 2
class GreenCircle implements DrawApi{Overridepublic void DrawCircle(int redis, int x, int y) {System.out.println(画出绿色的圆 redis || x || y);}
}
//桥接系统方法
abstract class Shape {//将系统类桥接到Shape中protected DrawApi drawApi;public Shape(DrawApi drawApi){this.drawApi drawApi;}public abstract void draw();
}//业务实现
class Circle extends Shape{private int x,y,redius;public Circle(int x,int y,int redius,DrawApi drawAPI) {super(drawAPI);this.xx;this.y y;this.redius redius;}//重写Overridepublic void draw() {drawApi.DrawCircle(x,y,redius);}}
class test{public static void main(String[] args) {Shape redCircle new Circle(100,100, 10,new RedisCircle());Shape greenCircle new Circle(100,100, 10,new GreenCircle());//调用重写方法redCircle.draw();greenCircle.draw();}
}
8.组合模式
组合模式组合多个对象形成树形结构以表示“整体-部分”的结构层次。它定义了如何将容器对象和叶子对象进行递归组合使得客户在使用的过程中无须进行区分可以对他们进行一致的处理。在使用组合模式中需要注意一点也是组合模式最关键的地方叶子对象和组合对象实现相同的接口。这就是组合模式能够将叶子节点和对象节点进行一致处理的原因。
虽然组合模式能够清晰地定义分层次的复杂对象也使得增加新构件也更容易但是这样就导致了系统的设计变得更加抽象如果系统的业务规则比较复杂的话使用组合模式就有一定的挑战了。 模式结构组合模式包含如下角色Component: 抽象构件Leaf: 叶子构件Composite: 容器构件Client: 客户类
9.装饰模式
我们可以通过继承和组合的方式来给一个对象添加行为虽然使用继承能够很好拥有父类的行为但是它存在几个缺陷一、对象之间的关系复杂的话系统变得复杂不利于维护。二、容易产生“类爆炸”现象。三、是静态的。在这里我们可以通过使用装饰者模式来解决这个问题。
装饰者模式动态地将责任附加到对象上。若要扩展功能装饰者提供了比继承更加有弹性的替代方案。虽然装饰者模式能够动态将责任附加到对象上但是他会产生许多的细小对象增加了系统的复杂度。 模式结构装饰模式包含如下角色Component: 抽象构件ConcreteComponent: 具体构件Decorator: 抽象装饰类ConcreteDecorator: 具体装饰类 10.外观模式
我们都知道类与类之间的耦合越低那么可复用性就越好如果两个类不必彼此通信那么就不要让这两个类发生直接的相互关系如果需要调用里面的方法可以通过第三者来转发调用。外观模式非常好的诠释了这段话。外观模式提供了一个统一的接口用来访问子系统中的一群接口。它让一个应用程序中子系统间的相互依赖关系减少到了最少它给子系统提供了一个简单、单一的屏障客户通过这个屏障来与子系统进行通信。通过使用外观模式使得客户对子系统的引用变得简单了实现了客户与子系统之间的松耦合。但是它违背了“开闭原则”因为增加新的子系统可能需要修改外观类或客户端的源代码。 外观模式包含如下角色Facade: 外观角色SubSystem:子系统角色
11.亨元模式
在一个系统中对象会使得内存占用过多特别是那些大量重复的对象这就是对系统资源的极大浪费。享元模式对对象的重用提供了一种解决方案它使用共享技术对相同或者相似对象实现重用。享元模式就是运行共享技术有效地支持大量细粒度对象的复用。系统使用少量对象,而且这些都比较相似状态变化小可以实现对象的多次复用。这里有一点要注意享元模式要求能够共享的对象必须是细粒度对象。享元模式通过共享技术使得系统中的对象个数大大减少了同时享元模式使用了内部状态和外部状态同时外部状态相对独立不会影响到内部状态所以享元模式能够使得享元对象在不同的环境下被共享。同时正是分为了内部状态和外部状态享元模式会使得系统变得更加复杂同时也会导致读取外部状态所消耗的时间过长。 享元模式包含如下角色Flyweight: 抽象享元类ConcreteFlyweight: 具体享元类UnsharedConcreteFlyweight: 非共享具体享元类FlyweightFactory: 享元工厂类
12.代理模式 代理模式就是给一个对象提供一个代理并由代理对象控制对原对象的引用。它使得客户不能直接与真正的目标对象通信。代理对象是目标对象的代表其他需要与这个目标对象打交道的操作都是和这个代理对象在交涉。
代理对象可以在客户端和目标对象之间起到中介的作用这样起到了的作用和保护了目标对象的同时也在一定程度上面减少了系统的耦合度。 代理模式包含如下角色 Subject: 抽象主题角色 Proxy: 代理主题角色 RealSubject: 真实主题角色
public interface Music {public void dispaly();
}class ReadMusic implements Music{private String fileName;//, 生命周期在创建是就读取public ReadMusic(String fileName) {this.fileName fileName;loadFile();}//加载文件public void loadFile(){System.out.println(加载文件...............);}Overridepublic void dispaly() {System.out.println(播放 fileName);}
}
//代理 ReadMusic
class MusicProxy implements Music{private ReadMusic readMusic;String filenames;public MusicProxy(String filenames) {this.filenames filenames;}Overridepublic void dispaly() {if(readMusic null){readMusic new ReadMusic(filenames);}readMusic.dispaly();}
}
class testProxyDemo{public static void main(String[] args) {//理解为将代理权交给proxyMusic music new MusicProxy(D:/123.png);music.dispaly();System.out.println(第二次请求被代理对象已经持有文件所以不用再请示);music.dispaly();}
}
13.访问者模式
访问者模式俗称23大设计模式中最难的一个。除了结构复杂外理解也比较难。在我们软件开发中我们可能会对同一个对象有不同的处理如果我们都做分别的处理将会产生灾难性的错误。对于这种问题访问者模式提供了比较好的解决方案。访问者模式即表示一个作用于某对象结构中的各元素的操作它使我们可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
访问者模式的目的是封装一些施加于某种数据结构元素之上的操作一旦这些操作需要修改的话接受这个操作的数据结构可以保持不变。为不同类型的元素提供多种访问操作方式且可以在不修改原有系统的情况下增加新的操作方式。同时我们还需要明确一点那就是访问者模式是适用于那些数据结构比较稳定的因为他是将数据的操作与数据结构进行分离了如果某个系统的数据结构相对稳定但是操作算法易于变化的话就比较适用适用访问者模式因为访问者模式使得算法操作的增加变得比较简单了。 访问者模式包含如下角色Vistor: 抽象访问者ConcreteVisitor: 具体访问者Element: 抽象元素ConcreteElement: 具体元素 ObjectStructure: 对象结构
14.模板模式
有些时候我们做某几件事情的步骤都差不多仅有那么一小点的不同在软件开发的世界里同样如此如果我们都将这些步骤都一一做的话费时费力不讨好。所以我们可以将这些步骤分解、封装起来然后利用继承的方式来继承即可当然不同的可以自己重写实现嘛这就是模板方法模式提供的解决方案。
所谓模板方法模式就是在一个方法中定义一个算法的骨架而将一些步骤延迟到子类中。模板方法使得子类可以在不改变算法结构的情况下重新定义算法中的某些步骤。
模板方法模式就是基于继承的代码复用技术的。在模板方法模式中我们可以将相同部分的代码放在父类中而将不同的代码放入不同的子类中。也就是说我们需要声明一个抽象的父类将部分逻辑以具体方法以及具体构造函数的形式实现然后声明一些抽象方法让子类来实现剩余的逻辑不同的子类可以以不同的方式来实现这些逻辑。所以模板方法的模板其实就是一个普通的方法只不过这个方法是将算法实现的步骤封装起来的。 模板方法模式包含如下角色AbstractClass: 抽象类 ConcreteClass: 具体子类
15.策略模式 我们知道一件事可能会有很多种方式来实现它但是其中总有一种最高效的方式在软件开发的世界里面同样如此我们也有很多中方法来实现一个功能但是我们需要一种简单、高效的方式来实现它使得系统能够非常灵活这就是策略模式。
所以策略模式就是定义了算法族分别封装起来让他们之前可以互相转换此模式然该算法的变化独立于使用算法的客户。
在策略模式中它将这些解决问题的方法定义成一个算法群每一个方法都对应着一个具体的算法这里的一个算法我就称之为一个策略。虽然策略模式定义了算法但是它并不提供算法的选择即什么算法对于什么问题最合适这是策略模式所不关心的所以对于策略的选择还是要客户端来做。客户必须要清楚的知道每个算法之间的区别和在什么时候什么地方使用什么策略是最合适的这样就增加客户端的负担。
同时策略模式也非常完美的符合了“开闭原则”用户可以在不修改原有系统的基础上选择算法或行为也可以灵活地增加新的算法或行为。但是一个策略对应一个类将会是系统产生很多的策略类。 策略模式包含如下角色Context: 环境类Strategy: 抽象策略类ConcreteStrategy: 具体策略类
16.状态模式 在很多情况下我们对象的行为依赖于它的一个或者多个变化的属性这些可变的属性我们称之为状态也就是说行为依赖状态即当该对象因为在外部的互动而导致他的状态发生变化从而它的行为也会做出相应的变化。对于这种情况我们是不能用行为来控制状态的变化而应该站在状态的角度来思考行为即是什么状态就要做出什么样的行为。这个就是状态模式。
所以状态模式就是允许对象在内部状态发生改变时改变它的行为对象看起来好像修改了它的类。
在状态模式中我们可以减少大块的if…else语句它是允许态转换逻辑与状态对象合成一体但是减少if…else语句的代价就是会换来大量的类所以状态模式势必会增加系统中类或者对象的个数。
同时状态模式是将所有与某个状态有关的行为放到一个类中并且可以方便地增加新的状态只需要改变对象状态即可改变对象的行为。但是这样就会导致系统的结构和实现都会比较复杂如果使用不当就会导致程序的结构和代码混乱不利于维护。 状态模式包含如下角色Context: 环境类State: 抽象状态类ConcreteState: 具体状态类
17.观察者模式
何谓观察者模式观察者模式定义了对象之间的一对多依赖关系这样一来当一个对象改变状态时它的所有依赖者都会收到通知并且自动更新。
在这里发生改变的对象称之为观察目标而被通知的对象称之为观察者。一个观察目标可以对应多个观察者而且这些观察者之间没有相互联系所以么可以根据需要增加和删除观察者使得系统更易于扩展。所以观察者提供了一种对象设计让主题和观察者之间以松耦合的方式结合。 观察者模式包含如下角色Subject: 目标ConcreteSubject: 具体目标Observer: 观察者ConcreteObserver: 具体观察者
18.备忘录模式 后悔药人人都想要但是事实却是残酷的根本就没有后悔药可买但是也不仅如此在软件的世界里就有后悔药备忘录模式就是一种后悔药它给我们的软件提供后悔药的机制通过它可以使系统恢复到某一特定的历史状态。
所谓备忘录模式就是在不破坏封装的前提下捕获一个对象的内部状态并在该对象之外保存这个状态这样可以在以后将对象恢复到原先保存的状态。它实现了对信息的封装使得客户不需要关心状态保存的细节。保存就要消耗资源所以备忘录模式的缺点就在于消耗资源。如果类的成员变量过多势必会占用比较大的资源而且每一次保存都会消耗一定的内存。 备忘录模式包含如下角色Originator: 原发器Memento: 备忘录Caretaker: 负责人
19.中介者模式 租房各位都有过的经历吧在这个过程中中介结构扮演着很重要的角色它在这里起到一个中间者的作用给我们和房主互相传递信息。在外面软件的世界里同样需要这样一个中间者。在我们的系统中有时候会存在着对象与对象之间存在着很强、复杂的关联关系如果让他们之间有直接的联系的话必定会导致整个系统变得非常复杂而且可扩展性很差在前面我们就知道如果两个类之间没有不必彼此通信我们就不应该让他们有直接的关联关系如果实在是需要通信的话我们可以通过第三者来转发他们的请求。同样这里我们利用中介者来解决这个问题。
所谓中介者模式就是用一个中介对象来封装一系列的对象交互中介者使各对象不需要显式地相互引用从而使其耦合松散而且可以独立地改变它们之间的交互。在中介者模式中中介对象用来封装对象之间的关系各个对象可以不需要知道具体的信息通过中介者对象就可以实现相互通信。它减少了对象之间的互相关系提供了系统可复用性简化了系统的结构。 在中介者模式中各个对象不需要互相知道了解他们只需要知道中介者对象即可但是中介者对象就必须要知道所有的对象和他们之间的关联关系正是因为这样就导致了中介者对象的结构过于复杂承担了过多的职责同时它也是整个系统的核心所在它有问题将会导致整个系统的问题。所以如果在系统的设计过程中如果出现“多对多”的复杂关系群时千万别急着使用中介者模式而是要仔细思考是不是您设计的系统存在问题。 Mediator: 抽象中介者ConcreteMediator: 具体中介者Colleague: 抽象同事类ConcreteColleague: 具体同事类
20.迭代器模式
对于迭代在编程过程中我们经常用到能够游走于聚合内的每一个元素同时还可以提供多种不同的遍历方式这就是迭代器模式的设计动机。在我们实际的开发过程中我们可能会需要根据不同的需求以不同的方式来遍历整个对象但是我们又不希望在聚合对象的抽象接口中充斥着各种不同的遍历操作于是我们就希望有某个东西能够以多种不同的方式来遍历一个聚合对象这时迭代器模式出现了。
何为迭代器模式所谓迭代器模式就是提供一种方法顺序访问一个聚合对象中的各个元素而不是暴露其内部的表示。迭代器模式是将迭代元素的责任交给迭代器而不是聚合对象我们甚至在不需要知道该聚合对象的内部结构就可以实现该聚合对象的迭代。
通过迭代器模式使得聚合对象的结构更加简单它不需要关注它元素的遍历只需要专注它应该专注的事情这样就更加符合单一职责原则了。 迭代器模式包含如下角色Iterator: 抽象迭代器ConcreteIterator: 具体迭代器Aggregate: 抽象聚合类ConcreteAggregate: 具体聚合类
21.解释器模式
所谓解释器模式就是定义语言的文法并且建立一个解释器来解释该语言中的句子。解释器模式描述了如何构成一个简单的语言解释器主要应用在使用面向对象语言开发的编译器中。它描述了如何为简单的语言定义一个文法如何在该语言中表示一个句子以及如何解释这些句子。 解释器模式包含如下角色AbstractExpression: 抽象表达式TerminalExpression: 终结符表达式NonterminalExpression: 非终结符表达式Context: 环境类Client: 客户类
22.命令模式 有些时候我们想某个对象发送一个请求但是我们并不知道该请求的具体接收者是谁具体的处理过程是如何的们只知道在程序运行中指定具体的请求接收者即可对于这样将请求封装成对象的我们称之为命令模式。所以命令模式将请求封装成对象以便使用不同的请求、队列或者日志来参数化其他对象。同时命令模式支持可撤销的操作。
命令模式可以将请求的发送者和接收者之间实现完全的解耦发送者和接收者之间没有直接的联系发送者只需要知道如何发送请求命令即可其余的可以一概不管甚至命令是否成功都无需关心。同时我们可以非常方便的增加新的命令但是可能就是因为方便和对请求的封装就会导致系统中会存在过多的具体命令类。 命令模式包含如下角色Command: 抽象命令类ConcreteCommand: 具体命令类Invoker: 调用者Receiver: 接收者Client:客户类
23.责任链模式
职责链模式描述的请求如何沿着对象所组成的链来传递的。它将对象组成一条链发送者将请求发给链的第一个接收者并且沿着这条链传递直到有一个对象来处理它或者直到最后也没有对象处理而留在链末尾端。
避免请求发送者与接收者耦合在一起让多个对象都有可能接收请求将这些对象连接成一条链并且沿着这条链传递请求直到有对象处理它为止这就是职责链模式。在职责链模式中使得每一个对象都有可能来处理请求从而实现了请求的发送者和接收者之间的解耦。同时职责链模式简化了对象的结构它使得每个对象都只需要引用它的后继者即可而不必了解整条链这样既提高了系统的灵活性也使得增加新的请求处理类也比较方便。但是在职责链中我们不能保证所有的请求都能够被处理而且不利于观察运行时特征。 职责链模式包含如下角色Handler: 抽象处理者ConcreteHandler: 具体处理者Client: 客户类
