策略模式

今天来讲一下如何通过策略模式和工厂方法来消除累赘的if...else，具体什么是策略模式，大家可以自行百度学习，我就不再这里做过多的介绍了。 注意：如果业务场景简单，建议使用if...else，因为代码逻辑简单，便于理解 Eat.java /** * 策略接口 * */ public interface Eat { public void eatFruit(String fruit); } EatApple.java /** * 具体的策略类：吃苹果 */ public class EatApple implements Eat{ @Override public void eatFruit(String fruit) { System.out.println("吃苹果"); } } EatBanana.java /** * 具体的策略类：吃香蕉 */ public class EatBanana implements Eat { @Override public void eatFruit(String fruit) { System.out.println("吃香蕉"); } } EatPear.java /** * 具体的策略类：吃梨 */ public class EatPear implements Eat { @Override public void eatFruit

版权声明：本文为博主原创文章，未经博主允许不得转载 https://blog.csdn.net/weixin_43835717/article/details/91491140 如果都使用if-else的话，就会使用代码变的臃肿，而且难以复用。那我们就可以根据不同的情况，将不同的方式封装成不同的策略，将策略与它的使用对象分离开来。 案例： 定义注解，标注范围 /** * @author Gjing * 价格范围注解 **/ @Target ( ElementType . TYPE ) @Retention ( RetentionPolicy . RUNTIME ) public @ interface PriceRegion { int min ( ) default 0 ; int max ( ) default Integer . MAX_VALUE ; } 具体策略 /** * @author Gjing * 抽象策略 **/ public interface Price { BigDecimal getPrice ( BigDecimal price ) ; } /** * @author Gjing * 会员,六折 **/ @PriceRegion ( min = 10000 , max = 20000 ) class Member implements Price {

【own】策略模式和状态模式，都是提取动态行为，解耦；if else 系列 策略模式： 在不确定具体行为，提取动态行为，便于后期维护；由于不确定具体的行为，所以行为对象会很多，不利于对象维护； 使用场景： 假设现在要设计一个贩卖各类书籍的电子商务网站的购物车系统。一个最简单的情况就是把所有货品的单价乘上数量，但是实际情况肯定比这要复杂。比如，本网站可能对所有的高级会员提供每本20%的促销折扣；对中级会员提供每本10%的促销折扣；对初级会员没有折扣。 　　根据描述，折扣是根据以下的几个算法中的一个进行的： 　　算法一：对初级会员没有折扣。 　　算法二：对中级会员提供10%的促销折扣。 　　算法三：对高级会员提供20%的促销折扣。 状态模式： 确定具体有几个状态，提取动态行为，不同状态有不同状态； 使用场景： 　考虑一个在线投票系统的应用，要实现控制同一个用户只能投一票，如果一个用户反复投票，而且投票次数超过5次，则判定为恶意刷票，要取消该用户投票的资格，当然同时也要取消他所投的票；如果一个用户的投票次数超过8次，将进入黑名单，禁止再登录和使用系统。 　　要使用状态模式实现，首先需要把投票过程的各种状态定义出来，根据以上描述大致分为四种状态：正常投票、反复投票、恶意刷票、进入黑名单。然后创建一个投票管理对象（相当于Context）。 状态模式与策略模式涉及到的角色： ●　　 环境

在 策略模式 中，一个类的行为或其算法可以在运行时更改。这种类型的设计模式属于行为型模式。简单理解就是一组算法，可以互换，再简单点策略就是封装算法。 一、类图 策略模式包含如下三个角色： 环境(Context)角色：持有一个Strategy的引用。 抽象策略(Strategy)角色：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。 具体策略(ConcreteStrategy)角色：包装了相关的算法或行为。 二、示例 假设某人在开车时频繁加速，因为超速他被一个警察拦下来了。有可能这个警察会比较友好，没开任何罚单就让他把车开走了。也有可能遇到了一个不太友好的警察，然后这个警察给他出具了一张罚单。但是并不知道会遇到什么类型的警察，直到他因为超速而被警察拦下停车，实际上这就是一种程序当中“运行时”的概念，只有在运行的时候才知道，到底会遇到什么类型的警察，实际上这就是“策略模式”。 策略接口： //先来定义一个策略的接口：Strategy public interface Strategy { public void processSpeeding(int speed); } 两种不同类型的Strategy: public class NicePolice implements Strategy { @Override public void

单例：线程池、任务管理器。 1.饿汉模式：类加载时就创建好单例对象，调用静态方法返回单例对象，不需要考虑多线程问题。 class Singleton{ 　　private static singleInstance = new Singleton(); 　　private Singleton(){} 　　public static Singleton getInstance(){ 　　　　return singleInstance; 　　} } 2.懒汉模式：在调用方法时再创建单例对象 class Singleton{ 　　private static volatile Singleton singleInstance = null; 　　private Singleton(){} 　　public static synchronized getInstance(){ 　　　　if(singleInstance==null){ 　　　　singleInstance = new Singleton(); 　　} 　　return singleInstance; 　　} } 简单工厂模式： public class LenovoComputer extends Computer{ @Override public void start() { System.out.println(

前言 最近段时间，接到一个需求：开发一个聚合支付服务，对其他内部项目提供统一的接口来实现不同支付平台的支付能力发起，比如支付宝，微信，银联等。为了处理相似的支付操作而各平台具体实现不同的情况，要让各个平台接口能力能相互独立，并要方便扩展后续新增的支付平台，我引入了设计模式的策略模式来应对需求场景，借此深入学习总结下策略模式，于是也就有了本文，希望对学习策略模式的同学有所帮助。 为什么需要策略模式 日常工作开发中我们总会遇到如下熟悉的代码片段： if(condition1){ // do something1 } else if (condition2){ // do something2 } else if (condition3){ // do something3 } 在每个 if 条件下都有数十行甚至百行的业务处理，各自处理又是相互独立的并且目的一致，都汇聚在一个方法里。这样的写法不但让类变得臃肿冗长，并且不同逻辑都在一个类中修改，维护和扩展起来都很费劲。那么又有什么办法可以优化这大段的代码呢，在实现功能的同时，让代码更加灵活和易维护。 要解决这个问题，本文的主角— 策略模式 就登场了，作为设计模式中比较简单的行为型模式，其实很多框架中都见到它的身影，稍后我们也会从各框架源码中识别策略模式的应用。使用策略模式可以帮助我们将每个处理逻辑封装成独立的类

策略模式Strategy 定义： 定义一系列的算法，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。策略模式的重心不是如何实现算法，而是如何组织、调用这些算法，从而让程序结构更灵活、可维护、可扩展。 策略算法对算法调度具有平等性，算法仅仅是一种性质相同而行为不同的处理，地位相同，可相互替换，算法之间没有依赖关系。 —抽象策略角色： 策略类，通常由一个接口或者抽象类实现。 —具体策略角色：包装了相关的算法和行为。 —环境角色：持有一个策略类的引用，最终给客户端调用。 策略模式UML图示 应用场景： 1、 多个类只区别在表现行为不同（性质一样，但行为不同） ，可以使用Strategy模式，在运行时动态选择具体要执行的行为。 2、 需要在不同情况下使用不同的策略(算法)，或者策略还可能在未来用其它方式来实现（动态）。 3、 对客户隐藏具体策略(算法)的实现细节（只公开一个功能，隐藏此功能实现的细节），彼此完全独立。 优点： 1、 提供了一种替代继承的方法 ，而且既保持了继承的优点(代码重用)还比继承更灵活(算法独立，可以任意扩展)。 2、 避免程序中使用多重条件转移语句，使系统更灵活，并易于扩展。 3、 遵守大部分GRASP原则和常用设计原则，高内聚、低偶合。 缺点： 1、 因为 每个具体策略类都会产生一个新类 ，所以会增加系统需要维护的类的数量。

防火墙管理工具 　　防火墙策略可以基于流量的源目地址、端口号、协议、应用等信息来定制，然后防火墙使用预先定制的策略规则监控出入的流量，若流量与某一条策略规则相匹配，则执行相应的处理，反之则丢弃。这样一来，就可以保证仅有合法的流量在企业内网和外部公网之间流动了。 　　在RHEL 7系统中，firewalld防火墙取代了iptables防火墙。iptables与firewalld都不是真正的防火墙，它们都只是用来定义防火墙策略的防火墙管理工具而已，或者说，它们只是一种服务。iptables服务会把配置好的防火墙策略交由内核层面的netfilter网络过滤器来处理，而firewalld服务则是把配置好的防火墙策略交由内核层面的nftables包过滤框架来处理。换句话说，当前在Linux系统中其实存在多个防火墙管理工具，旨在方便运维人员管理Linux系统中的防火墙策略，我们只需要配置妥当其中的一个就足够了。 iptables 　　在早期的Linux系统中，默认使用的是iptables防火墙管理服务来配置防火墙。尽管新型的firewalld防火墙管理服务已经被投入使用多年，但是大量的企业在生产环境中依然出于各种原因而继续使用iptables。 　　各个防火墙管理工具的配置思路是一致的，在掌握了iptables后再学习其他防火墙管理工具时，也有借鉴意义。 策略与规则链 　

策略模式，将一组特定的行为和算法封装成类，以适应某些特定的上下文环境。 eg：假如有一个电商网站系统，针对男性女性用户要各自跳转到不同的商品类目，并且所有的广告位展示不同的广告。在传统的代码中，都是在系统中加入各种if else的判断，硬编码的方式。如果有一天增加了一种用户，就需要改写代码。使用策略模式，如果新增加一种用户类型，只需要增加一种策略就可以。其他所有的地方只需要使用不同的策略就可以。 首先声明策略的接口文件，约定了策略的包含的行为。然后，定义各个具体的策略实现类。 UserStrategy.php <?php /* * 声明策略文件的接口，约定策略包含的行为。 */ interface UserStrategy { function showAd(); function showCategory(); } FemaleUser.php <?php require_once 'UserStrategy.php'; class FemaleUser implements UserStrategy { function showAd(){ echo "2016冬季女装"; } function showCategory(){ echo "女装"; } } MaleUser.php <?php require_once 'UserStrategy.php'; class

策略模式 策略模式的用意是针对一组算法， 将每一个算法封装到具有共同接口的独立类中 ，从而使得它们可以相互替换。策略模式使得算法可以在不影响到客户端的情况下发生变化。 策略模式的结构 策略模式是对算法的包装 ，是把使用算法的责任和算法本身分开。策略模式通常是把一系列的算法包装到一系列的策略类里面，作为一个抽象策略类的子类。 策略模式涉及到三个角色： 1、环境角色 持有一个策略Strategy的引用 2、抽象策略角色 这是一个抽象角色，通常由一个接口或抽象类实现，此角色给出所有具体策略类所需的接口 3、具体策略角色 包装了相关算法或行为 策略模式示例 有一个抽象的策略接口： public interface Strategy { public void useStrategy(); } 实现两种具体的策略： public class StrategyA implements Strategy { public void useStrategy() { System.out.println("StrategyA.useStrategy()"); } } public class StrategyB implements Strategy { public void useStrategy() { System.out.println("StrategyB.useStrategy()")