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

1.什么是外观模式
为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用

2.为什么要使用外观模式
在软件开发系统中,客户程序经常会与复杂系统的内部子系统之间产生耦合,从而导致客户程序随着子系统的变化而变化,那么如何简化客户程序与子系统之间的交互接口?如何将复杂系统的内部子系统与客户程序之间的依赖解耦?

现在来考虑这样一个抵押系统,当有一个客户来时,有如下几件事情需要确认:
到银行子系统查询他是否有足够多的存款,到信用子系统查询他是否有良好的信用,到贷款子系统查询他有无贷款劣迹。只有这三个子系统都通过时才可进行抵押。我们先不考虑Facade模式,那么客户程序就要直接访问这些子系统,分别进行判断。

 private static void Main(string[] args)
        {
            //外观,封装子系统
            Mortgage mortgage = new Mortgage();

            Customer customer = new Customer("Ann McKinsey");
            bool eligable = mortgage.IsEligible(customer, 125000);

            Console.WriteLine("\n" + customer.Name +
                " has been " + (eligable ? "Approved" : "Rejected"));
            Console.ReadLine();
        }
        //顾客类
        public class Customer
        {
            private string _name;

            public Customer(string name)
            {
                this._name = name;
            }

            public string Name
            {
                get { return _name; }
            }
        }

        //银行子系统
        public class Bank
        {
            public bool HasSufficientSavings(Customer c, int amount)
            {
                Console.WriteLine("Check bank for " + c.Name);
                return true;
            }
        }

        //信用子系统
        public class Credit
        {
            public bool HasGoodCredit(Customer c)
            {
                Console.WriteLine("Check credit for " + c.Name);
                return true;
            }
        }

        //贷款子系统
        public class Loan
        {
            public bool HasNoBadLoans(Customer c)
            {
                Console.WriteLine("Check loans for " + c.Name);
                return true;
            }

        }

        public class Mortgage
        {
            private Bank bank = new Bank();
            private Loan loan = new Loan();
            private Credit credit = new Credit();

            public bool IsEligible(Customer cust, int amount)
            {
                Console.WriteLine("{0} applies for {1:C} loan\n",
                  cust.Name, amount);

                bool eligible = true;

                if (!bank.HasSufficientSavings(cust, amount))
                {
                    eligible = false;
                }
                else if (!loan.HasNoBadLoans(cust))
                {
                    eligible = false;
                }
                else if (!credit.HasGoodCredit(cust))
                {
                    eligible = false;
                }

                return eligible;
            }
        }

可以看到引入Facade模式后,客户程序只与Mortgage发生依赖,也就是Mortgage屏蔽了子系统之间的复杂的操作,达到了解耦内部子系统与客户程序之间的依赖。

Facade模式在实际开发中最多的运用当属开发N层架构的应用程序了

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

时间: 2024-07-30 13:36:58

设计模式学习之外观模式(Facade,结构型模式)(8)的相关文章

设计模式-11 外观模式(结构型模式)

一  外观模式 外观模式(Facade Pattern)隐藏系统的复杂性,并向客户端提供了一个客户端可以访问系统的接口.这种类型的设计模式属于结构型模式,它向现有的系统添加一个接口,来隐藏系统的复杂性. 主要解决:降低访问复杂系统的内部子系统时的复杂度,简化客户端与之的接口. 关键代码:在客户端和复杂系统之间再加一层,这一次将调用顺序.依赖关系等处理好. 使用场景: JAVA 的三层开发模式 1.为复杂的模块或子系统提供外界访问的模块. 2.子系统相对独立. 3.预防低水平人员带来的风险. 类图

(转)Java经典设计模式(2):七大结构型模式(附实例和详解)

原文出处: 小宝鸽 总体来说设计模式分为三大类:创建型模式.结构型模式和行为型模式. 博主的上一篇文章已经提到过创建型模式,此外该文章还有设计模式概况和设计模式的六大原则.设计模式的六大原则是设计模式的核心思想,详情请看博主的另外一篇文章:Java经典设计模式之五大创建模式(附实例和详解). 接下来我们看看结构型模式,共七种:适配器模式.装饰器模式.代理模式.外观模式.桥接模式.组合模式.享元模式.其中适配器模式主要分为三类:类的适配器模式.对象的适配器模式.接口的适配器模式.其中的对象的适配器

设计模式08: Composite 组合模式(结构型模式)

Composite 组合模式(结构型模式) 对象容器的问题在面向对象系统中,我们常会遇到一类具有“容器”特征的对象——即他们在充当对象的同时,又是其他对象的容器. public interface IBox { void Process(); } public class SingleBox:IBox { public void Process(){...} } public class ContainerBox:IBox { public void Process(){...} public

设计模式12: Proxy 代理模式(结构型模式)

Proxy 代理模式(结构型模式) 直接与间接 人们对于复杂的软件系统常常有一种处理手法,即增加一层间接层,从而对系统获得一种更为灵活.满足特定需求的解决方案.如下图,开始时,A需要和B进行3次通信,当增加一个C后,C和B只需要通信一次,A和C通信3次就好了. 动机(Motivation) 在面向对象系统中某些对象由于某种原因(比如对象创建的开销很大,或者某些操作需要安全机制,或者需要进程外的访问等),直接访问会给使用者.或者系统结构带来很多麻烦. 如果在不失去透明操作对象的同时来管理.控制这些

设计模式-12 享元模式(结构型模式)

一 享元模式 享元模式的主要目的是实现对象的共享,即共享池,当系统中对象多的时候可以减少内存的开销,通常与工厂模式一起使用. 主要解决:在有大量对象时,有可能会造成内存溢出,我们把其中共同的部分抽象出来,如果有相同的业务请求,直接返回在内存中已有的对象,避免重新创建. 关键代码:存储相似的对象 使用场景: 1.系统有大量相似对象. 2.需要缓冲池的场景. 类图 : 二 实现代码 Java里面的JDBC连接池,适用于作共享的一些个对象,他们有一些共有的属性,就拿数据库连接 池来说,url.driv

设计模式11: Flyweight 享元模式(结构型模式)

Flyweight 享元模式(结构型模式) 面向对象的代价 面向对象很好的解决了系统抽象性的问题,同时在大多数情况下也不会损及系统的性能.但是,在某些特殊应用中,由于对象的数量太大,采用面向对象会给系统带来难以承受的内存开销.比如图形应用中的图元等对象.字处理应用中的字符对象等. 动机(Motivation) 采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中,而带来很高的运行代价——主要指内存需求方面的代价. 如何避免大量细粒度对象问题的同时,让外部客户程序仍然能够透明地使用面向对象

设计模式07: Bridge 桥接模式(结构型模式)

Bridge 桥接模式(结构型模式) 抽象与实现 抽象不应该依赖于实现细节,实现细节应该依赖于抽象. 抽象B稳定,实现细节b变化 问题在于如果抽象B由于固有的原因,本身并不稳定,也有可能变化,怎么办? 举例来说 假如我们需要开发一个同时支持PC和手机的坦克游戏,游戏在PC和手机上功能都一样,都有同样的类型,面临同样的需求变化,比如坦克可能有多种不同的型号:T50,T75,T90…… 对于其中坦克设计,我们可能很容易设计出来一个Tank的抽象基类: /// <summary> /// 抽象Tan

设计模式06: Adapter 适配器模式(结构型模式)

Adapter 适配器模式(结构型模式) 适配(转换)的概念无处不在:电源转接头.电源适配器.水管转接头... 动机(Motivation)在软件系统中,由于应用环境的变化,常常需要将“一些现存的对象”放在新的环境中应用,但是新环境要求的接口是这些现存对象不能满足的.如何应对这种“迁移的变化”?如何既能够利用现有对象的良好表现,同时又能满足新的应用环境所要求的接口? 意图(Intent)将一个类的接口转换成客户希望的另一个接口.Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一

23种设计模式-----创建型模式、结构型模式

一.创建型模式(都是用来帮助创建对象的) 1.单例模式 作用:保证一个类只有一个实例,并且提供一个访问该实例的全局访问点 应用:Windows的任务管理器.回收站:项目中读取配置文件的类:网站的计数器:应用程序的日志应用:数据库连接池:操作系统的文件系统:Application:Spring中的bean:Servlet:spring MVC框架/struts1框架中的控制器对象 选用:占用资源小.不需要延时加载--------枚举-->饿汉           占用资源大 .需要延时    --