前一段时间写过关于机房重构的七层架构，里面包括一个外观层。机房重构也敲了好长时间了，却始终不太清楚，这个外观模式究竟有什么作用？大家都敲过机房收费系统，知道在这个系统中一般都仅仅涉及到一个表。结构相对来说比較简单。所以这样给我自己的一个困惑，就是用不用外观模式貌似没有什么差别。那么在七层架构中为什么还要有外观设计模式的存在？
事实上在这个问题的前提，是我还不能清楚的解释外观模式是如何的一个设计模式。产生的背景，定义，运用的优点。以及缺点吧。
不总结一下。永远不知道掌握多少。尝试总结一下。
首先一张图反映一个混乱的系统，阐述外观产生背景
正是由于系统的混乱。不利于后期的维护，所以有了外观模式。增加外观模式之后的系统。
是不是瞬间清晰非常多，所以尝试着使用设计模式，它会帮助我们更好的工作。
定义
为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口。这个接口使得这一子系统更加easy使用。
以下用一个程序说明问题
class SubSystemA
{
public void MethodA()
{
//业务实现代码
}
}
class SubSystemB
{
public void MethodB()
{
//业务实现代码
}
}
class SubSystemC
{
public void MethodC()
{
//业务实现代码
}
} 使用外观模式。代码编写例如以下
class Facade
{
private SubSystemA obj1 = new SubSystemA();
private SubSystemB obj2 = new SubSystemB();
private SubSystemC obj3 = new SubSystemC();
public void Method()
{
obj1.MethodA();
obj2.MethodB();
obj3.MethodC();
}
} class Program
{
static void Main(string[] args)
{
Facade facade = new Facade();
facade.Method();
}
} 再来看看不用外观模式的
class Program
{
static void Main(string[] args)
{
SubSystemA a1=new SubSystemA ();
SubSystemB b1=new SubSystemB ();
SubSystemC c1 = new SubSystemC();
a1.MethodA();
b1.MethodB();
c1.MethodC();
Console.Read();
}
}这是连接子系统较少，想象一下假设我们连接数十个子系统。这还指不定是如何一锅乱粥了。。所以用户在面对程序的时候，仅仅须要一个button就能够完毕全部的事情。这样方便程序有谁能不喜欢使用！
看完了图和代码，详细总结一下，外观模式究竟有什么优点！
长处
1、引入外观模式。是客户对子系统的使用变得简单了，降低了与子系统的关联对象，实现了子系统与客户之间的松耦合关系。
2、仅仅是提供了一个訪问子系统的统一入口，并不影响用户直接使用子系统类。
3、减少了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程。
事物都有两面性，所以外观模式相同，假设乱用，也会给我们带来非常大的困扰。说说设计模式的缺点吧。
缺点
1、不能非常好地限制客户使用子系统类。假设对客户訪问子系统类做太多的限制则降低了可变性和灵活性
2、在不引入抽象外观类的情况下。添加新的子系统可能须要改动外观类或client的源码。违背了“开闭原则”
使用情景
1、当要为一个复杂子系统提供一个简单接口时能够使用外观模式。
2、客户程序与多个子系统之间存在非常大的依赖性。引入外观类将子系统与客户以及其它子系统解耦。能够提高子系统的独立性和可移植性。
【总结】
外观模式的主要目的就是为程序做到解耦合。降低程序与细致与子系统之间存在的非常大的依赖性。假设须要实现一个外观模式，须要将子系统组合进外观中。然后将工作托付给外观运行。最大的缺点就是违背了开放封闭原则。
如有理解偏颇之处，还请各位大神斧正，不胜感激！