设计模式-调停者

合集下载

《大话设计模式》java代码

《大话设计模式》java代码

《⼤话设计模式》java代码01 简单⼯⼚模式02 策略模式 (Strategy) 它定义了算法家族,分别封装起来,让他们之间可以互相替换,此模式让算法的变化,不会影响到使⽤算法的客户03 单⼀职责原则 就⼀个类⽽⾔,应该仅有⼀个引起它变化的原因【ASD】04 开放-封闭原则 软件的实体(类,模块等),应该可以扩展,但是不可以修改05 依赖倒转原则 ⾼层模块不应该依赖低层模块,两者都应该依赖其抽象;抽象(接⼝,抽象类等)不应该依赖于细节(实现类等);细节应该要依赖于抽象 ⾥⽒代换原则: ⼦类必须能够替换掉他们⽗亲的类型06 装饰模式 动态的给⼀个对象添加⼀些额外的职责07 代理模式 为其他对象提供⼀种代理以控制对这个对象的访问 例⼦:⼀,远程代理WebService,⼆,虚拟代理,三,安全代理08 ⼯⼚⽅法模式 定义⼀个⽤于创建对象的接⼝,让⼦类决定实例化哪⼀个类。

该⽅式使⼀个类的实例化延迟到⼦类09 原型模式 ⽤原型实例制定创建对象的种类,并通过拷贝这些原型实例创建新的对象10 模板⽅法模式 定义⼀个操作中的算法的⾻架,⽽将⼀些步骤延迟到⼦类中去。

模板⽅法使得⼦类可以不改变⼀个算法的结构即可重定义该算法的某些特定的步骤11 迪⽶特法则(最少知识原则) 如果两个类不必彼此直接通信,那么这两个类就不应当发⽣直接的相互作⽤,如果其中⼀个类需要调⽤另⼀个类的某⼀个⽅法的时候,可以通过第三者转发这个调⽤12 外观模式 为⼦系统中的⼀组接⼝提供⼀个⼀致的界⾯,此模式定义了⼀个⾼层接⼝,该接⼝使得这⼀⼦系统更加容易使⽤13 建造者模式 将⼀个复杂的对象的构建与它的表⽰分离,使得同样的构建过程可以创建不同的表⽰14 观察者模式(发布-订阅模式 Publish/Subscribe) 定义了⼀种⼀对多的依赖关系,让多个观察者对象同时监听⼀个主题对象.这个主体对象在状态发⽣变化时候会通知所有观察者对戏那个,使他们能够⾃动更新⾃⼰.(委托事件)15 抽象⼯⼚模式 提供⼀个创建⼀系列相关或相互依赖的对象的接⼝,⽽⽆需指定他们具体的类(反射技术)16 状态模式 当⼀个对象的内在状态改变时允许改变其⾏为,这个对象看起来像是改变了其类. 状态模式主要解决的是当控制⼀个对象状态转换的条件表达式过于复杂的情况,把状态的判断逻辑转移到表⽰不同状态的⼀系列类当众,可以把复杂的判断逻辑简化.17 适配器模式 将⼀个类的接⼝转换成客户希望那个的另外的⼀个接⼝.Adapter模式使得原本接⼝不兼容⽽不能⼀起⼯作的那些类可以⼀起⼯作. 18 备忘录模式 在不破坏封装性前提下,捕获⼀个对象的内部状态,便在该对象之外保存这个状态,这样以后就可以将该对象恢复到原先保存的状态19 组合模式 将对象组合成树形结构以表⽰"部分-整体"的层次结构.组合模式使得⽤户对单个对象和组合对象具有⼀致性.20 迭代器模式 提供⼀种⽅法顺序访问⼀个聚合对象中的各个元素,⽽⼜不暴露该对象的内部表⽰21 单例模式 保证⼀个类仅有⼀个实例,并提供⼀个访问它的全局访问点 合成/聚合复⽤原则 尽量使⽤合成/聚合,尽量不要使⽤类继承22 桥接模式 将抽象部分和实现部分分离,使他们可以独⽴地变化23 命令模式 将⼀个请求封装为⼀个对象,从⽽使你可⽤不同的请求对客户进⾏参数化,对请求排队或记录请求⽇志,以及⽀持可撤销操作.24 职责链模式 使多个对象都有机会处理请求,从⽽避免请求的发送者和接收者之间的耦合关系,将这个对象练成⼀条链,并沿着这条链传递该请求,直到有⼀个对象处理它为⽌.25 中介者模式(调停者模式) ⽤⼀个中介对象来封装⼀系列的对象交互.中介者使各种对象不需要显式地相互作⽤,从⽽使其耦合松散,⽽且可以独⽴地改变他们之间的交互 26 享元模式 利⽤共享技术有效地⽀持⼤量的细粒度的对象27 解释器模式28 访问者模式。

深入浅出设计模式(中文版)

深入浅出设计模式(中文版)

{ public static void main(String[] args) { try{ Driver driver = new BenzDriver(); Car car = driver.driverCar(); car.drive(); } …… } 可以看出工厂方法的加入,使得对象的数量成倍增长。当产品种类非常多时,会出现大 量的与之对应的工厂对象,这不是我们所希望的。因为如果不能避免这种情况,可以考虑使 用简单工厂模式与工厂方法模式相结合的方式来减少工厂类:即对于产品树上类似的种类 (一般是树的叶子中互为兄弟的)使用简单工厂模式来实现。 五、小结 工厂方法模式仿佛已经很完美的对对象的创建进行了包装, 使得客户程序中仅仅处理抽 象产品角色提供的接口。 那我们是否一定要在代码中遍布工厂呢?大可不必。 也许在下面情 况下你可以考虑使用工厂方法模式: 1) 当客户程序不需要知道要使用对象的创建过程。 2) 客户程序使用的对象存在变动的可能,或者根本就不知道使用哪一个具体的对象。 简单工厂模式与工厂方法模式真正的避免了代码的改动了?没有。在简单工厂模式中, 新产品的加入要修改工厂角色中的判断语句; 而在工厂方法模式中, 要么将判断逻辑留在抽 象工厂角色中,要么在客户程序中将具体工厂角色写死(就象上面的例子一样) 。而且产品 对象创建条件的改变必然会引起工厂角色的修改。 面对这种情况,Java 的反射机制与配置文件的巧妙结合突破了限制——这在 Spring 中 完美的体现了出来。 六、抽象工厂模式 先来认识下什么是产品族: 位于不同产品等级结构中,功能相关联的产品组成的家族。 还是让我们用一个例子来形象地说明一下吧。
这便是简单工厂模式了。怎么样,使用起来很简单吧?那么它带来了什么好处呢? 首先,使用了简单工厂模式后,我们的程序不在“有病”,更加符合现实中的情况;而且 客户端免除了直接创建产品对象的责任,而仅仅负责“消费”产品(正如暴发户所为) 。 下面我们从开闭原则(对扩展开放;对修改封闭)上来分析下简单工厂模式。当暴发户 增加了一辆车的时候, 只要符合抽象产品制定的合同, 那么只要通知工厂类知道就可以被客 户使用了。所以对产品部分来说,它是符合开闭原则的;但是工厂部分好像不太理想,因为 每增加一辆车, 都要在工厂类中增加相应的业务逻辑或者判断逻辑, 这显然是违背开闭原则 的。可想而知对于新产品的加入,工厂类是很被动的。对于这样的工厂类(在我们的例子中 是为司机师傅) ,我们称它为全能类或者上帝类。 我们举的例子是最简单的情况, 而在实际应用中, 很可能产品是一个多层次的树状结构。 由于简单工厂模式中只有一个工厂类来对应这些产品,所以这可能会把我们的上帝累坏了, 也累坏了我们这些程序员:( 于是工厂方法模式作为救世主出现了。 四、工厂方法模式 工厂方法模式去掉了简单工厂模式中工厂方法的静态属性, 使得它可以被子类继承。 这 样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分 担。 你应该大致猜出了工厂方法模式的结构,来看下它的组成: 1) 抽象工厂角色: 这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须 实现的接口或者必须继承的父类。在 java 中它由抽象类或者接口来实现。 2) 具体工厂角色: 它含有和具体业务逻辑有关的代码。 由应用程序调用以创建对应的具体 产品的对象。

中介者模式调停者Mediator行为型设计模式(二十一)

中介者模式调停者Mediator行为型设计模式(二十一)

中介者模式调停者Mediator行为型设计模式(二十一)中介者模式(Mediator)调度、调停意图用一个中介对象(中介者)来封装一系列的对象交互,中介者使各对象不需要显式地相互引用,从而使其耦合松散而且可以独立地改变它们之间的交互。

中介者模式又称为调停者模式。

面向对象的程序设计中,我们通常将功能进行分解,按照职责以类为维度进行划分,也就是使用时功能最终将分布在多个对象中并且我们会尽可能的保持对象功能的单一(单一职责原则)相对于对象的单一职责来说,任何的系统或者模块的功能却并不会单一,往往都是有多个对象交互协作来实现所有的功能对象之间不可避免的需要建立连接换句话说系统(或者某模块)必然是复杂的(没有什么系统可以几个对象就轻松搞定,那样或许也不能称之为系统了吧)功能必然会分布在多个对象中多个对象协作必然需要联系,这必然导致耦合的产生如上图所示,虽然系统对外呈现是一个统一的整体,但是,内部各个模块之间很可能是紧密的耦合各个模块相互联系,可能互相持有引用,会出现网状结构,完全不符合迪米特法则。

如果对系统进行改动,将会变得困难。

我们以装修为例一般装修公司都会给每一个项目配备一个项目经理(这个项目也就是你家这个单子了,项目经理就是包工头)装修的一般阶段分为:前期设计→拆改→水电→瓦工→木工→油漆→安装→保洁→软装项目经理手上经常同时有几个工地在同步进行,只要错的开就好了因为每个阶段都是有先后顺序的,你不可能先木工,然后再去拆改;因为每个阶段也都需要一定时间,也意味着这一拨人不可能同时在你家工作开工后项目经理会进行工作安排水电工结束了A之后,项目经理会安排他到B,然后安排瓦工到A,然后........所有的顺序都是由项目经理负责调度,水电工可以完全不认识瓦工,他们也完全不需要进行联系有事儿找项目经理如果没有项目经理,会是什么场景?那就是人人都是项目经理,人人都需要管自己,还需要管别人也就是每个人安排分配自己的时间与任务水电工结束后需要联系瓦工进场,如果瓦工发现有遗留问题,需要联系水电工进行沟通木工需要联系瓦工确认进展情况,油漆工又需要确认木工状况...你会发现他们必须要经常保持联系,以获得进展情况,进而安排自己的工作一个包工队尚且如此,如果是一个大的装修公司,怎么办?而且装修而言,阶段之间还会有顺序,油漆工用不到联系水电工但是在系统中,对象岂会仅仅与一个对象联系?那岂不是更复杂、乱套?中介者模式就是为了解决系统内部的调度问题,降低系统内部各模块之间的耦合度。

工厂模式,工厂方法模式,单例模式,外观(Facade)模

工厂模式,工厂方法模式,单例模式,外观(Facade)模

工厂模式,工厂方法模式,单例模式,外观(Facade)模式,观察者(Observer)模式,桥接(Bridge)模式都是比较常用的,不同的项目有不同的设计方向,可以参考的设计模式也不尽相同,没有定数,只是上面这几个模式用的比较多一些。

其他的模式我找了一下,都列出来了。

======================Java常用的设计模式创建型模式1、FACTORY—追MM少不了请吃饭了,麦当劳的鸡翅和肯德基的鸡翅都是MM 爱吃的东西,虽然口味有所不同,但不管你带MM去麦当劳或肯德基,只管向服务员说“来四个鸡翅”就行了。

麦当劳和肯德基就是生产鸡翅的Factory工厂模式:客户类和工厂类分开。

消费者任何时候需要某种产品,只需向工厂请求即可。

消费者无须修改就可以接纳新产品。

缺点是当产品修改时,工厂类也要做相应的修改。

如:如何创建及如何向客户端提供。

2、BUILDER—MM最爱听的就是“我爱你”这句话了,见到不同地方的MM,要能够用她们的方言跟她说这句话哦,我有一个多种语言翻译机,上面每种语言都有一个按键,见到MM我只要按对应的键,它就能够用相应的语言说出“我爱你”这句话了,国外的MM也可以轻松搞掂,这就是我的“我爱你”builder。

(这一定比美军在伊拉克用的翻译机好卖)建造模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。

建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。

建造模式可以强制实行一种分步骤进行的建造过程。

3、FACTORY METHOD—请MM去麦当劳吃汉堡,不同的MM有不同的口味,要每个都记住是一件烦人的事情,我一般采用Factory Method模式,带着MM到服务员那儿,说“要一个汉堡”,具体要什么样的汉堡呢,让MM直接跟服务员说就行了。

工厂方法模式:核心工厂类不再负责所有产品的创建,而是将具体创建的工作交给子类去做,成为一个抽象工厂角色,仅负责给出具体工厂类必须实现的接口,而不接触哪一个产品类应当被实例化这种细节。

最新软件设计模式练习题-2018

最新软件设计模式练习题-2018

一、选择题1.(A)模式的关键是将一个对象定义为原型,并为其提供复制自己的方法。

A.原型B.创建者C.工厂方法D.迭代2.下面的类图表示的是哪个设计模式?(B)A装饰模式(Decorator)B策略模式(Strategy)C桥接模式(Bridge)D观察者模式(Observer)3.Strategy(策略)模式的意图是:(A)。

A.定义一系列的算法,把它们一个个的封装起来,并且使它们可相互替换。

B.为一个对象动态连接附加的职责。

C.你希望只拥有一个对象,但不用全局对象来控制对象的实例化。

D.在对象之间定义一种一对多的依赖关系,这样当一个对象的状态改变时,所有依赖于它的对象都将得到通知并自动更新。

4.下面不属于创建型模式的有(C)。

A.抽象工厂模式(Abstract Factory)B.工厂方法模式(Factory Method)C.适配器模式(Adapter)D.单例模式(Singleton)5.将一个类的接口转换成客户希望的另一个接口。

这句话是对下列哪种模式的描述(C)。

A.策略模式(Strategies)B.桥接模式(Bridge)C.适配器模式(Adapter)D.单例模式(Singleton)6.下面的类图表示的是哪个设计模式?(A)。

A装饰模式(Decorator)B适配器模式(Adapter)C策略模式(Strategies)D桥接模式(Bridge)7.下面属于结构模式的有(D)。

A.策略模式(Strategies)B.单例模式(Singleton)C.抽象工厂模式(Abstract Factory)D.装饰模式(Decorator8.下图可以使用(A)模式进行设计。

A.组合B.模板C.责任链D.状态9.( B )将抽象部分与它的实现部分分离,使它们都可以独立地变化。

A.组合B.桥接C.责任链D.状态10.下图是关于房间状态的描述,可以使用( D )模式进行设计。

A.组合B.桥接C.责任链D.状态11.设计模式具有的优点(A )。

技术专题--j2ee模式

技术专题--j2ee模式

j2ee模式(MVC模式、Model1,Model2)1、j2ee常用的设计模式?说明工厂模式。

Java中的23种设计模式:Factory(工厂模式), Builder(建造模式), Factory Method(工厂方法模式),Prototype(原始模型模式),Singleton(单例模式), Facade(门面模式),Adapter(适配器模式), Bridge(桥梁模式), Composite(合成模式),Decorator(装饰模式), Flyweight(享元模式), Proxy(代理模式),Command(命令模式), Interpreter(解释器模式), Visitor(访问者模式),Iterator(迭代子模式), Mediator(调停者模式), Memento(备忘录模式),Observer(观察者模式), State(状态模式), Strategy(策略模式),Template Method(模板方法模式), Chain Of Responsibleity(责任链模式)工厂模式:工厂模式是一种经常被使用到的模式,根据工厂模式实现的类可以根据提供的数据生成一组类中某一个类的实例,通常这一组类有一个公共的抽象父类并且实现了相同的方法,但是这些方法针对不同的数据进行了不同的操作。

首先需要定义一个基类,该类的子类通过不同的方法实现了基类中的方法。

然后需要定义一个工厂类,工厂类可以根据条件生成不同的子类实例。

当得到子类的实例后,开发人员可以调用基类中的方法而不必考虑到底返回的是哪一个子类的实例。

2、说说你所熟悉或听说过的j2ee中的几种常用模式?及对设计模式的一些看法Session Facade Pattern:使用SessionBean访问EntityBeanMessage Facade Pattern:实现异步调用EJB Command Pattern:使用Command JavaBeans取代SessionBean,实现轻量级访问Data Transfer Object Factory:通过DTO Factory简化EntityBean数据提供特性Generic Attribute Access:通过AttibuteAccess接口简化EntityBean数据提供特性Business Interface:通过远程(本地)接口和Bean类实现相同接口规范业务逻辑一致性ejb架构的设计好坏将直接影响系统的性能、可扩展性、可维护性、组件可重用性及开发效率。

系统分析与设计复习提纲

系统分析与设计复习提纲

系统分析与设计复习提纲一、试题类型●选择题:基本概念, 见复习要点●填空题:基本概念, 见复习要点●判断题:基本概念, 见复习要点●名词解释:见下列复习题●简答题:见下列复习题●画图、程序题二、各章复习要点(完整叙述参见课本或PPT)OOADA分析:做正确的事(对问题需求调查研究)D设计:正确地做事(概念上的解决方案)OA面向对象分析:发现描述领域对象OD面向对象设计: 定义软件对象及如何协作关键技能:为软件对象分配职责统一过程UP核心思想: 短固迭代进化可适应6个主要科目(工作流):业务建模,需求,设计,实现,测试,部署4个阶段:初始、细化、构造、移交敏捷开发宣言:工、文、合、计需求定义:能力,条件分类:"FURPS+"模型制品:USGVR用例概念:参与者、场景、用例模型作用:捕获用户目标的最好办法;发现定义需求的核心机制;强调了F:功能需求;不是OO,是OOAD关键需求的输入表示法:摘要、非正式、详述How:选边界;定主参;定目标;以目标编用例细化阶段一句话:构核架,决高险,定需求,预进度领域模型What is:"可视化字典"/"概念模型"/"领域对象模型"/"分析对象模型"How to:寻找策略: 重用修改现有模型(首要); 常见分类列表; 名词短语(从详述用例)系统顺序图SSD作用:SSD是OC和OD的输入;SSD中的操作在OC中分析;SSD是协作对象设计的起点;UC文本是它的输入系统事件:特定场景, 跨系统边界的事件系统操作:对系统事件进行处理的系统行为或功能操作契约OC后置条件:三种状态变化:实例创建删除;属性修改;关联形成清除逻辑架构LALA:软件类宏观组织结构;组织为包、子系统、层等;对立术语:部署架构包图:描述LA; 能组织如何事物层:对类、包、子系统粗颗粒度分组;高层可调用低层,反之不然常见层:UADBTF交互图描述对象间消息交互, 比静态图价值更高种类:顺序图(栅栏式、顺序清晰); 通信图(网格式、空间效用)UML类图类属性:2种表示方式: 属性文本(内置属性);关联线(关联属性)。

JAVA设计模式之调停者模式详解

JAVA设计模式之调停者模式详解

JAVA设计模式之调停者模式详解在阎宏博⼠的《JAVA与模式》⼀书中开头是这样描述调停者(Mediator)模式的: 调停者模式是对象的⾏为模式。

调停者模式包装了⼀系列对象相互作⽤的⽅式,使得这些对象不必相互明显引⽤。

从⽽使它们可以较松散地耦合。

当这些对象中的某些对象之间的相互作⽤发⽣改变时,不会⽴即影响到其他的⼀些对象之间的相互作⽤。

从⽽保证这些相互作⽤可以彼此独⽴地变化。

为什么需要调停者 如下图所⽰,这个⽰意图中有⼤量的对象,这些对象既会影响别的对象,⼜会被别的对象所影响,因此常常叫做同事(Colleague)对象。

这些同事对象通过彼此的相互作⽤形成系统的⾏为。

从图中可以看出,⼏乎每⼀个对象都需要与其他的对象发⽣相互作⽤,⽽这种相互作⽤表现为⼀个对象与另⼀个对象的直接耦合。

这就是过度耦合的系统。

通过引⼊调停者对象(Mediator),可以将系统的⽹状结构变成以中介者为中⼼的星形结构,如下图所⽰。

在这个星形结构中,同事对象不再通过直接的联系与另⼀个对象发⽣相互作⽤;相反的,它通过调停者对象与另⼀个对象发⽣相互作⽤。

调停者对象的存在保证了对象结构上的稳定,也就是说,系统的结构不会因为新对象的引⼊造成⼤量的修改⼯作。

⼀个好的⾯向对象的设计可以使对象之间增加协作性(Collaboration),减少耦合度(Couping)。

⼀个深思熟虑的设计会把⼀个系统分解为⼀群相互协作的同事对象,然后给每⼀个同事对象以独特的责任,恰当的配置它们之间的协作关系,使它们可以在⼀起⼯作。

如果没有主板 ⼤家都知道,电脑⾥⾯各个配件之间的交互,主要是通过主板来完成的。

如果电脑⾥⾯没有了主板,那么各个配件之间就必须⾃⾏相互交互,以互相传送数据。

⽽且由于各个配件的接⼝不同,相互之间交互时,还必须把数据接⼝进⾏转换才能匹配上。

所幸是有了主板,各个配件的交互完全通过主板来完成,每个配件都只需要和主板交互,⽽主板知道如何跟所有的配件打交道,这样就简单多了。

中介者模式特点及应用场景

中介者模式特点及应用场景

中介者模式特点及应用场景
中介者模式是设计模式中的一种,也被称为调停者模式。

它的特点是提供一个中介对象,来管理和协调各个对象之间的通信和交互的过程。

中介者模式的核心思想是松耦合和单一职责原则,通过将一个系统中对象之间的交互模式改变为中介者直接进行交互,从而降低了各个对象之间的耦合性,提高了系统的可维护性和可扩展性。

中介者模式适用于以下场景:
1. 当一个系统中各个对象之间的交互模式复杂,杂乱无章,难以维护和扩展时,可以考虑使用中介者模式,将各个对象的交互行为集中在一个中介者中,从而降低系统的复杂度。

2. 当一个系统中的各个对象之间存在相互依赖的情况,但是这些依赖关系不应该直接暴露出来时,可以使用中介者模式,将依赖关系集中在一个中介者中来进行管理和协调。

3. 当一个系统中的各个对象之间需要进行协作完成某个业务功能时,可以使用中介者模式,将各个对象的协作行为集中在一个中介者中,从而提高系统的灵活性和可扩展性。

4. 当一个系统中的各个对象之间需要进行交互和通信时,可以使用中介者模式,
将交互和通信的过程集中在一个中介者中,从而降低对象之间的耦合性,提高系统的稳定性和可维护性。

接-“策略模式”

接-“策略模式”

---------------------------------------------------------------最新资料推荐------------------------------------------------------接-“策略模式”Java 与模式摘要面向对象的设计原则接-策略模式即在一个以继承关系形成的等级结构里面,树叶节点均应当是具体类,而树枝节点均应当是抽象类(或 java 接口)。

在一个从抽象类到多个具体类的继承关系中,共同的代码应当尽量一动到抽象类里。

一个对象从超类继承而来的代码,在不使用时不会造成对资源的浪费。

但是,数据的移动方向是从抽象类到具体类,也即从继承的等级结构的高端相等级结构的低端移动。

一个对象得数据不论是否使用都会占用资源。

1、开-闭原则(OCP)。

相应的模式:策略模式、简单工厂模式、工厂方法模式、抽象工厂模式、建造模式、桥梁模式、门面模式、调停者模式、访问者模式、迭代子模式 2、里氏代换原则(LSP)相应的模式:策略模式、合成模式、代理模式代理模式给某一对象提供一个代理对象,并由代理对象控制对原对象的饮用。

代理模式能够成立的关键,就在于代理模式和真是主体模式都1 / 3是抽象主体角色的子类。

应尽量从抽象类继承:如果有两个具体类 A 和 B 有继承关系,那么一个最简单的修改方案是建立一个抽象类 C,然后让 A, B 类成为抽象类 C 的子类。

注意:继承应当用来扩展超类的功能,而不是 Override 或撤销超类的功能,应当避免。

3、依赖倒转原则(DIP)相应的模式:工厂方法模式、模办方法模式、迭代子模式有针对接口编程,不要针对实现编程。

前者是说,应当使用 Java 接口和抽象 Java 类进行变量的类型声明、参量的类型声明、方法的返回类型声明,以及数据类型的转换等;后者是说,不应当使用具体 Java 类进行变量的类型声明。

等。

变量被声明时的类型叫做变量的静态类型(Static Type)或明显类型(Apparent Type)。

调停者模式(Mediator Pattern)

调停者模式(Mediator Pattern)

通常,面向对象应用程序是由一组为了提供某种服务而彼此交互的对象组成。

当彼此引用的对象数量比较少时,此时对象之间就为直接交互(点对点)。

图31.1展示了当ObjectA和ObjectB之间彼此直接引用时的直接交互。

Figure 31.1: Point-to-Point Communication in the Case of Two Objects 当对象的数量增加时,这种直接交互会导致对象之间复杂的、混乱的引用(如图31.2)。

这就会影响应用程序的可维护性。

同时,因为对象之间的高耦合,当一个对象直接引用其他的对象时,缩小了这些对象的复用范围。

Figure 31.2: Point-toPoint Communication?Increased Number of Objects 在这种情况下,调停模式(Mediator Pattern)可以为这组对象设计一个控制、协调交互(交流)的模型,从而消除对象直接引用其他对象的需求。

(如图31.3)Figure 31.3: Object Interaction?Mediator as a Communication Hub 调停者模式(Mediator Pattern)推荐抽象所有对象交互的细节到一个独立的类,这个类就是调停者,它负责这组对象之间的交互。

这组对象中的每一个对象仍然负责提供它所具有的服务,但为了提供服务,对象之间不能直接彼此交互。

两个不同对象之间的交互通过调停者(Mediator)进行路由。

所有的对象把消息发送给调停者(Mediator)。

调停者(Mediator)依据应用程序的需求把消息再发送给相应的对象。

这样的设计有以下主要的优点:(1)随着所有对象的交互行为移到一个独立的对象中,通过调停者(Mediator)的子类替换调停者(Mediator)或者改变它的功能可以很容易的改变对象之间内部的关联行为。

(2)将对象的内部依赖关系移到一个单独的对象,这样会提高对象的可用(3)因为对象不需要直接引用其他的对象,所以对象可以更容易的进行单元测试。

设计模式期末复习知识讲解

设计模式期末复习知识讲解

设计模式期末复习题1、以下哪个模式是利用一个对象,快速地生成一批对象:()A.抽象工厂(Abstract Factory)模式B.组合(Composite)模式C.原型(Prototype)模式D.桥接(Bridge)模式2、要针对接口编程,不要针对实现编程是()原则的一种表述。

A.里氏代换B. 依赖倒转C.接口隔离D.迪米特3、“不要和陌生人说话”是( )原则的通俗表述A.开闭B.里氏代换C.合成复用D.迪米特4、关于继承表述错误的是:()A.继承是一种通过扩展一个已有对象的实现,从而获得新功能的复用方法。

B.泛化类(超类)可以显式地捕获那些公共的属性和方法。

特殊类(子类)则通过附加属性和方法来进行实现的扩展。

C.破坏了封装性,因为这会将父类的实现细节暴露给子类。

D.继承本质上是“白盒复用”,对父类的修改,不会影响到子类5、当想使用一个已经存在的类,但其接口不符合需求时,可以采用()设计模式将该类的接口转换成我们希望的接口A. 命令(Command)B. 适配器(Adapter)C.装饰(Decorator)D.桥接(Bridge)6、对于依赖倒转的表述错误的是()A.依赖于抽象而不依赖于具体,也就是针对接口编程。

B.依赖倒转的接口并非语法意义上的接口,而是一个类对其他对象进行调用时,所知道的方法集合。

C.从选项B的角度论述,一个对象可以有多个接口。

D.实现了同一接口的对象,可以在运行期间,顺利地进行替换。

而且不必知道所示用的对象是那个实现类的实例。

E.此题没有正确答案。

7、Java 的异常处理机制可理解为哪一种行为模式。

A.观察者(Observer )模式B.迭代器(Iterator)模式C.职责链(Chain of Responsibility )模式D.策略(Strategy )模式8、( )不是桥接模式所适用的场景A. 一个可以跨平台并支持多种格式的文件编辑器B. 一个支持多数据源的报表生成工具,可以以不同图形方式显示报表信息C. 一个可动态选择排序算法的数据操作工具D. 一个可以支持多种编程语言的跨平台开发工具9、下图描述了一种设计模式,该模式不可以()A. 动态决定由一组对象中某个对象处理该请求B. 动态指定处理一个请求的对象集合,并高效率地处理一个请求C. 使多个对象都有机会处理请求,避免请求的发送者和接收者间的耦合D. 将对象连成一条链,并沿着该链传递请求Client +handleRequest()Handler+handlerRequest()ConcreateHandlerA +handleRequest()ConcreateHandlerB-successor1110、在()时无须使用命令模式A. 实现撤消操作和恢复操作B. 将请求的发送者和接收者解耦C. 不改变聚合类的前提下定义作用于聚合中元素的新操作D. 在不同的时刻指定请求,并将请求排队11. 中介者模式中通过中介者来将同事类解耦,这是()的具体应用。

设计模式-观察者、调停者

设计模式-观察者、调停者

实践的一小步 代码质量的一大步
相关模式
● 备忘录模式
● 观察者模式使用了备忘录模式,暂时将观察者兑现光存储在被观察者对里面
● MVC模式
● 架构模式:一般是观察者模式、合成模式、策略模式等设计模式的组合。
● 调停者模式 ● 待续。
实践的一小步 代码质量的一大步
Java观察者模式类图 Java观察者模式类图
实践的一小步 代码质量的一大步
模式分析
● 优点
● 可以减少使用静态的继承关系,是的具体同事类可以更加容易得被复用 ● 可以避免同事对象之间的过度耦合,使得调停者类与同事类可以相对独 立的演化 ● 将多对多的相互作用转换为一对多的相互作用,是的对象之间的关系更 加易于维护和理解 ● 将对象的行为和协作抽象化,把对象在小尺度的行为上与其他对象的相 互作用分开
抽抽抽抽抽
ConcreteSubject observers : ArrayList changeState() 1
ConcreteObserver
具具抽抽
具具抽抽抽
实践的一小步 代码质量的一大步
模式类图二
<<Interface>> Subject observers : ArrayList<Observer> attach() detach() notifyObservers() 抽抽抽抽 1 0..* <<Interface>> Observer update()
实践的一小步 代码质量的一大步
Observable类
被观察者类都是 java.util.Observable类的子类 在被观察者对象的 notifyObservers()方法实现应 该调用每一个观察者对象的 update()方法,从而通知所 有的观察对象。

设计模式完结(17)---中介者模式--协调多个对象之间的交互

设计模式完结(17)---中介者模式--协调多个对象之间的交互

设计模式完结(17)---中介者模式--协调多个对象之间的交互中介者模式定义如下:中介者模式(Mediator Pattern):⽤⼀个中介对象(中介者)来封装⼀系列的对象交互,中介者使各对象不需要显式地相互引⽤,从⽽使其耦合松散,⽽且可以独⽴地改变它们之间的交互。

中介者模式⼜称为调停者模式,它是⼀种对象⾏为型模式。

举例: qq 之间交流 qq 群如果在⼀个系统中对象之间的联系呈现为⽹状结构,如图20-4所⽰。

对象之间存在⼤量的多对多联系,将导致系统⾮常复杂,这些对象既会影响别的对象,也会被别的对象所影响,这些对象称为同事对象,它们之间通过彼此的相互作⽤实现系统的⾏为。

在⽹状结构中,⼏乎每个对象都需要与其他对象发⽣相互作⽤,⽽这种相互作⽤表现为⼀个对象与另外⼀个对象的直接耦合,这将导致⼀个过度耦合的系统。

同事对象不再直接与另⼀个对象联系,它通过中介者对象与另⼀个对象发⽣相互作⽤。

中介者对象的存在保证了对象结构上的稳定,也就是说,系统的结构不会因为新对象的引⼊带来⼤量的修改⼯作。

Mediator(抽象中介者):它定义⼀个接⼝,该接⼝⽤于与各同事对象之间进⾏通信。

● ConcreteMediator(具体中介者):它是抽象中介者的⼦类,通过协调各个同事对象来实现协作⾏为,它维持了对各个同事对象的引⽤。

● Colleague(抽象同事类):它定义各个同事类公有的⽅法,并声明了⼀些抽象⽅法来供⼦类实现,同时它维持了⼀个对抽象中介者类的引⽤,其⼦类可以通过该引⽤来与中介者通信。

● ConcreteColleague(具体同事类):它是抽象同事类的⼦类;每⼀个同事对象在需要和其他同事对象通信时,先与中介者通信,通过中介者来间接完成与其他同事类的通信;在具体同事类中实现了在抽象同事类中声明的抽象⽅法。

中介者模式的核⼼在于中介者类的引⼊,在中介者模式中,中介者类承担了两⽅⾯的职责:(1) 中转作⽤(结构性):通过中介者提供的中转作⽤,各个同事对象就不再需要显式引⽤其他同事,当需要和其他同事进⾏通信时,可通过中介者来实现间接调⽤。

软件设计常见的23种设计模式

软件设计常见的23种设计模式

软件设计常见的23种设计模式 在现代软件开发当中,设计模式起到⾄关重要的作⽤。

尤其是⾃从⾯向对象的语⾔普遍使⽤以后,促成了团队合作设计的热潮,⽽在此时,没有⼀个好的设计模式,软件设计⼏乎成了不可能完成的任务。

⼀般模式有4个基本要素:模式名称(pattern name)、问题(problem)、解决⽅案(solution)、效果(consequences)。

常见23种模式概述: 1)抽象⼯⼚模式(Abstract Factory):提供⼀个创建⼀系列相关或相互依赖对象的接⼝,⽽⽆需指定它们具体的类。

2)适配器模式(Adapter):将⼀个类的接⼝转换成客户希望的另外⼀个接⼝。

适配器模式使得原本由于接⼝不兼容⽽不能⼀起⼯作的类可以⼀起⼯作。

3)桥梁模式(Bridge):将抽象部分与它的实现部分分离,使它们都可以独⽴地变化。

4)建造模式(Builder):将⼀个复杂对象的构建与它的表⽰分离,使同样的构建过程可以创建不同的表⽰。

5)责任链模式(Chain of Responsibility):为解除请求的发送者和接收者之间耦合,⽽使多个对象都有机会处理这个请求。

将这些对象连成⼀条链,并沿着这条链传递该请求,直到有⼀个对象处理它。

6)命令模式(Command):将⼀个请求封装为⼀个对象,从⽽可⽤不同的请求对客户进⾏参数化;对请求排队或记录请求⽇志,以及⽀持可取消的操作。

7)合成模式(Composite):将对象组合成树形结构以表⽰“部分-整体”的层次结构。

它使得客户对单个对象和复合对象的使⽤具有⼀致性。

8)装饰模式(Decorator):动态地给⼀个对象添加⼀些额外的职责。

就扩展功能⽽⾔,它能⽣成⼦类的⽅式更为灵活。

9)门⾯模式(Facade):为⼦系统中的⼀组接⼝提供⼀个⼀致的界⾯,门⾯模式定义了⼀个⾼层接⼝,这个接⼝使得这⼀⼦系统更加容易使⽤。

10)⼯⼚⽅法(Factory Method):定义⼀个⽤于创建对象的接⼝,让⼦类决定将哪⼀个类实例化。

C#的23种设计模式简要介绍

C#的23种设计模式简要介绍
不同的子类可以以不同的方式实现这些抽象方法,从而对剩余的逻辑有不同的实现。
先制定一个顶级逻辑框架,而将逻辑的细节留给具体的子类去实现。
23、VISITOR—访问者模式:访问者模式的目的是封装一些施加于某种数据结构元素之上的操作。
一旦这些操作需要修改的话,接受这个操作的数据结构可以保持不变。访问者模式适用于数据结构相对未定的系统,
合成模式就是一个处理对象的树结构的模式。合成模式把部分与整体的关系用树结构表示出来。
合成模式使得客户端把一个个单独的成分对象和由他们复合而成的合成对象同等看待。
9、DECORATOR—装饰模式:装饰模式以对客户端透明的方式扩展对象的功能,是继承关系的一个替代方案,
提供比继承更多的灵活性。动态给一个对象增加功能,这些功能可以再动态的撤消。增加由一些基本功能的排列组合而产生的非常大量的功能。
命令对象的等级结构中的对象的任何排列组合都是一个语言。
16、ITERATOR—迭代子模式:迭代子模式可以顺序访问一个聚集中的元素而不必暴露聚集的内部表象。
多个对象聚在一起形成的总体称之为聚集,聚集对象是能够包容一组对象的容器对象。
迭代子模式将迭代逻辑封装到一个独立的子对象中,从而与聚集本身隔开。迭代子模式简化了聚集的界面
命令模式把发出命令的责任和执行命令的责任分割开,委派给不同的对象。
命令模式允许请求的一方和发送的一方独立开来,使得请求的一方不必知道接收请求的一方的接口,更不必知道请求是怎么被接收,
以及操作是否执行,何时被执行以及是怎么被执行的。系统支持命令的撤消。
15、INTERPRETER—解释器模式:给定一个语言后,解释器模式可以定义出其文法的一种表示,并同时提供一个解释器。

软考系统架构师案例分析知识点整理

软考系统架构师案例分析知识点整理

系统规划:包括系统项目的提出预可行性分析;系统方案的制定、评价和改进;新旧系统的分析和比较;现有软件、硬件和数据资源的有效利用;软件架构设计:XML技术;基于架构的软件开发过程;软件的质量属性;架构(模型)风格;特定领域软件架构;基于架构的软件开发方法;架构评估;软件产品线;系统演化设计模式:设计模式概念;设计模式的组成;模式和软件架构;设计模式分类;设计模式实现;系统设计:处理流程设计;人机界面设计;文件涉及;存储设计;数据库设计;网络应用系统的设计;系统运行环境的集成与设计;中间件;应用服务器;性能设计与性能评估;系统转换设计划;软件系统建模:系统需求、建模的作用以及意义;定义问题(目标、功能、性能)与归结模型(静态结构模型、动态行为模型、物理模型);结构化系统建模;数据流图;面向对象系统建模;统一建模语言(UML);数据库建模;E-R图;逆向工程;分布式系统设计:分布式通行协议的设计;基于对象的分布式系统设计;基于web的分布式系统设计;基于消息和协同的分布式系统设计;异构分布式系统的互操作性设计;嵌入式系统设计:实时系统和嵌入式系统特征;实时任务调度和多任务设计;中断处理和异常处理;嵌入式系统的开发设计系统的可靠性分析与设计:系统故障模型和可靠性模型;系统的可靠性分析与可靠度计算;提高系统可靠性的措施;系统的故障对策和系统的备份与恢复;系统安全性和保密性设计:系统的访问控制技术;数据的完整性;数据与文件的加密;通信的安全性;系统的安全性设计;1、概念类系统规划项目计划:包括范围计划、工作范围计划、活动定义、资源需求、资源计划、活动排序、费用估算、进度计划、费用计划;项目辅助计划包括质量计划、沟通计划、人力资源计划、风险计划、采购计划。

虚拟化技术:计算元件在虚拟的基础上运行;有完全虚拟化,准虚拟化,操作系统层虚拟化等;虚拟化收益:1、有效提高服务器资源利用率2、支持运行在不同操作系统之上的多个业务共享一台服务器3、减少服务器数量,降低硬件成本4、节约场地面积,减少能耗软件架构设计架构风险:架构设计中潜在的、存在问题的架构决策所带来的隐患敏感点:为了实现某种特定的质量属性,一个或者多个系统组件所具有的特性权衡点:影响多个质量属性,并且对多个质量属性来说都是敏感点的系统属性软件质量属性包括:功能性、性能、可用性、可靠性、健壮性、安全性、可修改性、可变性、易用性、可测试性、互操作性六种质量属性策略:1、可用性错误检测:命令/响应,心跳机制,异常监控错误恢复:表决(裁决表),主动冗余,被动冗余,备件,状态再同步,检查点/回滚错误预防:从服务中删除,事物(要么全成功,要么全失败),定期重置,进程监视器2、可修改性局部化修改:维持语义的一致性,预期期望的变更,泛化该模块,限制可能的选择防止连锁反应:信息隐藏,维持现有的接口,限制通信路径,仲裁者的使用推迟绑定时间:运行时注册,配置文件,多态,构件更换3、性能资源需求:减少处理时间所需的资源,减少所处理事件的数量,控制资源使用,限制执行时间资源管理:引入并发,维持数据或计算的多个副本,增加可用资源资源仲裁:先进/先出,固定优先级,动态优先级调度,静态调度4、安全性抵抗攻击:对用户进行身份验证,对用户进行授权,维护数据的机密性,维护完整性,限制暴露的信息,限制访问检测攻击:部署入侵检测系统从攻击中恢复:恢复,识别攻击者5、可测试性输入/输出:记录/回放,将接口—实现分离,优化访问线路/接口内部监控:当监视器处于激活状态时,记录事件6、易用性运行时:任务模型,用户模型,系统模型设计时:将用户接口与应用的其余部分分离支持用户主动:支持用户主动操作软件架构风格:描述某一类特定应用领域中软件系统组织方式和惯用方式;组织方式描述了系统的组成构建和这些构建的组织方式,惯用模式则反映众多系统共有的结构和语义。

软件架构模式的种类

软件架构模式的种类

在做软件架构设计时,根据不同的抽象层次可分为三种不同层次的模式:架构模式(Architectural Pattern)、设计模式(Design Pattern)、代码模式(Coding Pattern)。

架构模式是一个系统的高层次策略,涉及到大尺度的组件以及整体性质和力学。

架构模式的好坏可以影响到总体布局和框架性结构。

设计模式是中等尺度的结构策略。

这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。

模式的好坏不会影响到系统的总体布局和总体框架。

设计模式定义出子系统或组件的微观结构。

代码模式(或成例)是特定的范例和与特定语言有关的编程技巧。

代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节,但不会影响到一个部件或子系统的中等尺度的结构,更不会影响到系统的总体布局和大尺度框架。

架构模式(Architectural Pattern)一个架构模式描述软件系统里的基本的结构组织或纲要。

架构模式提供一些事先定义好的子系统,指定它们的责任,并给出把它们组织在一起的法则和指南。

称之为系统模式。

•MVC模式,一个架构模式常常可以分解成很多个设计模式的联合使用。

MVC模式常常包括调停者(Mediator)模式、策略(Strategy)模式、合成(Composite)模式、观察者(Observer)模式等。

•Layers(分层)模式,有时也称Tiers模式•Blackboard(黑板)模式•Broker(中介)模式•Distributed Process(分散过程)模式•Microkernel(微核)模式架构模式常常划分成如下的几种:一、模块结构(From Mud to Structure)型。

帮助架构师将系统合理划分,避免形成一个对象的海洋。

包括Layers(分层)模式、Blackboard(黑板)模式、Pipes/Filters (管道/过滤器)模式等。

二、分散系统(Distributed Systems)型。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

实践的一小步 代码质量的一大步
模式时序图
: Colleague1 : ConcreteMe... : Colleague2
1: change( ) 2: colleagueChanged( ) 3: action( ) 4: action( )
实践的一小步 代码质量的一大步
模式分析
● 优点
● 可以减少使用静态的继承关系,是的具体同事类可以更加容易得被复用 ● 可以避免同事对象之间的过度耦合,使得调停者类与同事类可以相对独 立的演化 ● 将多对多的相互作用转换为一对多的相互作用,是的对象之间的关系更 加易于维护和理解 ● 将对象的行为和协作抽象化,把对象在小尺度的行为上与其他对象的相 互作用分开
● 实现了抽象调停者所声明的事件方法。具体调停者知晓所有的同 事对象,并从具体同事对象接受消息,向具体同事对象发出命令
● 抽象同事(Colleague)角色:
● 定义出调停者到同事对象的接口。同事对象只知道调停者,而不 知道其余的同事对象
● 具体同事(Concrete Colleague)角色
● 每一个具体同事类都清楚自己在小范围内的行为,而不知道它在 大范围内的目的。
设计模式
—调停者模式
实践的一小步 代码质量的一大步
调停者模式(Mediator Pattern)
● 是对象的行为模式。
● 包装了一系列对象相互作用的方式,是这些对象不 必相互明显引用,从而使他们可以较松散的耦合, 使得其可以彼此独立的变化。 ● 增加协作性(Collaboration),减少耦合度(Coupling) ● 体现了“迪米特法则(LoD)(最少知识原则)” ● 属于很容易被滥用的一个设计模式
实践的一小步 代码质量的一大步
程序分析
● //具体同事类----光驱 ● package com.bankht.Mediator; public class CDDriver extends Colleague { // 光驱读取出来的数据 private String data = “”; public CDDriver(Mediator mediator) { super(mediator); } public String getData() { // 获取光盘读取出来的数据 return data; }
实践的一小步 代码质量的一大步
程序分析
/** * 读取光盘 */ public void readCD() { // 逗号前是视频显示的数据,逗号后是声音 this.data = "One Piece,海贼王我当定了"; // 通知主板,自己的状态发生了改变 getMediator().changed(this); } }
实践的一小步 代码质量的一大步
程序分析
● // 让调停者知道所有同事 mediator.setCdDriver(cd); mediator.setCpu(cpu); mediator.setVideoCard(vc); mediator.setSoundCard(sc); // 开始看电影,把光盘放入光驱,光驱开始读盘 cd.readCD(); } }
实践的一小步 代码质量的一大步
程序分析
● //具体调停者类
● package com.bankht.Mediator; public class MainBoard implements Mediator { // 需要知道要交互的同事类——光驱类 private CDDriver cdDriver = null; // 需要知道要交互的同事类——CPU类 private CPU cpu = null; // 需要知道要交互的同事类——显卡类 private VideoCard videoCard = null; // 需要知道要交互的同事类——声卡类 private SoundCard soundCard = null; public void setCdDriver(CDDriver cdDriver) { this.cdDriver = cdDriver; }
● 缺点
● 降低了同事对象的复杂性,代价是增加了调停者对象的复杂性 ● 提供了倾斜的可扩展性和可复用性:调停者类经常充满了各个具体同事 类的关系协调代码,不易复用。因此,具体同事类的复用是以调停者类 的不可复用为代价的
实践的一小步 代码质量的一大步
不适合的使用场合
● 不应当在责任划分混乱时使用 ● 不应当对“数据类” 和“方法类”使用。
实践的一小步 代码质量的一大步
程序分析
● public void setCpu(CPU cpu) { this.cpu = cpu; } public void setVideoCard(VideoCard videoCard) { this.videoCard = videoCard; } public void setSoundCard(SoundCard soundCard) { this.soundCard = soundCard; } @Override public void changed(Colleague c) { if (c instanceof CDDriver) { // 表示光驱读取数据了 this.opeCDDriverReadData((CDDriver) c); } else if (c instanceof CPU) { this.opeCPU((CPU) c); } }
实践的一小步 代码质量的一大步
程序分析
● //抽象调停者 package com.bankht.Mediator; public interface Mediator { /** * 同事对象在自身改变的时候来通知调停者方法 让调停 者去负责相应的与其他同事对象的交互 */ public void changed(Colleague c); }
实践的一小步 代码质量的一大步
程序分析
● 具体同事类---声卡 ● package com.bankht.Mediator; public class SoundCard extends Colleague { public SoundCard(Mediator mediator) { super(mediator); } /** * 按照声频数据发出声音 */ public void soundData(String data) { System.out.println("画外音:" + data); } }
实践的一小步 代码质量的一大步
程序分析
● //具体同事类----CPU
● package com.bankht.Mediator; public class CPU extends Colleague { // 分解出来的视频数据 private String videoData = ""; // 分解出来的声音数据 private String soundData = ""; public CPU(Mediator mediator) { super(mediator); } /** * 获取分解出来的视频数据 */ public String getVideoData() { return videoData; } /** 实践的一小步 质量的一大步
程序分析
● /* 获取分解出来的声音数据 */ public String getSoundData() { return soundData; } /** * 处理数据,把数据分成音频和视频的数据 */ public void executeData(String data) { // 把数据分解开,前面是视频数据,后面是音频数据 String[] array = data.split(","); this.videoData = array[0]; this.soundData = array[1]; // 通知主板,CPU完成工作 getMediator().changed(this); }
实践的一小步 代码质量的一大步
}
程序分析
● //具体同事类---显卡
package com.bankht.Mediator; public class VideoCard extends Colleague { public VideoCard(Mediator mediator) { super(mediator); } /** * 显示视频数据 */ public void showData(String data) { System.out.println("您正在观看的是:" + data); } }
实践的一小步 代码质量的一大步
如何恰到好处的使用设计模式
● 完全了解面临的具体问题 ● 完全了解设计模式 ● 非常了解怎样使用设计模式解决实际问题 ● 要将设计模式理论与具体系统需求情况相结 合,而不是生硬的组合和拼凑
实践的一小步 代码质量的一大步
大量对象间的复杂关系
A D G
B
E
H
C
F
I
实践的一小步 代码质量的一大步
● 封装应该是行为及其所涉及的状态的封装。不应当将其分开。
实践的一小步 代码质量的一大步
模式示例
没有主板,使用电脑看电影的过程
实践的一小步 代码质量的一大步
模式示例
● 加入主板之后的电脑各部件关 系,如下图所示:
实践的一小步 代码质量的一大步
程序分析
● 例如使用电脑看电影过程的例子 //抽象同事类
实践的一小步 代码质量的一大步
程序分析
● //客户端程序 ● package com.bankht.Mediator; public class Client { public static void main(String[] args) { // 创建调停者——主板 MainBoard mediator = new MainBoard(); // 创建同事类 CDDriver cd = new CDDriver(mediator); CPU cpu = new CPU(mediator); VideoCard vc = new VideoCard(mediator); SoundCard sc = new SoundCard(mediator);
相关文档
最新文档