枚举设计决策的常量特定方法

Question

这更多是一个设计问题。所以首先，我有一个枚举：

enum WageType {
    MONTHLY {
        public int getWageRatePerUnit() {
            return 60000;
        }

        public boolean isPaymentTime(DateTime date) {
            return date.getDayOfMonth() == 29;
        }
    },
    DAILY {
        public int getWageRatePerUnit() {
            return 2500;
        }

        public boolean isPaymentTime(DateTime date) {
            return date.getHourOfDay() == 20;
        }
    };

    public abstract int getWageRatePerUnit();
    public abstract boolean isPaymentTime(DateTime date);
}

现在我有 2 个抽象方法，以及枚举常量中的相应实现。实际场景中包含一些冗长的业务逻辑，我最终得到了 3 或 4 个这样的方法。

但我有一种感觉，我正在搞砸我的枚举。这是否被认为是糟糕的设计实践，将特定于不同枚举类型的业务逻辑放在常量特定的方法中？如果我宁愿实现一个接口，并在那里定义方法，并让所有枚举常量实现它们，这会有什么不同？当然，在那之后我将不得不在任何地方使用接口引用，但我必须看看它是否适用于休眠映射。目前，我将枚举常量作为实体的一部分使用@Enumerated(EnumType.String). 所以，我希望另一种方法不会对这部分产生太大影响，即 End 行为应该保持不变。

顺便说一句，我认为不需要接口，因为我不会有一组单独的枚举常量具有类似的行为。其他选项可能是某种实用程序类，以处理这些枚举常量。只需将方法传递给它正在处理的枚举类型。

你怎么说？我应该遵循哪种方法？如果您能想到，我愿意接受其他更好的选择吗？

Answer 1

关于让您的枚举实现接口与为每个枚举值扩展模板方法，我会坚持使用模板方法，因为正如您所说，不会有任何其他枚举或类实现这些方法。（如果您有许多需要履行合同的枚举或类，则实现接口是有意义的，但情况似乎并非如此）。

我个人认为枚举是具有一些约束的类（即它们是最终的且无状态的），但有人认为以这种方式使用枚举是很hacky的。我完全不同意，因为我认为使用语言提供的功能是绝对有效的，模板方法就是这样的功能之一。然而，很高兴知道这种方法在一些保守的环境中会产生阻力。

尽管如此，我确实认为在枚举中使用模板方法会使您的代码变得非常冗长。仅当模板方法的数量和枚举值的数量都很低并且如果允许它们将来不会改变时，我才会采用这种方法。

另一方面，您可以使用此代码而不是您的代码来实现完全相同的功能：

public enum WageType {
    MONTHLY(60000, 29), DAILY(2500, 20);

    private final int wageRatePerUnit;
    private final int hourOfDay;

    public WageType(int wageRatePerUnit, int hourOfDay) {
        this.wageRatePerUnit = wageRatePerUnit;
        this.hourOfDay = hourOfDay;
    }

    public int getWageRatePerUnit() {
        return this.wageRatePerUnit;
    }

    public boolean isPaymentTime(DateTime date) {
        return date.getHourOfDay() == this.hourOfDay;
    }
}

该代码比您的代码简单得多，并且提供完全相同的功能。但是，您将无法从数据库中检索枚举，因为 Hibernate 找不到它的默认构造函数。

现在，我相信使用可用的语言功能来找到解决方案是可以的，但使用它们是因为否则 Hibernate 将不知道如何实现您的枚举......好吧，这就是我所说的解决方法。

也许您可以创建WageType一个实体并让 Hibernate 像往常一样处理它，并将其关联到其他实体，然后在该实体的方法中或在实体外部的服务类中或在某些实用程序类中实现您的逻辑，无论您喜欢什么。请注意，这将导致额外的联接或选择（或者可能是子选择，呃），具体取决于实体WageType参与的每个关联的获取策略。