(十一)外观模式详解(Service第三者插足,让action与dao分手)

原创 2013年06月22日 23:25:32

                  作者:zuoxiaolong8810(左潇龙),转载请注明出处。

                  各位好,LZ今天给各位分享一个不太熟悉的面孔,但却是我们最经常使用的设计模式,外观模式。

                  定义:外观模式是软件工程中常用的一种软件设计模式。它为子系统中的一组接口提供一个统一的高层接口。这一接口使得子系统更加容易使用。

                  该定义引自百度百科,它的表现很简单,将一系列子接口的功能进行整理,从而产生一个更高层的接口。

                  相信做JAVA的各位大部分是WEB开发,那么肯定都对XXXDao,XXXService非常熟悉了,这显然和外观模式有一腿。当然,还有一大部分是android开发,LZ没接触过android开发,但是LZ大胆的想象,在移动领域的JAVA开发,应该也有类似的情况发生。

                  接下来,我们来看看外观模式的标准类图。


                  上述便是外观模式的类图,它主要由两部分组成,一部分是子系统(包括接口,实现类,等等),一部分是外观接口和实现类,外观接口负责提供客户端定制的服务,外观实现则负责组合子系统中的各个类和接口完成这些服务,外观接口则是提供给客户端使用的,这样就解除了客户端与子系统的依赖,而让客户端只依赖于外观接口,这是一个优秀的解耦实践。

                  下面LZ依然使用JAVA代码将上述的类图诠释出来,我们来直观的看看外观模式的实现方式。首先是我们的子系统,它包括三个接口,三个实现,LZ这里一并给出。

package com.facade;

public interface Sub1 {

	void function1();
	
}
package com.facade;

public interface Sub2 {

	void function2();
	
}
package com.facade;

public interface Sub3 {

	void function3();
	
}
package com.facade;

public class Sub1Impl implements Sub1{

	public void function1() {
		System.out.println("子系统中Sub1接口的功能");
	}

}
package com.facade;

public class Sub2Impl implements Sub2{

	public void function2() {
		System.out.println("子系统中Sub2接口的功能");
	}

}
package com.facade;

public class Sub3Impl implements Sub3{

	public void function3() {
		System.out.println("子系统中Sub3接口的功能");
	}

}

                      以上便是我们模拟出的一个子系统,那么现在便是我们最重要的接口出场的时候了,LZ给出Facade以及它的简单实现。

package com.facade;

public interface Facade {
	
	/*  下面随便组装几个功能  */
	
	void function12();
	
	void function23();
	
	void function123();
	
}
package com.facade;

public class FacadeImpl implements Facade{

	private Sub1 sub1;
	
	private Sub2 sub2;
	
	private Sub3 sub3;
	
	public FacadeImpl() {
		super();
		this.sub1 = new Sub1Impl();
		this.sub2 = new Sub2Impl();
		this.sub3 = new Sub3Impl();
	}

	public FacadeImpl(Sub1 sub1, Sub2 sub2, Sub3 sub3) {
		super();
		this.sub1 = sub1;
		this.sub2 = sub2;
		this.sub3 = sub3;
	}

	public void function12() {
		sub1.function1();
		sub2.function2();
	}

	public void function23() {
		sub2.function2();
		sub3.function3();
	}

	public void function123() {
		sub1.function1();
		sub2.function2();
		sub3.function3();
	}

}

                     以上便是我们的外观接口和实现类,它当中的功能一般是根据是客户端的需要定制的,将客户端的一个完整功能作为一个行为,然后调用子系统完成。下面我们看看客户端的调用。

package com.facade;

public class Client {

	public static void main(String[] args) {
		Facade facade = new FacadeImpl();
		facade.function12();
		System.out.println("-------------------------");
		facade.function23();
		System.out.println("-------------------------");
		facade.function123();
		
		/*  以上为使用了外观模式的调用方式,以下为原始方式   */
		
		System.out.println("-------------以下原始方式--------------");
		Sub1 sub1 = new Sub1Impl();
		Sub2 sub2 = new Sub2Impl();
		Sub3 sub3 = new Sub3Impl();
		sub1.function1();
		sub2.function2();
		System.out.println("-------------------------");
		sub2.function2();
		sub3.function3();
		System.out.println("-------------------------");
		sub1.function1();
		sub2.function2();
		sub3.function3();
	}
	
}

                     LZ在下面还给出了原始的调用方式,可以看出在外观模式的作用下,我们客户端只依赖外观一个接口,而在原始的方式下,我们的客户端依赖于整个子系统,所以外观模式主要解决的是类之间的耦合过于复杂。

                     附上LZ运行结果。

                     以上便是标准的外观模式展现,LZ下面再给出需要知晓的几点。

                     1,实际使用当中,接口并不是必须的,虽说根据依赖倒置原则,无论是处于高层的外观层,还是处于底层的子系统,都应该依赖于抽象,但是这会倒置子系统的每一个实现都要对应一个接口,从而导致系统的复杂性增加,所以这样做并不是必须的。

                     2,外观接口当中并不一定是子系统中某几个功能的组合,也可以是将子系统中某一个接口的某一功能单独暴露给客户端。

                     3,外观接口如果需要暴露给客户端很多的功能的话,可以将外观接口拆分为若干个外观接口,如此便会形成一层外观层。

                     上述LZ给出的第三点,便是为了引出我们标题当中的service,相信各位做过web开发的都见过我们项目中很多的service和dao(注:小型项目或许不需要service这一层),这一层service层,有一个非常重要的作用,就是为了方便我们管理项目中与业务逻辑相关的事物,而service层,其实是给我们的事务管理器提供了一个可以方便的配置切入点的事物管理层。

                     除了上述这个重要的功能外,service层同时也是组合dao层暴露给action的功能,dao层的各个类只是简单的数据操作对象,它们不具有业务逻辑,而赋予了它们业务逻辑方便action调用的功臣,正是service这一层。各位可以想象一下,假设没有service这一层,你的action当中有很多功能需要依赖多少个dao才可以完成工作。

                    同时在WEB项目中,有的项目会抽象出一层service接口和一层dao接口,这是为了降低客户端(这里的客户端可以认为是action)与业务实现细节以及service外观层与数据操作实现细节的耦合,而有的项目则没有抽象层,这也并非就是不合适的。

                    首先添加抽象层会大大的加剧项目的类文件数量,从而使项目的复杂性增加,而且在项目刚进入开发的时候,往往接口是不稳定的,因为我们经常会需要要给某一个service添加一个方法,而为了将方法暴露给客户端(即action),我们必须将该方法添加到对应的接口当中。

                    所以针对这一情况,我们更好的做法是等到接口行为相对稳定时,再考虑是否要重构去添加抽象的接口,而且现在的IDE工具都在一定程度上对重构进行了支持,比如eclipse就可以直接导出一个类的接口,所以我们完全可以在需要时快速的给项目添加抽象的接口层。

                    相比起观察者模式,适配器模式等适合小规模使用的设计模式,外观模式更多的是大范围的使用,它会是很多时候支撑我们整个架构的设计思路。

                    鉴于此,LZ此处不再给出具体的service和dao的示例,各位的项目中到处都充斥着这种例子。

                    如果形象的去形容外观模式在WEB中的应用,可以说它让action和dao分了手,而插入了一个第三者service,断开了action与dao的耦合,转而使用更高层的service。

                    这里需要提醒各位的是,外观模式并不是简单的使用组合将功能组合起来,也就是说它的重点不在组合功能,而在于制作一个对外暴露的外观。它一般是用来将一个子系统(注意,是一个子系统,也就是说外观并不是简单的几个类的组合就是外观模式了)的功能进行调配,暴露给客户端一个外部的表象,使得客户端与子系统断开依赖关系。

                    由于外观模式属于一种“大”模式,所以我们平时很少会接触到,但是有很多技术的应用,其实都有着外观模式的影子。

                    比如webservice,它是给一个WEB应用提供一个外观,让客户端可以调用一些接口去使用WEB应用当中的一些功能或者说服务。再比如API,中文名称应用程序接口,它其实也可以看做是给底层的操作系统做了一层外观,使程序猿在编程的时候可以直接使用外观提供的接口,从而间接的指挥操作系统完成一些事情。

                    本次外观模式的分享,LZ没有像之前一样写一堆示例代码给各位看,更多的是在讨论外观模式的应用场景和应用范围,希望各位看完之后对外观模式有一个宏观的认识,而不是仅限于代码层次的理解。

                    好了,本次外观模式的分享就到此结束了,谢谢各位的收看,下期再见。

                    下期预告,命令模式。

                   

 

                   

                     








版权声明:本文为博主原创文章,支持转载,但转载时请务必在明显位置,给出原文作者名字(左潇龙)及原文连接,否则,作者将保留追究法律责任的权利。

(十一)外观模式详解(Service第三者插足,让action与dao分手)

作者:zuoxiaolong8810(左潇龙),转载请注明出处。                   各位好,LZ今天给各位分享一个不太熟悉的面孔,但却是我们最经常使用的设计模式,外观模式。   ...
  • zuoxiaolong8810
  • zuoxiaolong8810
  • 2013年06月22日 23:25
  • 2422

外观模式详解(Service第三者插足,让action与dao分手)

外观模式详解(Service第三者插足,让action与dao分手)                   作者:zuoxiaolong8810(左潇龙),转载请注明出处,特别说明:本博文来自博主...
  • wxl1234579
  • wxl1234579
  • 2016年10月08日 16:10
  • 136

(十一)外观模式详解(Service第三者插足,让action与dao分手)

作者:zuoxiaolong8810(左潇龙),转载请注明出处,特别说明:本博文来自博主原博客,为保证新博客中博文的完整性,特复制到此留存,如需转载请注明新博客地址即可。              ...
  • u013344397
  • u013344397
  • 2016年11月29日 22:41
  • 57

开发设计模式

一、观察者Observer 观察者模式定义了对象之间的一对多依赖,当一个对象改变状态时,它的所有依赖者都会收到通知并自动更新。为了交互对象之间的松耦合设计。 二、工厂模式 工厂方法模式实例化对象...
  • u013936522
  • u013936522
  • 2015年04月02日 14:32
  • 326

设计模式大杂烩(24种设计模式的总结以及学习设计模式的几点建议)

作者:zuoxiaolong8810(左潇龙),转载请注明出处。                 迄今为止,LZ已经将24种设计模式介绍完了,其中包括GOF23种设计模式以及简单工厂模式,这些设计模式...
  • zuoxiaolong8810
  • zuoxiaolong8810
  • 2013年08月14日 11:37
  • 3637

小三上位中的数学问题

由“第三者插足”产生的暧昧关系数量惊人。虽然这个现象很普遍,但是人们还几乎没研究过这种关系究竟品质如何。最近,社会心理学家约书亚·福斯特(Joshua Foster)及其同事的一项研究发现,这种关系无...
  • skyworth0103
  • skyworth0103
  • 2014年11月05日 20:59
  • 394

关于MVC结构中的action,service,dao,domain的解释

service是业务层,dao是数据访问层。简单的说DAO层是跟数据库打交道的,service层是处理一些业务流程的 表示层调用控制层,控制层调用业务层,业务层调用数据访问层。 举个最简单的例子,...
  • kyswdzz_0
  • kyswdzz_0
  • 2015年07月09日 10:04
  • 1985

设计模式大杂烩(24种设计模式的总结以及学习设计模式的几点建议)

转自:http://www.cnblogs.com/zuoxiaolong/p/pattern26.html#undefined 设计模式大杂烩(24种设计模式的总结以及学习设计模式的几点建议)...
  • benxiaohai888
  • benxiaohai888
  • 2017年10月15日 16:39
  • 73

JAVA设计模式(开篇)

设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问,设计模式于...
  • read22580
  • read22580
  • 2016年12月05日 22:36
  • 131
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:(十一)外观模式详解(Service第三者插足,让action与dao分手)
举报原因:
原因补充:

(最多只允许输入30个字)