【问题标题】:Design of inheritance for Validate interfacesValidate 接口的继承设计
【发布时间】:2010-09-15 23:28:06
【问题描述】:

我从来没有这么擅长设计,因为有很多不同的可能性,它们都有优点和缺点,我从不知道该选择哪一个。无论如何,这是我的问题,我需要许多不同的松散相关的类来进行验证。但是,其中一些类需要额外的信息来进行验证。我想要一个方法validate 可以用来验证一个对象,我想确定一个对象是否可以通过接口验证,比如Validatable。以下是我可以拥有的两个基本解决方案。

interface Validatable {
  public void validate() throws ValidateException;
}
interface Object1Validatable {
  public void validate(Object1Converse converse) throws ValidateException;
}
class Object1 implements Object1Validatable {
  ...
  public void validate() throws ValidateException {
    throw new UnsupportedOperationException();
  }
}
class Object2 implements Validatable {
  ...
  public void validate() throws ValidateException {
    ...
  }
}

这是第一个解决方案,我有一个通用的全局接口,可以验证的东西实现,我可以使用validate() 来验证,但 Object1 不支持这个,所以它有点失效,但 Object2 确实支持它,所以可能还有很多其他课程。

或者,我可以拥有以下内容,这将使我没有顶级界面。

interface Object1Validatable {
  public void validate(Object1Converse converse) throws ValidateException;
}
class Object1 implements Object1Validatable {
  ...
  public void validate(Object1Converse converse) throws ValidateException {
    ...
  }
}
interface Object2Validatable {
  public void validate() throws ValidateException;
}
class Object2 implements Object2Validatable {
  ...
  public void validate() throws ValidateException {
    ...
  }
}

我认为我遇到的主要问题是我有点坚持拥有顶级接口的想法,因此我至少可以说 X 或 Y 对象是可验证的。

【问题讨论】:

    标签: java inheritance interface


    【解决方案1】:

    “可以验证对象”问题的简单解决方案是添加第三个接口。

    这第三个接口是一个空接口,它是其他两个接口的父级,这意味着您可以只检查该接口(假设您不担心有人欺骗是可验证的),然后反复检查可能的验证接口如果您需要实际验证。

    例子:

    interface Validateable
    {
    }
    
    interface EmptyValidateable inherits Validateable //Or is it implements?
    {
         void validate() throws ValidateException;
    }
    
    interface Objectvalidateable inherits Validateable
    {
         void validate(Object validateObj);
    }
    

    【讨论】:

      【解决方案2】:

      这是在 C# 中,但同样的想法当然可以在许多其他语言中实现。

      public class MyClass {
          //Properties and methods here
      }
      
      public class MyClassValidator : IValidator<MyClass> {
          IList<IValidatorError> IValidator.Validate(MyClass obj) {
              //Perform some checks here
          }
      }
      
      //...
      
      public void RegisterValidators() {
          Validators.Add<MyClassValidator>();
      }
      
      //...
      
      public void PerformSomeLogic() {
          var myobj = new MyClass { };
          //Set some properties, call some methods, etc.
          var v = Validators.Get<MyClass>();
          if(v.GetErrors(myobj).Count() > 0)
              throw new Exception();
          SaveToDatabase(myobj);
      }
      

      【讨论】:

        【解决方案3】:

        也许apache commons validator 项目在这里会很有用 - 直接或作为如何解决您的问题的模型。它们实际上有一组并行的对象来执行验证 - 因此对象上没有接口,只是对象/类的相关验证器的存在/不存在。

        【讨论】:

        • 我猜这里的界面让他可以轻松筛选可验证和不可验证对象的混合列表...
        • 不幸的是,这不是我要在这里进行的验证类型,我会进一步研究它,它可能会很方便,谢谢。
        【解决方案4】:

        这个呢:

        interface Validatable {
          void validate(Validator v);
        }
        
        class Object1 implements Validatable{
          void validate(Validator v){
            v.foo
            v.bar
          }
        }
        class Object1Converse implements Validator{
         //....
        }
        class Object2 implements Validatable{
          void validate(Validator v){
            //do whatever you need and ingore validator ? 
          }
        }
        

        如果 Object2 收到不需要的参数,你关心什么?如果没有它也能正常运行,可以忽略它对吗?

        如果您担心在 object2 和 Object1Converse 之间引入不必要的依赖关系,那么只需指定一个接口来解耦它们并将其用作验证器。

        现在我必须补充一点,有一个混合模型,其中既有能够自我验证的对象,也有需要外部状态信息来验证的对象,这听起来很奇怪。

        想说明一下吗?

        【讨论】:

        • 如果我要这样做,那么我只需要 validate(Object o) 然后每个类都可以确定要传递给它的 Object 类型,但是没有类型检查和实际上,任何东西都可以传递给 validate 方法,这可能会导致问题。
        • 我不会使用 Object,因为它不会向未来的开发者传达任何信息,因此我将类型限制为验证器对象。我仍然认为尝试将通用接口应用于不同的行为(自我验证和外部验证)是有问题的。
        • 也许你是对的,也许这只是在类(或对象当前继承的接口)上放置一个方法。
        猜你喜欢
        • 2019-09-29
        • 2015-10-29
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2012-10-11
        • 1970-01-01
        • 2011-04-22
        • 1970-01-01
        相关资源
        最近更新 更多