结构类模式大PK 结构类模式包括适配器模式.桥梁模式.组合模式.装饰模式.门面模式.享元模式和代理模式.之所以称其为结构类模式,是因为他们都是通过组合类或对象产生更大结构以适应更高成层次的逻辑需求.我们来分析一下装饰模式和代理模式.装饰模式和适配器模式. 装饰模式VS代理模式 首先要说明的是装饰模式是代理模式的特殊应用,两者的共同点是有相同的接口,不同点事代理模式着重对代理过程的控制,而装饰模式则是对类的功能进行加强或减弱,着重…

结构类模式包括: 适配器模式 桥梁模式 组合模式 装饰模式 门面模式 享元模式 代理模式 结构类模式着重于如何建立一个软件结构 为什么叫结构类模式呢? 因为他们都是通过组合类或对象产生更大结构以适应更高层次的逻辑需求. 结构型模式是为解决怎样组装现有的类,设计他们的交互方式,从而达到实现一定的功能的目的. 代理模式VS装饰模式 首先,装饰模式就是代理模式的一个特殊应用,两者的共同点是都具有相同的接口,不同点是代理模式着重对代理过程的控制,而装饰模式则是对类的功能进行加强或减弱,着重类的功能变化.…

定义 为子系统中的一组接口提供一个一致的界面,定义一个高层接口,这个接口使得这一子系统更加容易使用. UML 优点 对客户屏蔽了其子系统组件,因而减少了客户处理对象的数目,并使得子系统实用起来更方便. 它实现了子系统与客户之间的松耦合关系,而子系统内部的功能组件往往是紧耦合的.松耦合关系使得子系统的组件变化不会影响到它的客户. Facade模式有助于建立层次结构系统,也有助于对对象之间的依赖关系分层. Facade模式还可以消除复杂的循环依赖关系,这一点在客户程序与子系统是分别实现的时候尤为重要…

一.动机(Motivate) 在软件系统开发的过程中,当组件的客户(即外部接口,或客户程序)和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的演化,这种过多的耦合面临很多变化的挑战.如何简化外部客户程序和系统间的交互接口?如何将外部客户程序的演化和内部子系统的变化之间的依赖相互解耦? 二.意图(Intent) 为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用. ——<设计模式>GoF 三.结构图(Structure…

定义 动态地将责任附加到对象上.若要扩展功能,装饰者提供了比继承更有弹性的替代方案. 它是通过创建一个包装对象,也就是装饰来包裹真实的对象. 特点 装饰对象和真实对象有相同的接口.这样客户端对象就能以和真实对象相同的方式和装饰对象交互. 装饰对象包含一个真实对象的引用(reference) 装饰对象接受所有来自客户端的请求.它把这些请求转发给真实的对象. 装饰对象可以在转发这些请求以前或以后增加一些附加功能.这样就确保了在运行时,不用修改给定对象的结构就可以在外部增加附加的功能.在面向对象的设计…

定义 将对象组合成树形结构以表示“部分整体”的层次结构.组合模式使得用户对单个对象和组合对象的使用具有一致性. 有时候又叫做部分-整体模式,它使我们树型结构的问题中,模糊了简单元素和复杂元素的概念,客户程序可以像处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦. 比较常见的有文件系统:文件系统由目录和文件组成.每个目录都可以装内容.目录的内容可以是文件,也可以是目录.按照这种方式,计算机的文件系统就是以递归结构来组织的.如果你想要描述这样的数据结构,那么你可以使用组合模式…

定义 为其他对象提供一种代理以控制对这个对象的访问. 代理模式也叫做委托模式,它是一项基本设计技巧.许多其他的模式,如状态模式.策略模式.访问者模式本质上是在更特殊的场合采用了委托模式,而且在日常的应用中,代理模式可以提供非常好的访问控制. 代理类负责对真实角色的应用,把所有抽象主题类定义的方法限制委托给真实主题角色实现,并且在真实主题角色处理完毕前后做预处理和善后处理工作. 基本上可以理解为:代理类持有实际操作对象的引用,通过公开方法将这些引用的方法提供给其它类调用. 和其它模式的区别 和适配…

定义 运用共享技术有效的支持大量细粒度的对象. 两个状态 内蕴状态存储在享元内部,不会随环境的改变而有所不同,是可以共享的. 外蕴状态是不可以共享的,它随环境的改变而改变的,因此外蕴状态是由客户端来保持(因为环境的变化是由客户端引起的). 和对象池的区别 对象池主要解决对象的复用问题,池中的每个对象都是可以替换的,从池中获取对象A和获取对象B对客户端而言都是一样的. 享元模式主要解决对象的共享问题,建立多个细粒度的可以进行共享的对象是其关注的重点. UML 优点 减少运行时对象实例的个数,节省内…

定义 将抽象化(Abstraction)与实现化(Implementation)脱耦,使得二者可以独立地变化. 在软件系统中,某些类型由于自身的逻辑,它具有两个或多个维度的变化,那么如何应对这种“多维度的变化”?如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化,而又不引入额外的复杂度?这就要使用Bridge模式. 我们来思考一下 如果我们需要做一个发送消息的系统,发送方式有站内消息和邮件两种,发送类型有普通和加急两种,我想大家都会很自然的想到下面的做法: //消息接口 IMess…

定义 适配器模式把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作. 类适配器模式 使用继承的方式实现没有提供的接口从而达到适配到新系统的需求. 对象适配器模式 使用聚合的方式提供新系统需要的所有接口. UML 优点 更好的复用性:系统需要使用现有的类,而此类的接口不符合系统的需要.那么通过适配器模式就可以让这些功能得到更好的复用. 更好的扩展性:在实现适配器功能的时候,可以调用自己开发的功能,从而自然地扩展系统的功能. 将目标类和适配者类…