Java 基于输入的不同验证器

我正处于项目的设计阶段，需要对给定对象执行某些验证。 验证可分为5个不同的组。每个单独的验证器类别都可以有多个版本，它们的实现略有不同

public interface Validator {
 boolean validate(Object o);
}

public abstract CostValidator implements Validator {
 //common logic related to cost validator
}

public class CostValidator1 extends CostValidator {
 boolean validate(Object o) {
   //implementation 1
 }

public class CostValidator2 extends CostValidator {
 boolean validator(Object o) {
  //implementation 2
 }

根据对象的业务组，需要执行CostValidator1或CostValidator2

对于每个业务组，我计划在配置系统中维护此类验证器的列表，即：

BusinessGroupA {
validators = [CostValidator1, SomeOtherValidator2...]
}

BusinessGroupB {
validators = [CostValidator2, AnotherValidator99...]
}

处理流将根据业务组从配置中获取验证程序列表，并在因此包含的每个验证程序中执行验证

这种方法有什么缺陷吗？

---

或者有没有更好的方法来解决我描述的用例？

我建议对上述解决方案添加两个改进：

1。保证存在所需的验证规则

假设每个业务组都应该执行相关的验证，那么应该有某种机制来保证配置指定足够的验证规则，即验证类。如果您有数十个属性，可能有数百个业务组，那么很容易在配置中出错，即不指定任何验证器以降低成本。我的建议是在业务对象级别指定哪些属性需要有验证器。然后创建某种对象工厂，根据业务组和验证需求将验证器绑定到对象

我会采用这个方法：

为每种类型的验证创建一个接口，例如ICostValidator和IWeightValidator

在您的配置中，保留业务对象所需的验证程序接口列表，例如：

RequiredValidator=[ICostValidator，IWeightValidator]

在BusinessGroupA或BusinessGroupB上执行验证时，请始终检查配置的验证程序是否实现了所有RequiredInterface

2。将验证器与特定业务对象分离

如果您现在查看成本和权重验证，它们将绑定到业务对象。我不知道类图的其余部分，但我可以想象成本和权重的属性将出现在多个业务对象中，例如Item、QuotationLine、SalesOrderLine、，ShippingLine等。那么最好使用不直接依赖于业务对象并且可以轻松应用于多个业务对象的验证器。在对象工厂中，您还可以处理验证器和底层对象之间的正确绑定

---

如果您需要一些代码示例，请告诉我。

我想知道，根据需求，是否有更好的设计方法。由于我的项目处于设计阶段，我想探索尽可能多的备选方案。是否有任何特定的原因将验证逻辑放在单独的类中？为什么对象不能验证自己<代码>如果（！object1.isValid（））{…}基于对象所属的业务组，则应用CostValidator1或CostValidator2或不应用成本验证。类似地，属于A组的对象在管道中可能有3个验证器，而属于B组的对象有5个。此外，还可以根据将来需要的更改将对象从一个业务组移动到另一个业务组。这个对象将由不同的组件作用，实现它们自己的业务逻辑。这里列出的验证器属于这样一个逻辑分组。此外，对象类的代码库遵循UML图中一种功能性更强的方法——所有的箭头都指向错误的方向。类应该指向它实现的接口或它扩展的类。你说得对。我刚刚为这个问题画了一个快速的一次性图表。谢谢你的回答！1.这是一个非常有效的观点，我也在考虑建立一些机制，以确保某些验证器不会意外丢失。我会把这个因素考虑到我的设计中。2.你说得对。虽然，我现在没有看到这些验证器在多个业务对象上运行的用例，但是人们永远无法确定将来可能需要做哪些更改。能否提供更多关于实现您在回答中提到的第一点的细节？