外观模式(Facade)
为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用
咱们暑假学习,好多同学都选择自己做饭吃,今天就来介绍两道具有代表性的大众喜爱的传统菜:红烧排骨、红烧鱼。
红烧排骨和红烧鱼大概的制作步骤都差不多分为四步:准备材料、腌制材料、煎炸、调汁。然后就可以做出一道丰盛的红烧排骨和红烧鱼了!然后,我们必须记得制作的每一个步骤,而且顺序还不能颠倒,否则做出的效果就不一样了。怎么让我们便于实现呢?就是我们今天将的外观模式。
外观简单来说就是提供一个单独的对外接口,用于作为外部应用和内部复杂系统的桥梁。外部 应用不必知道系统内部的实现细节。外观模式就像饭店中的厨师,他知道红烧排骨该怎么做,我们去饭店吃饭,只需要看菜谱、点菜就行了!
外观模式类图:
Facade(外观角色):构成系统内部复杂子系统的单一窗口,对系统外部提供更高一级的接口API。
SubSystem(子系统角色):系统内部各种子系统各司其职,做好“本职工作”。外观角色的存在对它们不产生任何影响,它们听从外观角色的调用,但不会反过来调用外观角色。
Client(客户端角色):作为外部应用的客户端角色,不关系系统内部复杂子系统的运作情况,而只于外观角色之间通信获得数据和结果。
主要优点:
1.它对客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并使得子系统使用起来更加容易。通过引入外观模式,客户端代码将变得很简单,与之关联的对象也很少。
2.它实现了子系统与客户端之间的松耦合关系,这使得子系统的变化不会影响到调用它的客户端,只需要调整外观类即可。
3. 一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象。
1.不能很好地限制客户端直接使用子系统类,如果对客户端访问子系统类做太多的限制则减少了可变性和灵活 性。
2. 如果设计不当,增加新的子系统可能需要修改外观类的源代码,违背了开闭原则。
1. 当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。
2.客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦,从而提高子系统的独立性和可移植性。
3.在层次化结构中,可以使用外观模式定义系统中每一层的入口,层与层之间不直接产生联系,而通过外观类建立联系,降低层之间的耦合度。
相关的模式:
1.抽象工厂:抽象工厂可以理解为与产生复杂对象有关的外观模式,因为在抽象工厂中提供更高一级的调用接口API,供外部应用调用获得对象实例。
2.单例:外观与单例联系比较紧密,因为一般情况向,外观经常被设计为单例运作,供外部应用调用。
3.中介者:中介者扮演系统中各个参与者的中间人,封装各个参与者之间的交互,中介者使得系统中各个对象之间不需要显式地相互调用,从而使系统的各个参与者相互解耦。
为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用
咱们暑假学习,好多同学都选择自己做饭吃,今天就来介绍两道具有代表性的大众喜爱的传统菜:红烧排骨、红烧鱼。
红烧排骨和红烧鱼大概的制作步骤都差不多分为四步:准备材料、腌制材料、煎炸、调汁。然后就可以做出一道丰盛的红烧排骨和红烧鱼了!然后,我们必须记得制作的每一个步骤,而且顺序还不能颠倒,否则做出的效果就不一样了。怎么让我们便于实现呢?就是我们今天将的外观模式。
外观简单来说就是提供一个单独的对外接口,用于作为外部应用和内部复杂系统的桥梁。外部 应用不必知道系统内部的实现细节。外观模式就像饭店中的厨师,他知道红烧排骨该怎么做,我们去饭店吃饭,只需要看菜谱、点菜就行了!
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace 外观
{
class Program
{
//做菜需要的材料类
public class Material
{
//做红烧排骨需要的材料
public void Spareribs()
{
Console.WriteLine("准备猪排骨500克,葱末、姜末、酱油、花生油、白糖、醋、料酒、盐各适量...");
}
//做红烧鱼需要的材料
public void Fish()
{
Console.WriteLine("准备鱼500克,葱末、姜末、酱油、花生油、白糖、醋、料酒、盐各适量..");
}
}
//腌制材料类
public class Cure
{
//腌制排骨
public void Spareribs()
{
Console.WriteLine("将排骨洗净剁成3厘米长段,用开水汆一下,捞出放盆内,加入盐、酱油腌入味...");
}
//腌制鱼
public void Fish()
{
Console.WriteLine("鱼收拾干净,擦干鱼皮后,表面剌花刀,用盐与姜腌制2-3小时...");
}
}
//煎炸材料类
public class Fry
{
//给排骨上色
public void Spareribs()
{
Console.WriteLine("锅里放一点点油,放入冰糖,用小火炒糖色,熬到糖的颜色变成浅褐色把汆过水的排骨倒入一起翻炒...");
}
//炸鱼
public void Fish()
{
Console.WriteLine("油加热至八成熟,提起演好的鱼尾放入油锅中,炸至两面金黄...");
}
}
//最后的调汁类
public class Sauce
{
//红烧排骨调汁
public void Spareribs()
{
Console.WriteLine("炒锅留少许油烧热,下入葱花、姜末爆香,加入适量清水、酱油、醋、料酒,倒入排骨,烧开后用慢火煨至汤汁浓、排骨熟,出锅即可!");
}
//红烧鱼调汁
public void Fish()
{
Console.WriteLine("留底油,放入花椒、干辣椒、八角、葱姜蒜大火爆香后,放入炸好的鱼,依次放入料酒、生抽、老抽、盐、适量清水,大货烧开后,关中小火烧15-20分钟,出锅即可!");
}
}
//红烧排骨外观类
public class SpareribsFacade
{
private Material material=new Material ();
private Cure cure=new Cure();
private Fry fry=new Fry();
private Sauce sauce=new Sauce();
public void CookSpareribs()
{
Console.Write("第一步:");
material.Spareribs ();
Console.Write("第二步:");
cure.Spareribs ();
Console.Write("第三步:");
fry.Spareribs ();
Console.Write("第四步:");
sauce .Spareribs ();
}
}
//红烧鱼外观类
public class FishFacade
{
private Material material=new Material ();
private Cure cure=new Cure();
private Fry fry=new Fry();
private Sauce sauce=new Sauce();
public void CookFish()
{
Console.Write("第一步:");
material.Fish ();
Console.Write("第二步:");
cure.Fish ();
Console.Write("第三步:");
fry.Fish ();
Console.Write("第四步:");
sauce.Fish ();
}
}
static void Main(string[] args)
{
//开始做红烧排骨了
Console.WriteLine("----开始做红烧排骨...");
SpareribsFacade spareribsFacade=new SpareribsFacade ();
spareribsFacade .CookSpareribs ();
Console.WriteLine("----红烧排骨制作完成!");
Console.WriteLine();
//开始做红烧鱼了
Console.WriteLine("----开始做红烧鱼...");
FishFacade fishFacade=new FishFacade ();
fishFacade .CookFish ();
Console.WriteLine("----红烧鱼制作完成!");
Console.Read();
}
}
}
外观模式类图:
Facade(外观角色):构成系统内部复杂子系统的单一窗口,对系统外部提供更高一级的接口API。
SubSystem(子系统角色):系统内部各种子系统各司其职,做好“本职工作”。外观角色的存在对它们不产生任何影响,它们听从外观角色的调用,但不会反过来调用外观角色。
Client(客户端角色):作为外部应用的客户端角色,不关系系统内部复杂子系统的运作情况,而只于外观角色之间通信获得数据和结果。
主要优点:
1.它对客户端屏蔽了子系统组件,减少了客户端所需处理的对象数目,并使得子系统使用起来更加容易。通过引入外观模式,客户端代码将变得很简单,与之关联的对象也很少。
2.它实现了子系统与客户端之间的松耦合关系,这使得子系统的变化不会影响到调用它的客户端,只需要调整外观类即可。
3. 一个子系统的修改对其他子系统没有任何影响,而且子系统内部变化也不会影响到外观对象。
1.不能很好地限制客户端直接使用子系统类,如果对客户端访问子系统类做太多的限制则减少了可变性和灵活 性。
2. 如果设计不当,增加新的子系统可能需要修改外观类的源代码,违背了开闭原则。
1. 当要为访问一系列复杂的子系统提供一个简单入口时可以使用外观模式。
2.客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦,从而提高子系统的独立性和可移植性。
3.在层次化结构中,可以使用外观模式定义系统中每一层的入口,层与层之间不直接产生联系,而通过外观类建立联系,降低层之间的耦合度。
相关的模式:
1.抽象工厂:抽象工厂可以理解为与产生复杂对象有关的外观模式,因为在抽象工厂中提供更高一级的调用接口API,供外部应用调用获得对象实例。
2.单例:外观与单例联系比较紧密,因为一般情况向,外观经常被设计为单例运作,供外部应用调用。
3.中介者:中介者扮演系统中各个参与者的中间人,封装各个参与者之间的交互,中介者使得系统中各个对象之间不需要显式地相互调用,从而使系统的各个参与者相互解耦。