设计模式整理_外观模式

  外观模式提供了一个统一的接口,用来访问子系统中的一群接口,外观定义了一个高层的接口,让子系统更容易使用.因为有了外观,客户的工作将更加快捷简便.

  组件建立后,将会组装于外观中,并直接将外观派发给客户,方便使用,因此外观模式简化了组件中的一系列接口,方便客户的操作.外观将客户从一个复杂的子系统中解耦.当需要简化并统一一个很大的接口或者一群复杂的接口时,使用外观.

  下面是外观模式的具体使用,可以看出,通过外观模式,大大的简化了客户的操作,对于组件的操作将在具体的外观内部进行操作.

  

//组件
public interface Login {
    public void loginGame();
}
class RpgLogin implements Login{

    @Override
    public void loginGame() {
        System.out.println("Login in RPG Game!");
    }

}
//组件
public interface Information {
    public void getInformation();
}
class RpgInformation implements Information {

    @Override
    public void getInformation() {
        System.out.println("get RPG Information.");
    }

}
//组件
public interface Role {
    public void selectRole();
}
class RpgRole implements Role{
    public void selectRole() {
        System.out.println("Select a RPG GAME role.");
    }
}
public interface PlayGame {
    public void play();
}
class PlayRpgGame implements PlayGame {
    /*三个组件直接在外观类中进行实例化,客户看不到,客户只关心具体的调用.*/
    Login log=new RpgLogin();
    Information inf=new RpgInformation();
    Role rol=new RpgRole();
    @Override
    public void play() {
        log.loginGame();
        inf.getInformation();
        rol.selectRole();
    }

}
//通过外观模式大大简化了操作.
public class Test {
    public static void main(String[] args) {
        PlayRpgGame play=new PlayRpgGame();
        play.play();
    }
}
时间: 2024-12-30 13:04:18

设计模式整理_外观模式的相关文章

设计模式整理_组合模式

组合模式允许你将对象组成树形结构,来表现整体和部分的联系.组合能让客户以一致的方式处理个别对象和对象的组合. 组合模式将整体称为组合.(类似于树结构中的树),将组合下面没有其他元素相连的物件称为叶结点.其中,组合和叶结点有着共同的父类,可以将两者所有的方法抽象到父类中,并且对方法有默认的实现,这样如果叶结点或者组合不想实现某个方法的时候,就可以不实现方法.通过将菜单和项放在相同的结构中,我们创建了一个整体/部分的层次结构,即由菜单项和菜单组成的对象树.可以将它视为一个整体.任何一个菜单都可能是组

设计模式整理_策略模式

△策略模式用于在用户行为经常发生变化的情况下,将行为单独提取出来,定义算法族,采用组合的方式,分别封装起来,让他们可以互相替换,此模式,让算法的变化独立于使用算法的客户. 该模式体现了如下设计模式的原则: 封装变化. 多用组合,少用继承. 针对接口编程,而不针对实现编程. 在策略模式中,第一点体现了对于类中变化的部分,进行了封装,第二部分体现了将算法族的接口定义在类中,采用组合的形式来完成对于类行为的定义,第三部分体现了利用借口代表每个行为,而将接口的具体实现交给其实现类来完成.下面是代码示例,

设计模式整理_状态模式

状态模式允许对象在内部状态改变的时候,改变它的行为,对象看起来好像修改了它的类.因为这个模式将状态封装成为独立的类,并将动作委托到代表当前状态的对象,而行为会随着内部状态而改变. 在状态模式中,Context内部持有状态,State接口定义了一个所有具体状态的共同接口,任何状态都实现这个相同的接口,这样一来,各个状态可以互相替换.具体状态实现状态接口,所以当Context改变状态的时候,行为也跟着改变.而不管在什么时候,只要有人调用Context的具体方法,它就会用来委托状态处理,下面用具体事例

设计模式整理_模板模式

模板模式在父类中定义了一个方法的模板,而子类可以动态的实现模板成分方法,但是模板中的方法顺序无法改变. 父类中的模板方法往往申明为final,用来保证方法不被子类覆盖,因为作为模板,是不可以改变的,但是模板方法内的一系列方法,可以由子类自己静态实现,同时在父类的模板方法中,可以定义钩子(hook)方法.方便子类对于模板方法的优化.下面用两个例子说明. /*没有钩子(hook)的模板方法,此时模板方法无法修改*/ public abstract class Model { public final

设计模式整理_工厂模式

一.简单工厂模式. 通常情况下,在代码中需要创建一系列对象的时候,如果需要创建新的同类型的对象,就需要对原代码进行修改,此时就不符合对修改关闭的原则,因此,我们将创建对象于使用对象的代码分隔开来,在工厂类中创建工厂,然后如果需要新的对象,只需要修改工厂的类即可. public interface Car /*在这里定义需要生成的实例,针对抽象组件*/{ public void run(); } class BenzCar /*实例*/ implements Car { @Override pub

设计模式整理_迭代器模式

迭代器模式提供了一种方法顺序访问一个聚合对象中的各个元素,而又不是暴露其内部的表示.将在聚合对象内部游走的任务放在迭代器上而不是放在聚合上,这样简化了聚合的接口和实现,也让责任各得其所. 例如在没有进行优化的下列代码中,在处理不同的对象的聚合的时候,获取了对象的内部实现,这对封装造成了破坏,另外一方面,当需要处理其他类型的聚合对象的时候,也会造成需要对源代码进行修改,不利于扩展. /* * 定义Food类,Food类是需要被聚合的对象 * */ public class Food { priva

设计模式整理_命令模式

命令模式将请求封装成对象,以便使用不同的请求,队列或者日志来参数化其他对象,命令模式也支持可撤销的操作.当需要将发出请求的对象和执行请求的对象解耦的时候,采用命令模式. 命令模式中有几个名词:调用者,命令,接受者,客户.客户负责创建命令和调用者,调用者将命令封装在自己里面,当客户需要执行某些操作的时候,调用者就将调用命令对象的方法,命令对象通知接受者执行操作.一个命令对象通过在特定的接受者上绑定一组动作来封装一个请求,调用者可以接受命令作为自己的参数,甚至在运行的时候动态的执行,命令可以支持撤销

设计模式(2)_代理模式 ————— 控制对象访问

设计模式(2)_代理模式 ----- 控制对象访问 一.动机 需求 现在有这样一个需求:有一个出版社,该出版社有一个工厂,专门用来生产制造图书,该工厂里有很多台生产制造图书的机器.每个机器有自己的位置坐标,用 int表示,机器的状态,{正在工作,暂停,故障},已经印刷了多少页图书.在出版社 在工厂 厂长的电脑屏幕上,可以随时打印出任何一台机器的报告信息(report infomation). 下来 我们用代码实现这个需求: PrinterMachine.java package com.crg;

设计模式学习之外观模式(Facade,结构型模式)(8)

1.什么是外观模式为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用 2.为什么要使用外观模式在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,从而导致客户程序随着子系统的变化而变化,那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦? 现在来考虑这样一个抵押系统,当有一个客户来时,有如下几件事情需要确认:到银行子系统查询他是否有足够多的存款,到信用子系统查询他是否有良好的信