一.外观模式介绍与使用场景
外观模式是一种结构设计模式,旨在为复杂系统提供一个简化的接口,以便客户端可以更方便地使用系统。外观模式通过创建一个高层次的接口,将系统的多个子系统封装起来,并提供一个统一的接口给客户端使用。
外观模式的核心思想是通过创建一个外观类(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),并使用其提供的接口来进行购买商品和取消购买的操作。
通过使用外观模式,我们将复杂的购物流程封装在外观类中,客户端只需要调用外观类提供的简化接口来完成购物操作,而无需关心子系统的具体实现细节。这样可以简化客户端的代码,并提供一个统一的接口来操作购物流程。
以上示例展示了电商系统中使用外观模式的一种实现方式,但具体的设计取决于系统的复杂性和需求。