精华内容
下载资源
问答
  • 2018-10-16 23:05:35

    facade 设计模式:
        facade 设计模式,有人称之为门面设计模式,也有人称之为外观设计模式。不管他叫什么,本人对它的理解为,它是对多个方法功能的封装。使其暴露一个入口。
        
        demo:
            现有类:股票A 股票B,有一需求是买股票,和卖出股票。
            
            StockA:
                package com.juvenxu.helloworld;

                public class StockA {
                    private int number = 0;

                    public void  sell(int number){
                        this.number -= number;
                    }

                    public void pay(int number){
                        this.number += number;
                    }

                    public int getNumber() {
                        return number;
                    }
                }
                
            StockB:
                package com.juvenxu.helloworld;

                public class StockB {
                    private int number = 0;

                    public void  sell(int number){
                        this.number -= number;
                    }

                    public void pay(int number){
                        this.number += number;
                    }

                    public int getNumber() {
                        return number;
                    }
                }
            
            不使用facade 设计模式前同时买入股票a,b各10张的做法
                @Test
                public void test2(){
                    StockA stockA = new StockA();
                    StockB stockB = new StockB();

                    stockA.pay(10);
                    stockB.pay(10);
                    System.out.println(stockA.getNumber());
                    System.out.println(stockB.getNumber());
                }
            
            使用facade 创建一个代理类StockProxy:
            StockProxy:
                package com.juvenxu.helloworld;

                public class StockProxy {

                    StockA stockA;
                    StockB stockB;

                    public static StockProxy Initialize(){
                        synchronized (StockProxy.class){
                            return new StockProxy();
                        }
                    }

                    public StockProxy(){
                        this.stockA = new StockA();
                        this.stockB = new StockB();
                    }

                    public int getStockANumber(){
                        return stockA.getNumber();
                    }

                    public int getStockBNumber(){
                        return stockB.getNumber();
                    }

                    public void sellAll(int number){
                        stockB.sell(number);
                        stockA.sell(number);
                    }

                    public void payAll(int number){
                        stockA.pay(number);
                        stockB.pay(number);
                    }
                }
                
            此时的测试方法:
                    @Test
                    public void test3() {
                        StockProxy stockProxy = StockProxy.Initialize();
                        stockProxy.payAll(10);
                        System.out.println(stockProxy.getStockANumber());
                        System.out.println(stockProxy.getStockBNumber());

                    }
            
            使用此设计模式的好处就是将业务逻辑封装到了代理类中,这样做降解了StockA、B和业务逻辑间的耦合,并且还不影响StockA、B的代码。又符合设计原则中的开闭原则,方便以后的升级和维护

    更多相关内容
  • 设计模式》一书对于Facade模式的意图是这样描述的: 为子系统中的一组接口提供一个统计接口。Facade模式定义了一个更高层的接口,使子系统更加容易使用。 大多数工作依旧需要由子系统完成,但Facade模式提供了...

    中文音译为外观设计模式。其实我们在开发中经常会使用到这种设计模式。比如我们项目中需要使用到一个中间件Elasticsearch,领导会让所有人都去学习如何使用它提供的复杂API,还是只需要让其中一个人学习并封装我们用得到的API呢?

    简介

    《设计模式》一书对于Facade模式的意图是这样描述的:

    为子系统中的一组接口提供一个统计接口。Facade模式定义了一个更高层的接口,使子系统更加容易使用。
    在这里插入图片描述

    大多数工作依旧需要由子系统完成,但Facade模式提供了一组更容易理解的方法,这些方法使用底层系统来实现新定义的函数。

    关键特征

    意图希望简化原有系统的使用方式。需要定义自己的接口。
    问题只需要使用某个复杂系统的子集,或者,需要以一种特殊的方式与系统交互。
    解决方案Facade为原有系统的客户提供了一个新的接口。
    参与者与协作者为客户提供的一个简化接口,使系统更容易使用。
    效果Facade模式简化了对所需子系统的使用过程。但是,由于Facade并不完整,因此客户可能无法使用某些功能。
    实现1.定义一个(或多个)具备所需接口的新类。2.让新的类使用原有的系统。

    好处

    • 跟踪系统使用情况。强制所有对系统的访问必须经过Facade,可以很容易监视系统使用情况。
    • 改换系统。未来换系统时,通过将原系统作为Facade一个私有成员,可以省力地切换到新系统。

    应用场景

    • 不需要使用一个复杂系统的所有功能,创建一个新的类,包含访问系统的所有规则。若只是使用系统的部分功能,新类创建的API将比原系统的API简单的多。
    • 希望封装或者隐藏原系统。
    • 希望使用原系统的功能,而且希望增加一些新的功能。
    • 编写新类的成本小于所有人学会使用或者未来维护原系统上所需的成本。
    展开全文
  • facade设计模式

    2012-03-07 14:48:10
    facade设计模式 里面有设计模式的实现
  • Facade设计模式在VB数据库中的应用
  • 23种设计模式(1)-Facade设计模式

    万次阅读 2016-05-16 14:47:00
    为解决这些问题,可以采用门面设计模式,也就是本博文的Facade设计模式。 采用Facade设计模式 Ear和Brain类同上 Head类 :在此我们添加一个门面类,也就是本设计模式的核心类。其实,作为门面,你不...

    前记

            曾经我遇见的一个需求是这样的,接口A有个方法void methodA(),类B需要实现接口A的methodA()方法,并且在类B中需要把methodA()方法内部处理逻辑获得的结果利用C类实例的某个方法进行持久化操作。由于技术功力尚浅,开始我左思右想就是不能实现这个需求。开始纠结于两个难题:1,methodA()方法返回值为void,我无法获得methodA()内部逻辑获得的数据,无法获得这些数据,也就无法利用持久化类C进行处理;2,methodA()方法入参又为空,我的持久化类C也无法注入。当时我就懵逼了。还好,突然脑海想起了曾学spring时遇见的模板类设计模式,于是浅显学了下的模板类设计模式轻松把这个难题搞定。解决方法为,B定义为抽象类,内部再另外定义一个抽象方法absMethod(C c),其入参为持久类C类型,在B类的methodA()方法中调用这个抽象方法absMethod(C c),这样持久化类则注入到了methodA()方法中,则可以对其中的数据进行持久化操作了。然后只需要用D类继承这个B类,并且实现这个B的absMethod(C c)方法,这样就可以把C实例间接传入methodA()方法。
            本博文并不是讲解模板类设计模式,只是借助遇见的这个问题的解决过程来强调设计模式对实现需求或学习技术源码是多么重要。不再废话,开始正文。


    设计模式原则

    这里写图片描述
    以下为6种设计原则,直接摘录于别的博文或百度,这些内容的最终来源基本都是设计模式经典书籍《设计模式—可复用面向对象软件的基础》
    1、开闭原则(Open Close Principle)
            开闭原则就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。所以一句话概括就是:为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,我们需要使用接口和抽象类,后面的具体设计中我们会提到这点。
    2、里氏代换原则(Liskov Substitution Principle)
            里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说,任何基类可以出现的地方,子类一定可以出现。 LSP是继承复用的基石,只有当衍生类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。
    3、依赖倒转原则(Dependence Inversion Principle)
            这个是开闭原则的基础,具体内容:真对接口编程,依赖于抽象而不依赖于具体。
    4、接口隔离原则(Interface Segregation Principle)
            这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。还是一个降低类之间的耦合度的意思,从这儿我们看出,其实设计模式就是一个软件的设计思想,从大型软件架构出发,为了升级和维护方便。所以上文中多次出现:降低依赖,降低耦合。
    5、迪米特法则(最少知道原则)(Demeter Principle)
            为什么叫最少知道原则,就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。
    6、合成复用原则(Composite Reuse Principle)
            原则是尽量使用合成/聚合的方式,而不是使用继承。


    问题描述

            交流对于程序员这个职位来说是严重缺乏的,我们需要多锻炼啊。就举这个例子,当别人对我们说一句话,我们要领会别人的意思,粗略的讲这个过程主要是耳朵和大脑配合的结果。耳朵首先要“听”别人说的话,也就是获取别人对我们说的话。然后交给大脑去分析,我们才得以明白,用代码来模拟就如下。


    不采用设计模式

    Ear类

    package com.facade.tradition;
    /**
     * 
     * @author DC
     *
     */
    public class Ear {
    
        /**
         * 别人说的话
         */
        private String words;
    
        /**
         * 听-获取别人说的话
         */
        public String getWords(String words){
            System.out.println("别人对我说的话:"+words);
            return words;
        }
    
        /**
         * 耳朵把话传给大脑
         */
        public boolean sendWordsToBrain(Brain brain,String words){
            return brain.sendWordsInBrain(words);
        }
    }
    

    Brain类

    package com.facade.tradition;
    /**
     * 
     * @author DC
     *
     */
    public class Brain {
    
        /**
         * 话语
         */
        private String words;
    
        /**
         * 把话语记录大脑,别人说了话就设置true,反之false
         */
        public boolean sendWordsInBrain(String words){
            this.words=words;
            if(words==null){
                return false;
            }else{
                return true;
            }
        }
    
        /**
         * 分析话语
         */
        public void explainWords(){
            //模拟分析过程
            try {
                System.out.println("正在分析对方说的话是什么意思......");
                Thread.sleep(5000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            System.out.println("额,原来你是这个意思!!");
        }
    }
    

    测试类TestTradition
    我们来测试一下,当别人对我们说了一句话, 如果若想理解别人,在不采用门面模式是怎样的。如图:

    package com.facade.tradition;
    /**
     * 不利用设计模式,用代码来模拟这个我们和别人交流接听和理解别人话的过程
     * @author DC
     *
     */
    public class TestTradition {
    
        public static void main(String[] args) {
            //这是我的耳朵和大脑
            Ear ear=new Ear();
            Brain brain=new Brain();
    
            //别人对我说了句话,我耳朵“听”到了
            String words=ear.getWords("你在干吗?");
    
            //但是我的耳朵并不理解别人说的什么意思,于是交给我的大脑
            ear.sendWordsToBrain(brain, words);
    
            //我的大脑分析话语
            brain.explainWords();
        }
    }
    

    在我耳朵和大脑的配合下,我终于明白了别人的话语,不容易啊,运行结果如下:
    这里写图片描述

    分析一下:
            再来看一下这个TestTradition代码,你是不是已经发现什么逻辑代码都得我们自己去完成,耳朵的逻辑处理我们得做,大脑的逻辑处理我们也得做。这导致了几个明显的问题:
             1. 测试类与Ear类代表的子系统和Brain类代表的子系统严重的耦合在了一起。
             2. 我们的测试类不仅与各个类所代表的子系统进行了交互,而且还必须了解两个子系统的类的内部实现情况。
             3. 我们系统中类的所有方法都暴露给了测试类,不论是需要暴露和不需要暴露的。
            再来看看上面提到的软件开发的设计原则,是不是这几个问题严重违背了一些设计原则。另外,我们并不需要了解和操作Ear或者Brain内部的一些方法。为解决这些问题,可以采用门面设计模式,也就是本博文的Facade设计模式。


    采用Facade设计模式

    Ear和Brain类同上
    Head类:在此我们添加一个门面类,也就是本设计模式的核心类。其实,作为门面,你不觉得没有比Head更合适的类了吗,Head封装了Ear和Brain。那就定义Head为门面类,代码如下:

    package com.facade.pattern;
    
    import javax.swing.plaf.synth.SynthSpinnerUI;
    
    /**
     * 模拟门面类,门面类一般是单例的,本例设计一个简单的单例
     * 
     * @author DC
     *
     */
    public class Head {
        /**
         * 耳朵引用变量
         */
        public Ear ear=null;
    
        /**
         * 大脑引用变量
         */
        public Brain brain=null;
    
        /**
         * 头引用变量
         */
        public static Head head=null;
    
        private Head(){
            ear=new Ear();
            brain=new Brain();
        }
    
        /**
         * 获得Head头单例
         * @return
         */
        public static Head getInstance(){
            synchronized(Head.class){
                if(head==null){
                    return new Head();              
                }
                return head;
            }
        }
    
    
        /**
         * "听"后明白了话语
         */
        public void explainWords(String words){
    
            //别人对我说了句话,我耳朵“听”到了
            String yourWords=ear.getWords(words);
    
            //但是我的耳朵并不理解别人说的什么意思,于是交给我的大脑
            ear.sendWordsToBrain(brain, yourWords);
    
            //我的大脑分析话语
            brain.explainWords();
        }
    
    }
    

    测试类TestFacade

    package com.facade.pattern;
    /**
     * 利用设计模式,用代码来模拟这个我们和别人交流接听和理解别人话的过程
     * @author DC
     *
     */
    public class TestFacade {
    
        public static void main(String[] args) {
            //头引用,已经把具体的各个子系统连同其实现细节都封装在内部
            Head head=Head.getInstance();
            //别人说了,我就明白了,并不需要直接和Ear和Brain交互
            head.explainWords("你在干吗??");
        }
    }
    

    运行情况和不采用设计模式一样。

    分析一下:
            再来看看这次发生了什么,Head门面类把Ear和Brain封装到了内部,并且把很多逻辑处理也封装到了内部,比如Ear实例获得话语,Ear实例传递话语,Brain实例记录话语这些都逻辑处理方法。通过这个门面类,只把和用户直接交互的方法explainWords()暴露给用户,其他的几个逻辑方法是属于系统内部方法,因此不需要交互也就不需要暴露出用户。这样的话,就解决了不采用Facade设计模式的几个问题。是不是感觉这个门面设计模式很简单了?


    Facade设计模式

    这里写图片描述
    这里写图片描述
            facade门面角色:客户端和facade进行交互。此角色知道相关的(一个或者多个)子系统的功能和责任。当客户端想与众多的子系统进行交互时,facade角色会将所有从客户端发来的请求委派到相应的子系统去。
            subsystem子系统角色:可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类,而是一个类的集合。每一个子系统都可以被客户端直接调用,或者被门面角色调用。子系统并不知道门面的存在,对于子系统而言,门面仅仅是另外一个客户端而已。

            Facade(外观)模式为子系统中的各类(或结构与方法)提供一个简明一致的界面,隐藏子系统的复杂性,使子系统更加容易使用。 Facade所面对的往往是多个类或其它程序单元,通过重新组合各类及程序单元,对外提供统一的接口/界面。门面模式要求一个子系统的外部与其内部的通信必须通过一个统一的门面(Facade)对象进行。

    Facade模式的几个使用场景:
      1、当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性,也更容易对子系统进行定制,但这也给那些不需要定制子系统的用户带来一些使用上的困难。Facade可以提供一个简单的缺省视图,这一视图对大多数用户来说已经足够,而那些需要更多的可定制性的用户可以越过Facade层。
      2、客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离,可以提高子系统的独立性和可移植性。
      3、当你需要构建一个层次结构的子系统时,使用Facade模式定义子系统中每层的入口点,如果子系统之间是相互依赖的,你可以让它们仅通过Facade进行通讯,从而简化了它们之间的依赖关系。

    特别注意

    1, 【GOF】的书中指出:在门面模式中,通常只需要一个门面类,并且此门面类只有一个实例,换言之它是一个单例类。当然这并不意味着在整个系统里只能有一个门面类,而仅仅是说对每一个子系统只有一个门面类。或者说,如果一个系统有好几个子系统的话,每一个子系统有一个门面类,整个系统可以有数个门面类。
    2,初学者往往以为通过继承一个门面类便可在子系统中加入新的行为,这是错误的。门面模式的用意是为子系统提供一个集中化和简化的沟通管道,而不能向子系统加入新的行为。

            以上比较专业的描述参考于书籍与别的博文。通俗一点理解,不采用facade设计模式就像现在的婚礼,采用facade设计模式和古代婚礼的整个过程是一样。
            不采用facade设计模式==现代婚礼。
            现在你遇见了一个心仪的女孩,恋爱了,打算和她结婚,上门提亲送彩礼什么的一切过程都得你亲力亲为。这个过程细节繁多。毕竟别人家的女儿,丈夫娘怎么会那么轻易让你得逞啦,已哭晕。
            采用facade设计模式==古代婚礼。
            周礼中规定的婚礼主要分六步,首先男方请媒人带上礼物去女方家里提亲,然后等女方家里回答,如果答应了,再让媒人带上男女双方的生辰去卜吉凶,如果可以结婚再选择一个日子,到了时间让男方和媒人带上礼物去迎娶。这下方便了,什么事都交给媒婆办了,连对方是不是女的我们自己都不能确定了。我们有什么事就找媒婆,媒婆从女方那里得到什么消息再反馈给我们。
            自己领悟吧,由于技术和理解有限就写这些了吧。望指教,谢谢!!


    参考书籍或博文:
    1,《设计模式—可复用面向对象软件的基础》(很不错的书籍)
    2,《JAVA设计模式之门面模式(外观模式)》
    3,《JAVA设计模式十九–Facade(外观模式)》
    4,《Java开发中的23种设计模式详解(转)》
    5,《设计模式(15)-Facade Pattern》

    展开全文
  • Command和Facade设计模式

    2019-03-19 01:30:53
    NULL 博文链接:https://smallbee.iteye.com/blog/708507
  • 设计模式-Facade模式

    2021-08-17 15:36:52
    门面(Facade模式的理解与应用 概念 门面模式,指子系统的外部与其内部的通信必需通过一个统一的门面(Facade)对象进行,示意图如下: 应用场景 为一个复杂子系统提供一个简单接口 子系统常常因为不断...

    门面(Facade)模式的理解与应用

    概念

    门面模式,指子系统的外部与其内部的通信必需通过一个统一的门面(Facade)对象进行,示意图如下:

    应用场景

    1. 为一个复杂子系统提供一个简单接口

    子系统常常因为不断演变而变得异常复杂,使用门面模式,对于客户端可以提供一个简单的接口,便于客户的调用。

    1. 保持子系统的独立性

    使用Façade,可以分离子系统和客户端,保持子系统的独立性。

    1. 层次化结构

    在构建层次化系统架构时,可以使用Façade模式定义系统中每一层的入口,限定层之间仅能通过Façade进行通信。例如Comtop最小系统中的man层,可以认为是DAO层对于AppService层的Façade。

    展开全文
  • 主要介绍了PHP设计模式:外观模式Facade,结合实例形式详细分析了PHP外观模式Facade相关概念、功能、原理、用法与操作注意事项,需要的朋友可以参考下
  • Facade设计模式

    2019-10-02 13:33:13
    Facade模式  Facade模式要求一个子系统的外部与其内部的通信必须通过一个统一的Facade对象进行。Facade模式提供一个高层次的接口,使得子系统更易于使用。  就如同医院的接待员一样,Facade模式Facade类将...
  • 介绍外观模式之前,首先让我们来看下面的例子: 假设我们现有一个对外接口FacadeService,里面有一个对外的方法a(); public interface FacadeService { public void a();//这个方法是给外部调用的 } 他有一个...
  • Facade 设计模式

    2014-07-14 13:26:05
    #include using namespace std; class Subsystem1 { public: Subsystem1() {}; ~Subsystem1() {} void Operation() ...class Facade ... Facade * fa=new Facade(); fa->Operation(); return 0; }
  • 1.定义 Facade模式名为外观模式,是一种结构型模式,外观模式是一种非常简单的设计模式。当系统过于复杂时,如果需要调用多个子系统来完成业务,此时会变的非常的复杂,而外观模式则是开一个窗口,相当于一个中介来...
  • Facade模式也叫外观模式,是由GoF提出的23种设计模式中的一种。Facade模式为一组具有类似功能的类群,比如类库,子系统等等,提供一个一致的简单的界面。这个一致的简单的界面被称作facade。为子系统中的一组接口...
  • 设计模式Facade模式

    千次阅读 2018-06-09 11:18:01
    Facade模式——简单窗口 当调用大型程序进行处理时,我们需要格外注意那些数量庞大的类之间错综复杂的关系。不过有一种更简单的做法,就是为这个大型程序提供一个“窗口”。这样,我们就不必单独地关注每个类了,只...
  • 主要介绍了C#设计模式Facade外观模式解决天河城购物问题,简单描述了外观模式的定义并结合具体实例分析了外观模式解决购物问题的相关步骤与操作技巧,需要的朋友可以参考下
  • Java设计模式Facade模式 GOF《设计模式》一书对Facade模式是这样描述的:为子系统中的一组接口提供一个统一接口。Facade模式定义了一个更高层的接口,使子系统更加容易使用。大致意思是说:使用一种比原有方式更...
  • 为子系统中的一组接口提供一个一致(稳定)的界面,Facade模式定义了一个高层接口,这个接口使得这个子系统更加容易使用(复用) 类图 应用场景 1.当你需要使用复杂子系统的有限但直接的接口时,请使用Facade模式 2...
  • [设计模式]:面向复用的:Adapter,Decorator,Facade设计模式的分类Adapter 适配器模式Decorator 装饰器模式Facade 外观模式 忙忙碌碌终于是开始了复习,也终于能从头梳理下这门课介绍的所有设计模式了。 设计模式的...
  • java设计模式Facade模式

    千次阅读 2018-07-05 14:14:17
    介绍外观模式之前,首先让我们来看下面的例子:假设我们现有一个对外接口FacadeService,里面有一个对外的方法a();public interface FacadeService { public void a();//这个方法是给外部调用的 }他有一个实现类...
  • 外观模式通过引入一个外观角色来简化客户端与子系统之间的交互,为复杂的子系统调用提供一个统一的入口,降低子系统与客户端的耦合,接下来就来看设计模式中的facade外观模式在JavaScript开发中的运用
  • 主要介绍了C++设计模式编程中Facade外观模式的使用实例解析,外观模式的主要用途就是为子系统的复杂处理过程提供方便的调用方法,需要的朋友可以参考下
  • 主要介绍了PHP设计模式之外观模式(Facade),结合实例形式详细分析了PHP外观模式的具体原来、用法及相关操作注意事项,需要的朋友可以参考下

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 36,451
精华内容 14,580
关键字:

facade设计模式