做系统 和网站前端,google网站管理员中心,深圳公司注册核名官网,app开发经费预算表目录
定义
类图
角色
角色详解
Strategy#xff08;抽象策略类#xff09;
Context#xff08;环境类 / 上下文类#xff09;
ConcreteStrategy#xff08;具体策略类#xff09;
优缺点
优点
缺点
使用场景
类行为差异场景
动态算法选…目录
定义
类图
角色
角色详解
Strategy抽象策略类
Context环境类 / 上下文类
ConcreteStrategy具体策略类
优缺点
优点
缺点
使用场景
类行为差异场景
动态算法选择场景
避免复杂条件语句场景
保密性与安全性场景 定义 策略模式作为一种行为型设计模式核心在于将对象的行为与对象本身分离开来。它把一系列相关的行为定义为一个行为接口然后通过不同的具体类来实现这些行为。这种设计方式使得行为可以独立于使用它们的对象进行变化极大地增强了系统的灵活性和可扩展性。 简单来说策略模式就像是为你的软件系统准备了一个 “行为工具箱”里面装满了各种不同的行为工具。当你的对象需要执行某种行为时它可以从这个工具箱中挑选合适的工具而无需在自身内部固化特定的行为逻辑。例如在一个电商系统中对于商品的促销活动有打折、满减、赠品等多种策略。通过策略模式我们可以将这些促销策略分别定义为不同的类每个类实现促销行为的接口。这样在不同的促销场景下只需选择相应的策略类商品就能以不同的促销方式进行销售而无需频繁修改商品类的代码。 从本质上讲策略模式的最大特点就是行为的变化性和可替代性。它允许在运行时动态地选择和切换行为就如同你在玩游戏时可以根据不同的游戏场景和对手特点灵活地选择不同的游戏策略一样。每个具体的行为实现就像是一个独立的策略它们之间可以相互替换以适应不同的业务需求和变化。在编程世界中这种模式使得算法能够独立于使用它的用户即对象而变化为软件系统注入了强大的生命力。
类图 角色 策略模式的类图清晰地展示了其核心组成部分以及它们之间的关系主要涉及三个关键角色 Strategy抽象策略类这是一个接口或抽象类它定义了一系列算法标识也就是若干个抽象方法。这些抽象方法代表了不同策略所共有的行为特征具体的策略实现类必须实现这些方法。例如在一个图形绘制系统中抽象策略类可能定义了一个 “drawShape” 的抽象方法用于绘制不同形状的图形。而具体的圆形绘制策略类、矩形绘制策略类等都需要实现这个 “drawShape” 方法以提供各自独特的绘制逻辑。抽象策略类的存在就像是为所有具体策略类制定了一个统一的规范确保它们在行为上具有一致性和可替代性。 Context环境类 / 上下文类环境类依赖于抽象策略类它包含一个用策略接口声明的变量。这个变量就像是一个 “插座”可以插入不同的具体策略类 “插头”。环境类提供一个方法这个方法持有一个策略类的引用并最终供客户端调用。在调用时该方法会委托策略变量调用具体策略所实现的策略接口中的方法。例如在一个旅行规划系统中环境类可以是 “TravelPlanner”它有一个属性是 “TravelStrategy” 类型用于存储不同的旅行策略如飞机旅行策略、火车旅行策略等。“TravelPlanner” 类还提供一个 “planTravel” 方法当客户端调用这个方法时它会根据当前设置的 “TravelStrategy” 对象调用相应策略的旅行规划方法如飞机旅行策略的 “planByAir” 方法或火车旅行策略的 “planByTrain” 方法。环境类在策略模式中起到了桥梁的作用它将客户端的请求与具体的策略实现连接起来使得客户端无需关心具体策略的细节只需与环境类进行交互即可。 ConcreteStrategy具体策略类具体策略类是实现抽象策略接口的类它们针对不同的具体情况实现了策略接口所定义的抽象方法给出了算法标识的具体实现。每个具体策略类就像是一把独特的 “钥匙”对应着解决特定问题的特定算法或行为。例如在一个排序算法的应用场景中可能有 “BubbleSortStrategy”冒泡排序策略类和 “QuickSortStrategy”快速排序策略类等具体策略类。“BubbleSortStrategy” 类实现了抽象策略接口中定义的 “sort” 方法使用冒泡排序算法对数据进行排序“QuickSortStrategy” 类同样实现了 “sort” 方法但采用的是快速排序算法。通过这种方式不同的具体策略类可以根据实际需求灵活地替换使用以达到最佳的排序效果。
角色详解
Strategy抽象策略类 行为抽象抽象策略类的首要职责是对一系列相关行为进行抽象。它通过定义抽象方法将不同具体策略类的共同行为特征提取出来形成一个统一的行为接口。这个接口就像是一个蓝图为具体策略类的实现提供了指导和规范。例如在一个支付系统中抽象策略类 “PaymentStrategy” 可以定义一个 “processPayment” 的抽象方法用于处理支付行为。无论是信用卡支付策略、支付宝支付策略还是微信支付策略都需要实现这个 “processPayment” 方法以完成各自特定的支付流程。通过这种行为抽象不同的支付策略在对外表现上具有了一致性都遵循 “PaymentStrategy” 接口所定义的行为规范使得它们可以在相同的环境中被灵活使用。 代码复用当多个具体策略类中存在一些共同的代码逻辑时抽象策略类可以将这部分公共代码提取出来放在自身的实现中。这样具体策略类只需继承抽象策略类并专注于实现各自特有的行为逻辑避免了代码的重复编写。例如在一个图像处理系统中抽象策略类 “ImageProcessingStrategy” 可能定义了一些通用的图像预处理方法如调整图像大小、转换图像格式等。具体的图像模糊处理策略类、图像锐化处理策略类等都继承自 “ImageProcessingStrategy”它们可以复用抽象策略类中的预处理方法同时实现自己独特的图像特效处理逻辑。这种代码复用机制不仅提高了开发效率还增强了代码的可维护性因为当公共代码需要修改时只需在抽象策略类中进行一次修改所有继承它的具体策略类都会自动应用这些修改。 扩展性支持抽象策略类为系统的扩展性提供了有力支持。当有新的行为需求出现时只需创建一个新的具体策略类实现抽象策略类定义的接口即可。无需对现有的代码进行大规模修改就能轻松地将新的策略集成到系统中。例如在一个游戏角色的技能系统中如果需要添加一种新的技能策略如 “FreezeSkillStrategy”冰冻技能策略只需要创建一个实现 “SkillStrategy” 抽象策略接口的 “FreezeSkillStrategy” 类并实现接口中的 “executeSkill” 方法定义冰冻技能的具体执行逻辑。然后在游戏运行时就可以根据需要动态地选择使用这个新的技能策略而不会影响到其他已有的技能策略和游戏系统的整体架构。
Context环境类 / 上下文类 策略引用管理环境类负责持有一个抽象策略类的引用这个引用就像是一个 “容器”可以容纳不同的具体策略对象。通过这种引用管理方式环境类可以在运行时动态地切换所使用的策略。例如在一个物流配送系统中环境类 “DeliveryContext” 有一个 “DeliveryStrategy” 类型的属性用于存储不同的配送策略如快递配送策略、同城配送策略等。在系统初始化时可以根据用户的选择或系统的配置将相应的具体配送策略对象赋值给这个属性。当需要执行配送任务时“DeliveryContext” 就可以通过这个引用调用具体配送策略的方法实现不同方式的配送服务。这种策略引用管理机制使得系统能够根据实际情况灵活地选择和应用不同的策略提高了系统的适应性和灵活性。 客户端交互接口环境类为客户端提供了一个统一的交互接口客户端通过调用环境类的方法来触发相应的策略行为而无需了解具体策略的实现细节。这样客户端与具体策略类之间实现了松耦合降低了客户端代码与策略实现代码之间的依赖关系。例如在一个音乐播放系统中环境类 “MusicPlayerContext” 提供了一个 “playMusic” 方法客户端只需调用这个方法而无需关心音乐播放是采用在线播放策略还是本地播放策略。“MusicPlayerContext” 会根据当前设置的 “MusicPlayStrategy” 对象调用相应策略的播放方法实现音乐的播放功能。这种设计方式使得客户端代码更加简洁、易读同时也方便了系统的维护和扩展因为当需要更换音乐播放策略时只需在 “MusicPlayerContext” 中修改所引用的策略对象而无需修改客户端代码。 策略执行协调环境类在策略执行过程中起到了协调的作用。它不仅负责将客户端的请求传递给具体策略类还可以在策略执行前后进行一些额外的处理如日志记录、权限验证等。例如在一个订单处理系统中环境类 “OrderProcessingContext” 在调用具体的订单处理策略如普通订单处理策略、加急订单处理策略的 “processOrder” 方法之前可以先记录订单处理的开始时间和相关信息在策略执行结束后可以记录订单处理的结果和结束时间并根据处理结果进行相应的后续操作如发送订单处理成功或失败的通知。通过这种策略执行协调机制环境类可以对整个策略执行过程进行有效的管理和控制确保系统的运行符合业务需求和规范。
ConcreteStrategy具体策略类 算法实现具体策略类的核心任务是实现抽象策略类定义的抽象方法提供具体的算法实现。每个具体策略类针对特定的业务场景或问题采用不同的算法或逻辑来完成相应的行为。例如在一个数据加密系统中“AESEncryptionStrategy” 类实现了抽象策略类 “EncryptionStrategy” 定义的 “encryptData” 方法使用 AES 加密算法对数据进行加密而 “RSAEncryptionStrategy” 类同样实现了 “encryptData” 方法但采用的是 RSA 加密算法。这些具体策略类通过实现各自独特的加密算法为系统提供了多种数据加密选择用户可以根据实际需求和安全要求选择合适的加密策略。 行为定制具体策略类可以根据自身的特点和需求对行为进行定制化处理。它们可以在实现抽象方法的基础上添加额外的逻辑和功能以满足特定场景下的业务需求。例如在一个电商平台的优惠券使用策略中“PercentageDiscountCouponStrategy” 类实现了抽象策略类 “CouponStrategy” 定义的 “applyCoupon” 方法用于计算使用百分比折扣优惠券后的商品价格。在这个方法中除了基本的价格计算逻辑外还可以添加一些定制化的逻辑如判断优惠券是否过期、是否满足使用条件等。通过这种行为定制机制具体策略类能够更加灵活地适应不同的业务场景和变化为系统提供更加丰富和个性化的功能。 可替换性具体策略类之间具有可替换性这是策略模式的重要特性之一。由于它们都实现了相同的抽象策略接口所以在运行时可以根据需要轻松地将一个具体策略类替换为另一个具体策略类而不会影响到系统的其他部分。例如在一个图形渲染系统中起初使用 “OpenGLRenderingStrategy” 类来实现图形渲染功能但随着业务发展和技术升级需要切换到性能更好的 “VulkanRenderingStrategy” 类。由于这两个类都实现了 “RenderingStrategy” 抽象策略接口所以只需在环境类中修改所引用的策略对象将 “OpenGLRenderingStrategy” 替换为 “VulkanRenderingStrategy”系统就可以无缝地切换到新的渲染策略而无需对其他模块的代码进行大规模修改。这种可替换性使得系统能够快速适应不同的需求和变化提高了系统的可维护性和可扩展性。
优缺点
优点 完美支持开闭原则开闭原则是软件设计中的重要原则之一它要求软件系统对扩展开放对修改关闭。策略模式为开闭原则提供了近乎完美的支持。当有新的行为或算法需求出现时我们只需创建一个新的具体策略类实现抽象策略接口然后在环境类中进行简单配置即可将新的策略集成到系统中而无需修改现有系统的核心代码。例如在一个在线教育平台的课程推荐系统中起初使用基于用户历史浏览记录的推荐策略但随着业务发展需要增加基于用户兴趣标签的推荐策略。通过策略模式我们可以创建一个新的 “InterestBasedRecommendationStrategy” 类实现 “RecommendationStrategy” 抽象策略接口然后在课程推荐环境类中添加对这个新策略的支持。这样系统在不修改现有推荐策略代码的基础上成功实现了新推荐策略的扩展有效降低了系统的维护成本和风险。 管理相关算法族策略模式提供了一种有效的方式来管理一组相关的算法。通过将不同的算法封装到各自的具体策略类中并通过抽象策略类进行统一管理我们可以清晰地组织和维护这些算法。例如在一个数据处理系统中有多种数据排序算法冒泡排序、快速排序、归并排序等和数据搜索算法顺序搜索、二分搜索等。通过策略模式我们可以将这些排序算法和搜索算法分别封装到不同的具体策略类中如 “BubbleSortStrategy”“QuickSortStrategy”“SequentialSearchStrategy”“BinarySearchStrategy” 等。这些具体策略类都继承自相应的抽象策略类如 “SortingStrategy”“SearchingStrategy”形成了一个算法族的层次结构。这种组织方式使得算法的管理更加方便易于理解和维护同时也方便了算法的扩展和替换。 替代继承关系在传统的面向对象编程中当一个类需要有多种不同的行为时可能会通过继承来实现即创建多个子类每个子类实现不同的行为。然而这种方式会导致类的数量急剧增加代码的复杂度和维护成本也随之上升并且在运行时难以动态地改变对象的行为。策略模式提供了一种更灵活的替代方案它通过将行为封装到独立的策略类中使得对象可以在运行时动态地选择和切换行为而无需通过继承来实现。例如在一个游戏角色类中如果使用继承来实现不同的攻击行为可能需要创建 “MeleeAttackCharacter”近战攻击角色类、“RangedAttackCharacter”远程攻击角色类等多个子类。而通过策略模式我们可以创建 “MeleeAttackStrategy” 和 “RangedAttackStrategy” 等具体策略类游戏角色类只需持有一个 “AttackStrategy” 抽象策略类的引用在运行时根据实际情况选择不同的攻击策略从而实现不同的攻击行为。这样不仅减少了类的数量降低了代码复杂度还提高了系统的灵活性和可扩展性。 避免多重条件转移语句在没有使用策略模式的情况下当一个对象需要根据不同的条件执行不同的行为时往往会使用多重条件转移语句如 if-else 或 switch 语句。然而随着条件和行为的增加这些条件转移语句会变得冗长、复杂难以阅读和维护。策略模式通过将不同的行为封装到具体策略类中使得条件判断和行为执行的逻辑分离从而避免了使用多重条件转移语句。例如在一个订单处理系统中如果不使用策略模式可能会在订单处理方法中使用大量的 if-else 语句来判断订单类型普通订单、加急订单、团购订单等并根据不同的订单类型执行不同的处理逻辑。而使用策略模式后我们可以创建 “NormalOrderStrategy”“UrgentOrderStrategy”“GroupBuyOrderStrategy” 等具体策略类订单处理环境类只需根据订单类型选择相应的策略类来执行订单处理逻辑无需在代码中编写复杂的条件判断语句。这样代码结构更加清晰可读性和可维护性大大提高。
缺点 客户端知晓策略类在策略模式中客户端必须了解所有可用的策略类并自行决定使用哪一个策略类。这就要求客户端对系统中的各种策略有一定的了解以便能够根据实际需求做出正确的选择。然而在一些复杂的系统中策略类的数量可能较多而且策略的实现细节也可能较为复杂这增加了客户端使用的难度。例如在一个金融投资系统中有多种投资策略如价值投资策略、成长投资策略、量化投资策略等每个策略都有其独特的算法和风险特点。客户端在选择投资策略时需要对这些策略有深入的了解才能做出合适的决策。如果客户端对策略不熟悉可能会选择错误的策略导致投资失败。为了解决这个问题可以在系统中提供一些辅助工具或文档帮助客户端更好地了解和选择策略或者在环境类中提供一些默认的策略选择逻辑降低客户端的使用难度。 策略类数量众多由于策略模式将每个具体的行为都封装成一个独立的策略类当系统中的行为种类较多时会导致策略类的数量急剧增加。这不仅增加了系统的复杂性和维护成本还可能会使代码的结构变得混乱。例如在一个电商平台的促销活动系统中可能有打折、满减、赠品、限时抢购、团购等多种促销策略每种促销策略都需要一个具体的策略类来实现。随着业务的发展和促销活动的不断创新可能还会有更多的促销策略需要添加这将导致策略类的数量不断增加
使用场景
类行为差异场景 当系统中存在众多类其差异仅体现在行为方面时策略模式的优势便得以凸显。以游戏开发为例游戏中有战士、法师、刺客等多种角色类。战士擅长近身物理攻击法师专注远程法术输出刺客则精于潜行暗杀。这些角色类的核心区别就在于战斗行为的不同。运用策略模式我们可以将攻击行为抽象出来创建如近战攻击策略类、远程法术攻击策略类、潜行攻击策略类等。游戏角色类通过持有攻击策略接口的引用在运行时动态选择相应策略。比如战士角色在初始化时可选择近战攻击策略在战斗中能根据局势灵活切换若遇到远程敌人可临时切换为远程攻击策略假设游戏设计允许从而极大地增强了角色行为的灵活性与可扩展性。 再比如电商平台中的不同商品类普通商品、限时折扣商品、团购商品它们的销售行为有所不同。普通商品正常售卖限时折扣商品在特定时间段以折扣价销售团购商品需达到一定购买人数才生效。通过策略模式分别创建普通销售策略类、限时折扣销售策略类、团购销售策略类商品类通过关联相应策略能轻松实现不同销售行为并且在促销活动调整时方便地切换销售策略。
动态算法选择场景 对于需要动态在几种算法中抉择的系统策略模式堪称绝佳之选。在数据处理领域以排序算法为例常见的有冒泡排序、快速排序、归并排序等。不同场景对排序算法的性能要求各异小规模数据可能适合冒泡排序因其实现简单而大规模数据则更适合快速排序或归并排序以提升效率。通过策略模式我们将每种排序算法封装成一个具体策略类如冒泡排序策略类、快速排序策略类、归并排序策略类它们都实现统一的排序策略接口。在数据处理模块中根据数据规模、数据特点等因素动态选择合适的排序策略。例如当处理 100 条以内的用户信息排序时可选用冒泡排序策略处理成千上万条交易数据排序时则切换为快速排序策略确保系统在不同情况下都能高效运行。 在图形渲染系统中也存在类似情况。渲染 2D 图形和 3D 图形需要不同的渲染算法2D 图形渲染可能采用简单的光栅化算法3D 图形渲染则需更复杂的光线追踪算法等。通过策略模式创建 2D 渲染策略类和 3D 渲染策略类渲染引擎类根据要渲染的图形类型动态调用相应的渲染策略实现高效且灵活的图形渲染。
避免复杂条件语句场景 若一个对象存在大量行为若不采用合适模式多重条件选择语句将不可避免导致代码冗长且难以维护。以电商系统的订单处理模块为例订单有普通订单、加急订单、团购订单、退货订单等多种类型每种订单的处理流程和规则大相径庭。传统做法可能是在订单处理方法中使用大量 if - else 或 switch 语句判断订单类型并执行相应处理逻辑随着订单类型增多代码会变得异常复杂。运用策略模式我们创建普通订单处理策略类、加急订单处理策略类、团购订单处理策略类、退货订单处理策略类等订单处理类通过持有订单处理策略接口的引用根据订单实际类型调用对应的策略类方法进行处理。如此一来代码结构清晰新增订单类型时只需添加对应的策略类无需大幅修改原有代码维护成本大幅降低。 在物流配送系统中配送订单也有多种类型如同城配送订单、跨城配送订单、国际配送订单每种订单的配送流程、费用计算、运输方式都不同。如果不使用策略模式配送处理代码将充满复杂的条件判断。采用策略模式后分别构建同城配送策略类、跨城配送策略类、国际配送策略类配送系统根据订单类型调用相应策略让代码简洁明了且易于扩展。
保密性与安全性场景 在保密性与安全性要求较高的场景下策略模式同样发挥着重要作用。在金融加密领域数据加密算法复杂且涉及敏感信息。例如有 AES 加密算法、RSA 加密算法等。通过策略模式将这些加密算法分别封装在 AES 加密策略类、RSA 加密策略类中客户端只需与加密策略接口交互无需知晓复杂的算法细节与相关数据结构。在数据传输或存储前根据安全级别等要求选择合适的加密策略。如普通用户数据可选用 AES 加密策略涉及大额资金交易的数据则采用安全性更高的 RSA 加密策略既保证了算法的保密性与安全性又提升了系统对不同安全需求的适应性。 在企业级系统中访问权限控制也可应用策略模式。不同级别的用户如普通员工、部门经理、系统管理员对系统资源有不同的访问权限。将权限验证算法封装在相应的策略类中如普通员工权限策略类、部门经理权限策略类、系统管理员权限策略类。系统在用户登录访问资源时根据用户角色调用对应的权限策略确保敏感信息的安全访问同时隐藏了复杂的权限验证逻辑。
