大话设计模式之六:11~15章(迪米特法则 、外观模式、建造者模式、观察者模式、抽象工厂模式)
来源:互联网 发布:java自学还是培训 编辑:程序博客网 时间:2024/06/07 16:00
注:《大话设计模式》这本书很好的介绍了设计模式,其对应的源码是C#语言写得,跑在visual studio上,所以自己先安装visual studio ,然后将源码跑一跑,这样能深刻的理解《大话设计模式这本书》,现在将整个过程整理好,方便别人也方便自己!
第十一章:无熟人难办事?——迪米特法则 (低耦合)
解决:一个软件实体应当尽可能少地与其他实体发生相互作用,迪米特法则可降低系统的耦合度,使类与类之间保持松散的耦合关系
JAVA设计模式之门面模式(外观模式)
目录(?)[+]
医院的例子
现代的软件系统都是比较复杂的,设计师处理复杂系统的一个常见方法便是将其“分而治之”,把一个系统划分为几个较小的子系统。如果把医院作为一个子系统,按照部门职能,这个系统可以划分为挂号、门诊、划价、化验、收费、取药等。看病的病人要与这些部门打交道,就如同一个子系统的客户端与一个子系统的各个类打交道一样,不是一件容易的事情。
首先病人必须先挂号,然后门诊。如果医生要求化验,病人必须首先划价,然后缴费,才可以到化验部门做化验。化验后再回到门诊室。
上图描述的是病人在医院里的体验,图中的方框代表医院。
解决这种不便的方法便是引进门面模式,医院可以设置一个接待员的位置,由接待员负责代为挂号、划价、缴费、取药等。这个接待员就是门面模式的体现,病人只接触接待员,由接待员与各个部门打交道。
门面模式的结构
门面模式没有一个一般化的类图描述,最好的描述方法实际上就是以一个例子说明。
由于门面模式的结构图过于抽象,因此把它稍稍具体点。假设子系统内有三个模块,分别是ModuleA、ModuleB和ModuleC,它们分别有一个示例方法,那么此时示例的整体结构图如下:
在这个对象图中,出现了两个角色:
● 门面(Facade)角色 :客户端可以调用这个角色的方法。此角色知晓相关的(一个或者多个)子系统的功能和责任。在正常情况下,本角色会将所有从客户端发来的请求委派到相应的子系统去。
● 子系统(SubSystem)角色 :可以同时有一个或者多个子系统。每个子系统都不是一个单独的类,而是一个类的集合(如上面的子系统就是由ModuleA、ModuleB、ModuleC三个类组合而成)。每个子系统都可以被客户端直接调用,或者被门面角色调用。子系统并不知道门面的存在,对于子系统而言,门面仅仅是另外一个客户端而已。
源代码
子系统角色中的类:
门面角色类:
客户端角色类:
Facade类其实相当于A、B、C模块的外观界面,有了这个Facade类,那么客户端就不需要亲自调用子系统中的A、B、C模块了,也不需要知道系统内部的实现细节,甚至都不需要知道A、B、C模块的存在,客户端只需要跟Facade类交互就好了,从而更好地实现了客户端和子系统中A、B、C模块的解耦,让客户端更容易地使用系统。
门面模式的实现
使用门面模式还有一个附带的好处,就是能够有选择性地暴露方法。一个模块中定义的方法可以分成两部分,一部分是给子系统外部使用的,一部分是子系统内部模块之间相互调用时使用的。有了Facade类,那么用于子系统内部模块之间相互调用的方法就不用暴露给子系统外部了。
比如,定义如下A、B、C模块。
这样定义一个ModuleFacade类可以有效地屏蔽内部的细节,免得客户端去调用Module类时,发现一些不需要它知道的方法。比如a2()和a3()方法就不需要让客户端知道,否则既暴露了内部的细节,又让客户端迷惑。对客户端来说,他可能还要去思考a2()、a3()方法用来干什么呢?其实a2()和a3()方法是内部模块之间交互的,原本就不是对子系统外部的,所以干脆就不要让客户端知道。
一个系统可以有几个门面类
在门面模式中,通常只需要一个门面类,并且此门面类只有一个实例,换言之它是一个单例类。当然这并不意味着在整个系统里只有一个门面类,而仅仅是说对每一个子系统只有一个门面类。或者说,如果一个系统有好几个子系统的话,每一个子系统都有一个门面类,整个系统可以有数个门面类。
为子系统增加新行为
初学者往往以为通过继承一个门面类便可在子系统中加入新的行为,这是错误的。门面模式的用意是为子系统提供一个集中化和简化的沟通管道,而不能向子系统加入新的行为。比如医院中的接待员并不是医护人员,接待员并不能为病人提供医疗服务。
门面模式的优点
门面模式的优点:
● 松散耦合
门面模式松散了客户端与子系统的耦合关系,让子系统内部的模块能更容易扩展和维护。
● 简单易用
门面模式让子系统更加易用,客户端不再需要了解子系统内部的实现,也不需要跟众多子系统内部的模块进行交互,只需要跟门面类交互就可以了。
● 更好的划分访问层次
通过合理使用Facade,可以帮助我们更好地划分访问的层次。有些方法是对系统外的,有些方法是系统内部使用的。把需要暴露给外部的功能集中到门面中,这样既方便客户端使用,也很好地隐藏了内部的细节。
作者:jason0539
微博:http://weibo.com/2553717707
博客:http://blog.csdn.net/jason0539(转载请说明出处)
1.使用建造者模式可以使客户端不必知道产品内部组成的细节。
2.具体的建造者类之间是相互独立的,对系统的扩展非常有利。
3.由于具体的建造者是独立的,因此可以对建造过程逐步细化,而不对其他的模块产生任何影响。
建造者模式通常包括下面几个角色:
1. builder:给出一个抽象接口,以规范产品对象的各个组成成分的建造。这个接口规定要实现复杂对象的哪些部分的创建,并不涉及具体的对象部件的创建。
2. ConcreteBuilder:实现Builder接口,针对不同的商业逻辑,具体化复杂对象的各部分的创建。 在建造过程完成后,提供产品的实例。
3. Director:调用具体建造者来创建复杂对象的各个部分,在指导者中不涉及具体产品的信息,只负责保证对象各部分完整创建或按某种顺序创建。
4. Product:要创建的复杂对象。
按照惯例,还是给出建造者模式的结构图
JAVA设计模式之抽象工厂模式
抽象工厂模式代码
产品类:
创建工厂类:
客户:
关于抽象工厂模式与工厂方法模式的区别,这里就不说了,感觉多看几遍例子就能理解,还有很多提到的产品族、等级结构等概念,说了反而更难理解。
作者:jason0539
博客:http://blog.csdn.net/jason0539(转载请说明出处)
- 大话设计模式之六:11~15章(迪米特法则 、外观模式、建造者模式、观察者模式、抽象工厂模式)
- 大话设计模式-----(四)迪米特法则、外观模式、建造者模式
- 大话设计模式-----(五)观察者模式、抽象工厂模式
- 大话设计模式之抽象工厂模式
- 大话设计模式之抽象工厂模式
- 大话设计模式6 建造者模式 观察者模式
- 《大话设计模式》读书笔记:建造者模式与观察者模式
- 大话设计模式15----抽象工厂模式
- 大话设计模式之建造者模式
- 大话设计模式之建造者模式
- 大话设计模式之建造者模式
- 大话设计模式之建造者模式
- 大话设计模式之建造者模式
- 大话设计模式之建造者模式
- 设计模式之建造型-抽象工厂模式(3)
- 【大话设计模式】--建造者模式VS装饰模式/抽象工厂
- 《Android之大话设计模式》--设计模式 创建型模式 第三章:抽象工厂模式
- php设计模式专题附源码(解释器模式、工厂方法模式、外观模式、装饰模式、建造者模式)
- python之pickle模块
- 数据库 增删改查
- docker系列文章
- HDU 4666 Hyperspace
- 设计模式(13)--Chain of Responsibility(责任链模式)--行为型
- 大话设计模式之六:11~15章(迪米特法则 、外观模式、建造者模式、观察者模式、抽象工厂模式)
- HttpURLConnection工具类 获取图片+Json
- 第一次博客
- 决策树算法---概念
- (学习笔记)设计模式之状态模式(游戏场景切换)
- 使用<c:forEach>标签遍历List中的map元素
- 负载均衡基础知识
- AsyncTask 网络获取图片和Json数据加载到ListView上
- MySql deadlock