应用泛型的策略模式

最新推荐文章于 2025-05-07 09:59:31 发布
原创 最新推荐文章于 2025-05-07 09:59:31 发布 · 595 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#class #编译器 #interface #java #generics #单元测试

应用泛型的策略模式
作者：Dr. Heinz M. Kabutz
 
 
 
摘要
策略模式相当的简单。通过使用这个模式，我们可以把一些内聚的状态转化为一些外在的状态，这样可以实现共享策略对象。当每一个策略对象为了实现它的功能而需要不同批次的信息的时候，策略模式将变得相当的灵活。在这篇文章里，我们将看到我们如何使用Java5的泛型把正确的上下文子类型传递到每一个策略对象中。
 
欢迎来到1、2、3版的《Java(TM)专家实事通讯》，在这里你将看到，当我们把策略模式和泛型结合到一起的时候，会发生一些什么事情。这篇文章写起来相当的困难，并且时间也很紧。我非常感谢下面的这些人，他们提供了有价值的参考：Angelika Langer, Philip Wadler, Maurice Naftalin 和 Kirk Pepperdine.
在我们开始详细分析这个模式之前，我需要增加一个提示：你可以使用一些比我在这里提供的例子更加复杂的示例作为策略模式的例子。这是解决这个特殊问题的另外一种方法。你可以按照我在这篇文章里所展示的步骤把策略模式介绍到你的现有代码中去。
我的目标如下：
。把行为移出一个大类
。设计算法来计算税收
。使得外在的状态对象最少
这能够帮助我，使得我可以通过继承而不必修改现有代码来获得代码。
 
 
使用泛型的策略模式
我们以一个简单的例子开始，这个例子是通过不同的纳税人来计算税费。纳税人的类型由类内部的一个int型的变量来定义，我们正是使用它来计算纳税人该缴多少税的。 
public class TaxPayer {
 public static final int COMPANY = 0;
 public static final int EMPLOYEE = 1;
 public static final int TRUST = 2;
 private static final double COMPANY_RATE = 0.30;
 private static final double EMPLOYEE_RATE = 0.45;
 private static final double TRUST_RATE = 0.35;
 
 private double income;
 private final int type;
 public TaxPayer(int type, double income) {
    this.type = type;
    this.income = income;
 }
 public double getIncome() {
    return income;
 }
 public double extortCash() {
    switch (type) {
      case COMPANY: return income * COMPANY_RATE;
      case EMPLOYEE: return income * EMPLOYEE_RATE;
      case TRUST:    return income * TRUST_RATE;
      default:       throw new IllegalArgumentException();
    }
 }
}
 
下面是这个大类的类图：
 
上面的类被ReceiverOfRevenue类所使用，如下： 
public class ReceiverOfRevenue {
 public static void main(String[] args) {
    TaxPayer heinz = new TaxPayer(TaxPayer.EMPLOYEE, 50000);
    TaxPayer maxsol = new TaxPayer(TaxPayer.COMPANY, 100000);
    TaxPayer family = new TaxPayer(TaxPayer.TRUST, 30000);
    System.out.println(heinz.extortCash());
    System.out.println(maxsol.extortCash());
    System.out.println(family.extortCash());
 }
}
 
最初的TaxPlayer类的计算相当的简单。然而，无论什么时候计算发生变化的话，你将不得不修改最初的那个类。还有，如果你有好几个 switch语句的话，当你引入一种新的纳税类型的话，你将不得不更新每一个switch语句。一旦我使用这种方法写了一个case公举的话，当我增加一个新的结构，我将不得不更改五种不同的switch语句来适应这种改变。如果我忘记输入switch语句的话，那么新的结构也将没有得到输入。
一种更好的方法用来避免使用switch或者多条件的if…else …if…是使用策略模式。它允许我们为每一个纳税人类型的税费计算创建一个独立的类。我们可以很容易的新增不同的税费类型。另外，一个更小的类意味着你的单元测试可以更加专注某一个特别的方面。
为了将原始的switch语句转化为策略对象，我们首先定义一个TaxStrategy接口： 
public interface TaxStrategy {
 public double extortCash(double income);
}
接着我们将为每一个计算提供一个独立的策略实现（像前面所提到的，现在这些实现看起来相当的简单，后面它们将变得比较复杂）： 
public class CompanyTaxStrategy implements TaxStrategy {
 private static final double RATE = 0.30;
 public double extortCash(double income) {
    return income * RATE ;
 }
}
 
public class EmployeeTaxStrategy implements TaxStrategy {
 private static final double RATE = 0.45;
 public double extortCash(double income) {
    return income * RATE;
 }
}
 
public class TrustTaxStrategy implements TaxStrategy {
 private static final double RATE = 0.40;
 public double extortCash(double income) {
    return income * RATE;
 }
}
现在TaxPayer类实用TaxStrategy对象来代替int类型的纳税人类型，我们使用多态代替多条件语句，如下： 
public class TaxPayer {
 public static final TaxStrategy EMPLOYEE =
    new EmployeeTaxStrategy();
 public static final TaxStrategy COMPANY =
    new CompanyTaxStrategy();
 public static final TaxStrategy TRUST =
    new TrustTaxStrategy();
 
 private final TaxStrategy strategy;
 private final double income;
 
 public TaxPayer(TaxStrategy strategy, double income) {
    this.strategy = strategy;
    this.income = income;
 }
 
 public double getIncome() {
    return income;
 }
 
 public double extortCash() {
    return strategy.extortCash(income);
 }
}
因为我们在TaxPayer类的内部定义了纳税人类型为常量，我们可以保持ReceiverOfRevenue类的正确性。
使用图例来演示这个解决方案，类图如下：
 
这个解决方案里面有一个问题。策略类的extortCash方法只有TaxPayer类的income一个输入参数。如果对于一个特定的TaxPayer，需要有多个因素来计算税费，那将怎么办呢？例如，当我结婚以后，南非的税法有一个可笑的条款是，结了婚的妇女比未结婚的妇女要交纳更多的税费。（为了演示这个税收的原因，我变成了妻子。即使我只是个学生，我妻子才是养家活口的人 J）
对于这个问题，有好几种解决方案。一种是将TaxStrategy的实例和一个TaxPayer对象相关联。这意味着状态是内在的，而我们将不能够共享TaxStrategy的实例。
另一种方法是，把所有的变量都传递到extortCash方法中。然而，这个方案又不是可维护的，因为当一个新的税费类型被定义时，你必须每一次更改该方法。你的政府可能会为小公司提供特种营业税分配。
还有一个方法是，传递TaxPayer 到extortCash（）方法里去。如果你有一个Employee类是TaxPayer的子类，EmployeeTaxStrategy将需要强制类型转换成Employee的实例，去看一看它是不是一个已婚的。
TaxStrategy接口需要做如下修改： 
public interface TaxStrategy {
 public double extortCash(TaxPayer p);
}
TaxPayer类里面的extortCash（）方法需要做如下的修改： 
public class TaxPayer {
 // the rest of the class is the same
 public double extortCash() {
    return strategy.extortCash(this);
 }
}
 
让我们实现那个特别的例子——已婚的妇女需要交纳更多的税费。我们不希望TaxPayer类包含税费的详细信息，因为它只需要关注employees的信息。和其他的类相比较，重点是计算机算税费。相信没有得益的话，定价是零。 
public class Employee extends TaxPayer {
 public enum Gender { MALE, FEMALE };
 private final boolean married;
 private final Gender gender;
 
 public Employee(TaxStrategy strategy, double income,
        boolean married, Gender gender) {
    super(strategy, income);
    this.married = married;
    this.gender = gender;
 }
 
 public boolean isMarried() {
    return married;
 }
 
 public Gender getGender() {
    return gender;
 }
}
EmployeeTaxStrategy类需要找出一个特定的TaxPayer是不是一个已婚的妇女。为了达到这个目的，它需要强制类型转化为Employee。而转化错误只能在运行期内显示出来。我们需要在转化前 instanceof检测它是否为Employee的实例。但是如果不是的话，我们会做什么呢？ 
public class EmployeeTaxStrategy implements TaxStrategy {
 private static final double NORMAL_RATE = 0.40;
 private static final double MARRIED_FEMALE_RATE = 0.48;
 
 public double extortCash(TaxPayer p) {
    Employee e = (Employee) p; // here we need to downcast!!!
    if (e.isMarried() &&
        e.getGender() == Employee.Gender.FEMALE) {
      return e.getIncome() * MARRIED_FEMALE_RATE;
    }
    return e.getIncome() * NORMAL_RATE;
 }
}
类图如下：
 
这个方法可以操作，但是还不是令人满意的。让我们看看其他的办法。
 
使用泛型避免强制类型转换
泛型是用来解决强制类型转换的，不错。但不幸的是，泛型也使得代码难以被阅读。如果你还在和“ ”这样符号斗争，那么你会发现我们的 Java 5 Delta Course课程是有用的，在这个课程的第三章，我们特别讲到了泛型。
我试着加入泛型，但是它比我想象的还要复杂。经过一段时间的尝试，我开始向Philip Wadler、Maurice Naftalin和Angelika Langer寻求帮助，他们都是Java的支持者，精彩的 Java Generics FAQ的作者。我们一起做出了如下的解决方法。
我们以对TaxStrategy的泛型开始，它被限制在TaxPayer和它的子类范围内。 
public interface TaxStrategy
extends TaxPayer> {
 public double extortCash(P p);
}
 
我们接着来写被限制在Company范围的CompanyTaxStrategy类。换句话说，参数P是一个Company范围。在这个国家，一个小公司交纳更少的税费，这样的小公司被定义为收入小于一百万美元但是雇员超过5个。 
public class CompanyTaxStrategy implements TaxStrategy
   
     {
   
 private static final double BIG_COMPANY_RATE = 0.30;
 private static final double SMALL_COMPANY_RATE = 0.15;
 
 public double extortCash(Company company) {
    if (company.getNumberOfEmployees() > 5
        && company.getIncome() < 1000000) {
      return company.getIncome() * SMALL_COMPANY_RATE;
    }
    return company.getIncome() * BIG_COMPANY_RATE;
 }
}
 
我们不得不修改了TaxPayer类，使得它包含一个泛型参数P，这个参数是TaxPayer的一个子类。表达式： class TaxPayer

extends TaxPayer

>看起来有点古怪，并且好像是一个习惯用法。它和让Ken Arnold困惑的Enum extends Enum > 相类似。经过考虑，我认为Enum extends Enum > 有充分的理由。然而，就像Philip Wadler指出的那样，既然Enum是一个泛型类，我们应该仅仅使用它来关联一个类型，（而不是一个泛型类）。将来，Java将会变得更加严格，那些夹生的类型将变得非法。因而我们必须选择是写Enum extends Enum > 还是 extends Enum > ，它们中间第一个选择要正确些。即使编译器现在还不能显示它们之间的差别，不久的将来，可能会看到警告信息，所以我在我的代码中遵从了上面的结论。

在TaxPayer中，我想在extortCash（）方法中直接使用类P的实现。然而，唯一取得一个实例而且没有编译器警告的方法是传递一个子类。我们可以通过一个叫 getDetailedType（）的工厂方法返回子类来解决这个问题。 
public abstract class TaxPayer
extends TaxPayer
> {
 public static final TaxStrategy
   
     EMPLOYEE =
   
    new EmployeeTaxStrategy();
 public static final TaxStrategy
   
     COMPANY =
   
    new CompanyTaxStrategy();
 public static final TaxStrategy
   
     TRUST =
   
    new TrustTaxStrategy();
 
 private double income;
 private TaxStrategy
 strategy;
 
 public TaxPayer(TaxStrategy
 strategy, double income) {
    this.strategy = strategy;
    this.income = income;
 }
 
 protected abstract P getDetailedType();
 
 public double getIncome() {
    return income;
 }
 
 public double extortCash() {
    return strategy.extortCash(getDetailedType());
 }
}
 
当我们在写Employee类的时候，我们必须指出，Employees类只能创建一个TaxStrategy，任何的其他的TaxStrategy都会让编译器警告。 
public class Employee extends TaxPayer
   
     {
   
 public enum Gender { MALE, FEMALE };
 private final boolean married;
 private final Gender gender;
 public Employee(TaxStrategy
   
     strategy, 
    double income,
   
                  boolean married, Gender gender) {
    super(strategy, income);
    this.married = married;
    this.gender = gender;
 }
 
 protected Employee getDetailedType() {
    return this;
 }
 
 public boolean isMarried() {
    return married;
 }
 
 public Gender getGender() {
    return gender;
 }
}
 
在这里，使用泛型的美妙之处是EmployeeTaxStrategy再也不需要强制类型转化。它通过泛型类紧紧地限制了Employees。 
public class EmployeeTaxStrategy implements TaxStrategy
   
     {
   
 private static final double NORMAL_RATE = 0.40;
 private static final double MARRIED_FEMALE_RATE = 0.48;
 
 public double extortCash(Employee e) {
    if (e.isMarried() &&
        e.getGender() == Employee.Gender.FEMALE) {
      return e.getIncome() * MARRIED_FEMALE_RATE;
    }
    return e.getIncome() * NORMAL_RATE;
 }
}
 
 
你可以为employees使用不同的策略，但是EmployeeTaxStrategy只能仅仅使用在employees上面，这是通过编译器强迫的。
 
亲切的问候，
Heinz



itkbase
关注
设计模式-使用策略模式+泛型 改造消息通知中心（一）
q809137492的博客
03-26 2106
前段时间负责一个智能化采购平台集成微信二次开发，其中涉及到微信模板消息的发送。当时系统中已经存在一个通知中心的服务，涉及站内信、阿里云短信、邮箱等消息发送，当然还要消息模板的维护。既然都是消息发送，那肯定就是将这个功能和之前的消息发送类型放到一起。于是开始调试功能，找到当时消息发送的远程接口，阅读上一任同事的代码。看完后，可以说几乎是惨不忍睹。不知道是那么copy过来的代码，没用的片段都没删掉。一个方法几百行。无论是扩展性，还是代码的可读性都非常糟糕。刚好当时时间比较充足，于是决定对主体结构进行重构，至于细
策略模式在业务中的实际应用
s178435865的专栏
04-24 1234
策略模式在业务中的实际应用
泛型策略模式的介绍和使用！
2401_87704405的博客
10-14 1126
之前设计过一个高扩展的系统，其中主要用的设计模式思想是：泛型策略模式+泛型模版模式。这篇文章先介绍一下泛型策略模式的使用！使用泛型定义策略模式可以提高代码的复用性、灵活性和可维护性。在实际应用中，结合其他设计模式可以实现更复杂的功能。但在使用泛型策略模式时，也要注意其局限性，避免过度设计导致代码复杂度增加。
Lambda表达式+策略模式+泛型
weixin_44906271的博客
04-26 1142
目录引出问题抛出问题一：方式一：抛出问题二：方式二：抛出问题三：方式三：方式四：Lambda表达式语法Lambda只能用在函数式接口JAVA中四个内置函数式接口 引出问题 创建了一个List集合，通过对这个集合的操作，抛出问题，并且利用Lambda表达式解决问题。 public class Test { public static void main(String[] args) { ...
Spring+策略模式+反射+泛型=无策略模式？
z28126308的专栏
11-27 1256
为什么要用策略模式？何时用策略模式？ 策略模式根据教科书式中的介绍为定义一系列算法，把它们一个个封装起来，并且使它们之间可互相替换，从而让算法可以独立于使用它的用户而变化。 在实际业务开发中，算法一般表现为一系列特定的业务操作，根据特定的业务策略执行相应的“算法”。一般在以下场景可以考虑使用策略模式： 选择语句(如if/else、switch)的多，选择执行块中操作各不相同且之后可能会进行业务扩展 避免选择语句导致的难以维护 想提高代码逼格 自定义式的策略模式演变 策略模式1.0 - 教材式的使用过程
现代C++设计：泛型编程与设计模式的应用
最新发布
08-21
书中不仅介绍了智能指针、对象工厂、单例模式等经典设计模式的具体实现，还展示了如何通过策略模式、类型列表、小型对象分配器等高级技巧提升代码的质量和性能。此外，书中提供的Loki模板库源码，为读者提供了一个...
Java策略模式实例解析与泛型应用
泛型策略模式允许我们定义一个泛型接口或类，然后由具体策略类去实现它们，这样就可以用一个统一的调用接口处理不同类型的数据。 ### 策略模式的简单例子分析 在提供的例子中，我们可以假设存在一个Context类，它...
关于.NET Framework中的设计模式–应用策略模式为List排序
01-02
编程时遇到排序在平常不过，使用.Net最常见的就是对泛型List进行排序，如果T是简单数据类型排序那么很简单 代码如下:public List<int> SortSimpleList(List<int> list){list.Sort();return list;} 同样对string等...
java设计模式之strategy(策略模式)和policy模式(泛化的strategy模式)
natee的专栏
09-23 1605
strategy模式 定义：运行时刻选择算法 表面上看起来，state模式和strategy模式是非常相似的，但既然他们分成两种不同的模式，就有一定的区别，用一句话来概括就是：策略用来处理算法方式变化，而状态则是处理状态变化。具体可以参考：http://blog.youkuaiyun.com/lwzcjd/archive/2009/05/19/420
Java设计模式之策略模式
10-29
Java设计模式之策略模式的详细描述
策略模式代码
05-13
策略模式代码 java 策略模式 排序 泛型
策略模式 strategy
jiangnet的博客
06-24 130
策略模式：定义算法族，分别封装起来，让他们可以互相替换，从而使算法的变化独立与算法的使用者。类图：       比如说有一个类，需要用到排序，而排序方式自然是多种多样的，显然在这个类中直接用一个方法进行排序是不太好的做法，因为它不能做到在不同情况下使用不同的算法排序。我们怎样应对这中不同的需求呢。我们可以把不同的排序方法封装到不同的类（排序类）中，这些类实现一个共同的接口（排序接口）。  "使用排...
Java 设计模式之策略模式
点滴记录
01-16 819
(一)了解策略模式 1.1什么是策略模式 策略模式(Strategy Pattern)是指对一系列的算法定义，并将每一个算法封装起来，而且使它们还可以相互替换。此模式让算法的变化独立于使用算法的客户。 1.2策略模式组成结构 环境(Context)：持有一个策略类的引用，最终给客户端调用。 抽象策略(Strategy)： 策略类，通常是一个接口或者抽象类。 具体策略(ConcreteSt
设计模式初探-策略模式
Java Dynamic的专栏
02-15 1666
策略模式(STRATEGY)，别名政策(Policy)，通过将一系列的算法封装成一个个的策略对象，使算法可以相互替换，并能独立于使用它们的客户而变化，属于对象行为型模式。软件开发过程中，通常要设计相应的算法，比如电子网站中经常有折扣活动，并且用户等级不同，享受的折扣也不一样。通过使用策略模式将折扣算法封装起来，不仅可以用于网商平台，还可以用于手持设备中折扣活动的实现。封装的特性确保了扩展算法和增加
Java设计模式泛型化之策略模式
道
01-10 3048
对于策略模式的理解是这样的： 做同一类型的事情，有不同的做法，这依赖于不同的上下文环境。但是有一个统一的模式。 就好像某网站对不同等级的用户有不同的折扣一样。 下面是代码结构： 策略接口 public interface Strategy { public void doSomething(); } 不同策略的不同实现 public class StrategyA imple
策略模式
hackerHL的博客
02-21 980
多态的最重要特性就是支持可扩展性。比如，排序算法，多种不同数据类型的值想要排序，通过同一个方法名的方法来排序，可以通过方法重载实现。 问题：如果要对某些对象进行排序比较，而不是基本数据类型，怎么样排序？Cat类package Strategy; public class Cat { private int age; private String name; public C
Java23种设计模式之第二弹-策略模式
weixin_44735933的博客
06-18 871
设计模式
泛型设计模式实践
qq_40453972的博客
05-07 1038
通过将泛型与设计模式结合，可以创建出既灵活又类型安全的代码结构，显著提升代码的可维护性和可扩展性。每种模式都通过泛型增强了其适用场景，使代码更加通用而不失类型安全. 在实际项目中，应根据场景选择合适模式，避免过度泛型化导致代码复杂度上升。结合Optional<T>、Stream API等特性，可进一步构建灵活且健壮的Java应用。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值