Facade模式
系统的复杂度
假设我们需要开发一个坦克模拟系统用于模拟坦克车在各种作战环境中的行为,其中坦克系统由引擎,控制器,车轮,车身等各子系统构成。
public class Wheel
{
public void WAction1(){...}
public void WAction2(){...}
}
public class Engine
{
public void EAction1(){...}
public void EAction2(){...}
}
public class Bodywork
{
public void BAction1(){...}
public void BAction2(){...}
}
public class Controller
{
public void CAction1(){...}
public void CAction2(){...}
}
动机(Motivation)
上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合,随着外部客户程序和各子系统的深化,这种过多的耦合面临很多变化的挑战。
如何简化外部客户程序和系统间的交互接口?如何将客户程序的深化和内部子系统的变化之间的依赖相互解耦?
意图(Intent)
为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。
--设计模式 GoF
难点一:使用internal封闭内部实现,只公开一个TankFacade类给外部,结构稳定,又适用了尽量依赖高层抽象,而不依赖实现细节。高层是相对稳定的,低层是相对易碎的。

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

Facade模式的几个要点
l 从客户程序的角度来看,Facade模式不仅简化了整个组件系统的接口,同时对于组件内部与客户程序来说,从某种程度上也达到了一种“解耦”的效果—内部子系统的任何变化不会影响到Facade接口的变化。
l Facade设计模式更注重从架构的层次去看整个系统,而不是单个类的层次。Facade很多时候更是一种架构设计模式。
l 注意区分Facade模式,Adapter模式,Bridge模式与Decorator模式。Facade模式注重简化接口,Adapter注重转换接口,Bridge模式注重分享接口(抽象)与其实现,Decorator模式注重稳定接口的前提下为对象扩展功能。
源自:李建忠老师
这个模式其实就是封装。

KK: [






DJ: [






