外观模式

一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第11天，点击查看活动详情。

外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。

这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。

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

外观模式更像是一种思想，单独为创建子系统而存在。比如基于现在已有的功能，需要对客服人员提供一套客服系统，可以定义一套接口，而不暴露原平台系统的各个细节实现。

优点：实现了统一的接口，更容易做安全控制。

缺点：扩展性、重用性低。原平台业务的扩展，子系统需要单独修改。

享元模式（Flyweight Pattern）主要用于减少创建对象的数量，以减少内存占用和提高性能。这种类型的设计模式属于结构型模式，它提供了减少对象数量从而改善应用所需的对象结构的方式。

作用：在有大量对象时，有可能会造成内存溢出，我们把其中共同的部分抽象出来，如果有相同的业务请求，直接返回在内存中已有的对象，避免重新创建。

数据库的数据池是享元模式思想的应用。

中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。

当多个类相互耦合，形成了网状结构，建立一个中间类用来解耦。

中介者模式有点像数据库的关联表，将两者之间建立关系。