常用设计模式解读与应用实例

常用设计模式解读与应用实例使用场景总结：当需要动态地给一个对象添加功能，这些功能可以动态地被撤销；或者当不能采用继承的方式进行扩展，或者采用继承不利于系统扩展和维护时。2.3代理模式(ProxyPattern)问题场景：在某些情况下，我们不希望或不能直接访问某个对象，例如该对象位于远程服务器上、创建成本很高、或者需要进行访问控制、日志记录等额外处理。核心思想：为其他对象提供一种代理以控制对这个对象的访问。代理对象在客户端和目标对象之间起到了中介的作用，可以实现对目标对象的保护、增强或简化访问。实现要点：*抽象主题（Subject）：定义目标对象和代理对象的共同接口。*真实主题（RealSubject）：实现抽象主题，是代理对象所代表的真实对象。*代理（Proxy）：实现抽象主题，并持有真实主题的引用。在其方法中，通常会调用真实主题的相应方法，并可以在调用前后添加额外操作。常见类型：*远程代理：为远程对象提供本地代理。*虚拟代理：延迟创建开销大的对象，直到真正需要时才创建。*保护代理：控制对真实对象的访问权限。*智能引用代理：在访问对象时执行一些额外操作，如计数引用、日志记录、缓存等。应用实例：图片懒加载。在一个图片查看器应用中，如果一次性加载所有高清图片，会耗费大量内存和带宽。我们可以为图片对象创建一个虚拟代理`ImageProxy`。当用户浏览图片列表时，代理对象先显示一个占位符（如缩略图或加载提示），只有当用户真正点击查看某张图片时，代理对象才会创建并加载真实的高清图片对象。使用场景总结：当需要在访问一个对象之前或之后执行一些特定的操作，或者需要对访问进行控制时，代理模式是一个很好的选择。三、行为型模式：对象间的通信与协作行为型模式关注对象之间的交互和职责分配，旨在通过定义清晰的通信方式来实现复杂的行为控制。3.1观察者模式(ObserverPattern)问题场景：在许多应用中，存在着一种一对多的依赖关系，即当一个对象的状态发生改变时，所有依赖于它的对象都需要得到通知并自动更新。例如，股票行情显示系统，当股票价格变动时，所有订阅了该股票的客户端都应实时看到最新价格。核心思想：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都能得到通知并被自动更新。观察者模式也称为发布-订阅（Publish-Subscribe）模式。实现要点：*主题（Subject/Observable）：被观察的对象。它维护一个观察者列表，可以添加、移除观察者，并在状态变化时通知所有注册的观察者。*观察者（Observer）：观察主题的对象。它定义了一个更新接口，当主题状态变化时，主题会调用此接口通知观察者。应用实例：一个简单的新闻订阅系统。`NewsAgency`作为主题，它会发布各种新闻。`NewsReader`作为观察者，它们可以向`NewsAgency`订阅新闻。当`NewsAgency`有新新闻发布时（状态改变），会遍历所有订阅的`NewsReader`，调用它们的`update(Newsnews)`方法，从而使读者及时获取到新闻。使用场景总结：当一个对象的改变需要同时改变其他对象，且不知道具体有多少对象需要改变时；或者当一个对象必须通知其他对象，而又不能假定其他对象是谁（即解耦发送者和接收者）。3.2策略模式(StrategyPattern)问题场景：当一个问题存在多种解决方案，且这些方案可以相互替换时，如果将所有方案的逻辑都写在一个类中，会导致该类变得臃肿不堪，难以维护和扩展。例如，一个电商系统的促销活动，可能有满减、打折、返券等多种优惠策略，并且策略可能随时间变化。核心思想：定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。策略模式让算法的变化独立于使用算法的客户。实现要点：*抽象策略（Strategy）：定义所有支持的算法的公共接口。*具体策略（ConcreteStrategy）：实现抽象策略接口，封装具体的算法实现。*上下文（Context）：持有一个策略对象的引用，负责使用策略对象。上下文可以通过构造器或setter方法来设置具体的策略。应用实例：电商系统的折扣计算。定义一个`DiscountStrategy`接口，包含`calculateDiscount(doubleprice)`方法。然后实现`FullReductionStrategy`（满减）、`PercentageDiscountStrategy`（打折）、`CashbackStrategy`（返券）等具体策略类。`Order`类作为上下文，它包含一个`DiscountStrategy`类型的成员变量。当计算订单最终价格时，`Order`会委托给其持有的`DiscountStrategy`对象来计算折扣。这样，当需要更换折扣策略时，只需为`Order`对象设置不同的`DiscountStrategy`实例即可，无需修改`Order`类本身。使用场景总结：系统有多种算法可以实现同一个目标，且这些算法经常需要切换；或者需要屏蔽算法的具体实现细节，只对外暴露统一接口。四、总结与思考设计模式并非银弹，没有放之四海而皆准的模式。本文介绍的这些模式只是众多设计模式中的沧海一粟，但它们在实际开发中出镜率极高。理解设计模式的关键在于把握其“为什么”（解决什么问题），而不仅仅是“是什么”（结构和代码）。在应用设计模式时，应遵循以下原则：1.理解为先：深入理解模式的意图、适用场景和优缺点，不要为了用模式而用模式。2.问题驱动：先识别问题，再选择合适的模式，而不是拿着模式去找问题。3.灵活变通：实际应用中，可能需要根据具体情况对模式进行适当调整和组合，而不是生搬硬套。4.关注基础：设计模式是基于面向对象的封装、继承、多态三大特性，以及单一职责、开闭原则