一.外观模式介绍与使用场景
外观模式是一种结构设计模式，旨在为复杂系统提供一个简化的接口，以便客户端可以更方便地使用系统。外观模式通过创建一个高层次的接口，将系统的多个子系统封装起来，并提供一个统一的接口给客户端使用。
外观模式的核心思想是通过创建一个外观类（Facade Class），将复杂系统的内部实现细节隐藏起来，只暴露出一个简化的接口给客户端。客户端只需要与外观类进行交互，而不需要直接与子系统的组件进行交互。
外观模式适用场景：
1.当一个系统的复杂性变得很高，由于存在大量的子系统和相互关联的类，导致客户端代码变得冗长和复杂时，可以考虑使用外观模式。外观模式可以将复杂的系统进行封装，提供一个简化的接口给客户端，使得客户端代码更加清晰、易于理解和维护。
2.当客户端与多个子系统进行交互，而这些子系统之间存在复杂的依赖关系时，可以使用外观模式来简化客户端与子系统的交互过程。外观模式可以将这些复杂的依赖关系和交互逻辑封装在外观类中，客户端只需要与外观类进行交互，无需关心子系统之间的具体交互细节。
3.当希望对一个复杂系统进行重构或扩展时，可以使用外观模式来隐藏系统内部的复杂性。外观模式可以提供一个稳定的接口给客户端使用，即使在系统内部发生变化，只需调整外观类而无需修改客户端代码。
4.当需要向客户端隐藏底层实现细节，提供一个高层次的接口时，可以使用外观模式。外观模式可以屏蔽客户端与子系统之间的直接交互，通过外观类提供的简化接口来完成操作。
外观模式常见于以下场景：
在大型软件系统中，可以使用外观模式来封装复杂的子系统，提供一个简化的接口给其他模块或子系统进行调用。
在多层架构中，可以使用外观模式来封装不同层之间的复杂依赖关系，提供一个统一的接口给上层模块进行调用。
在面向服务的架构（SOA）中，可以使用外观模式来封装服务接口，提供一个简化的接口给客户端进行调用，隐藏底层服务的复杂性。
总之，外观模式适用于需要简化复杂系统接口、隐藏系统内部复杂性、减少客户端与子系统的耦合度的场景。它提供了一种简单、统一的方式来与复杂系统进行交互，使系统更易于使用、扩展和维护。
二.外观模式实现
下面我们通过一个简单的demo来了解一下外观模式：
// 子系统A class SubsystemA { public void operationA() { System.out.println("Subsystem A: operation A"); } } // 子系统B class SubsystemB { public void operationB() { System.out.println("Subsystem B: operation B"); } } // 子系统C class SubsystemC { public void operationC() { System.out.println("Subsystem C: operation C"); } } // 外观类 class Facade { private SubsystemA subsystemA; private SubsystemB subsystemB; private SubsystemC subsystemC; public Facade() { subsystemA = new SubsystemA(); subsystemB = new SubsystemB(); subsystemC = new SubsystemC(); } public void operation() { subsystemA.operationA(); subsystemB.operationB(); subsystemC.operationC(); } } // 使用示例 public class Main { public static void main(String[] args) { Facade facade = new Facade(); facade.operation(); } }
在上面的demo中，我们模拟了一个外观模式的场景。子系统A、子系统B和子系统C分别代表了复杂系统中的不同部分或功能模块。
外观类（Facade）封装了这些子系统，并提供了一个简化的接口（operation）给客户端使用。客户端只需要与外观类进行交互，而无需关心子系统的具体实现细节。
在 Main 类的 main 方法中，我们创建了外观类的对象（Facade），并调用其 operation 方法。通过外观类，客户端可以直接使用一个简单的方法来操作整个复杂系统，而不需要了解系统内部的复杂性。
通过使用外观模式，我们将复杂系统的实现细节隐藏起来，提供了一个简单的接口给客户端使用。这样可以降低客户端的复杂度，减少了对系统内部的直接依赖，提高了系统的灵活性和可维护性。外观模式常用于封装复杂的第三方库、提供简化的接口给客户端等场景。
下面我们再来模拟一个外观模式的场景，把电商系统中复杂的购物流程封装到一个外观类中，并提供一个简化的接口给客户端调用：
// 子系统A: 商品管理 class ProductManager { public void addProduct(String productName) { System.out.println("添加商品：" + productName); } public void removeProduct(String productName) { System.out.println("移除商品：" + productName); } } // 子系统B: 购物车管理 class ShoppingCartManager { public void addToCart(String productName) { System.out.println("添加商品到购物车：" + productName); } public void removeFromCart(String productName) { System.out.println("从购物车移除商品：" + productName); } } // 子系统C: 订单管理 class OrderManager { public void createOrder() { System.out.println("创建订单"); } public void cancelOrder() { System.out.println("取消订单"); } } // 外观类 class ShoppingFacade { private ProductManager productManager; private ShoppingCartManager shoppingCartManager; private OrderManager orderManager; public ShoppingFacade() { productManager = new ProductManager(); shoppingCartManager = new ShoppingCartManager(); orderManager = new OrderManager(); } // 提供简化的接口给客户端 public void purchaseProduct(String productName) { productManager.addProduct(productName); shoppingCartManager.addToCart(productName); orderManager.createOrder(); System.out.println("购买成功！"); } public void cancelPurchase(String productName) { orderManager.cancelOrder(); shoppingCartManager.removeFromCart(productName); productManager.removeProduct(productName); System.out.println("取消购买成功！"); } } // 使用示例 public class Main { public static void main(String[] args) { ShoppingFacade shoppingFacade = new ShoppingFacade(); // 购买商品 shoppingFacade.purchaseProduct("iPhone 12"); System.out.println("------------------------------------"); // 取消购买 shoppingFacade.cancelPurchase("iPhone 12"); } }
其中子系统A代表了商品管理，子系统B代表了购物车管理，子系统C代表了订单管理。
外观类（ShoppingFacade）封装了这些子系统，并提供了简化的接口（purchaseProduct和cancelPurchase）给客户端使用。客户端只需要与外观类进行交互，无需了解子系统的具体实现细节。
在 Main 类的 main 方法中，我们创建了外观类的对象（ShoppingFacade），并使用其提供的接口来进行购买商品和取消购买的操作。
通过使用外观模式，我们将复杂的购物流程封装在外观类中，客户端只需要调用外观类提供的简化接口来完成购物操作，而无需关心子系统的具体实现细节。这样可以简化客户端的代码，并提供一个统一的接口来操作购物流程。
以上示例展示了电商系统中使用外观模式的一种实现方式，但具体的设计取决于系统的复杂性和需求。
