【有毒的设计模式】外观模式

版权声明:O.O 欢迎转载,如果我有能力写到原创文章的话~ https://blog.csdn.net/qq_16468937/article/details/51096492

//说些废话

其实最近都想偷懒不写设计模式的blog,但是只看不写又记忆不深刻,挺矛盾的,就简单写写吧,总比不写好


//部分资料来源

1.C++设计模式:http://www.jellythink.com/archives/217

2.程杰——大话设计模式


//适用场合

1.需要简化客户端与子系统之间的依赖关系(想要降低客户端与子系统间的耦合度),想抽象出一个接口来调用子类系统。

2.设计初期,意识到要将两个不同的层分离,数据访问层 / 业务逻辑层 / 表示层


//正文

外观模式,为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。[DP]

是 依赖倒转原则 和 迪米特法则 的重要体现。

复习一下:

依赖倒转原则

1.高层模块不应该依赖低层模块。两个都应该依赖抽象。

2.抽象不应该依赖细节。细节应该依赖抽象。



偷懒,不打代码,简单说说。

比如我现在定义了三个子系统ABC。

A里面有一个a_method,用来放置一本算法导论书

B里面有一个b_method,用来放置一个ipad

C里面有一个c_method,用来放置一支笔

那我现在如果要收拾房间,就要在main函数里面,new A,B,C类的对象,abc,然后调用他们的method方法,顺序是abc

这样main函数可读性就差了


外观模式就是加一个D类

然后里面private放上A B C 的对象,public里加一个facade函数,里面就是new abc对象+调用abc的方法。

这样在main函数里面就直接d->facade()就行了,这样就降低了main和子系统的复杂度。


这样的一个好处是,在客户端不用知道abc他们的调用顺序,也就不要去理解那么复杂的逻辑了。

这只是简单例子,如果是大型项目,子系统更是多得很,如果每次都要把子系统理解完再调用,你的时间就GG了,有了接口模式,你或许可以根据外观模式的接口的说明然后决定这个高层接口是否满足需求。


//问题

1.

Q:为什么我觉得外观模式有点像简单工厂模式?

A:开始是觉得有点像的,不过后来想了下,我的理解是,简单工厂模式是针对对象创建类封装的,而且那对象都有关联,都继承自一个父类,对父类使用简单工厂。

       但是外观模式是针对不同类,并且调用类成员函数。


2.

Q:什么时候用外观模式?

A:大型系统,子系统过多过杂,可以考虑抽象一部分功能出来实现一个接口类

猜你喜欢

转载自blog.csdn.net/qq_16468937/article/details/51096492