代码之家  ›  专栏  ›  技术社区  ›  Drew

接口、静态内部类和最佳实践

  •  0
  • Drew  · 技术社区  · 7 年前

    所以,这或多或少是一个编码风格的问题。我在这里使用Bean验证,但是对于任何具有不太可能经常更改的简单实现的接口,其思想都是一样的。

    @Target( { METHOD, FIELD, ANNOTATION_TYPE })
    @Retention(RUNTIME)
    @Constraint(validatedBy = PhoneNumber.PhoneNumberValidator.class)
    @Documented
    public @interface PhoneNumber {
        String message() default "Must Be A Valid Phone Number";
    
        Class<?>[] groups() default {};
    
        Class<? extends Payload>[] payload() default {};
    
    
    
        public class PhoneNumberValidator implements ConstraintValidator<PhoneNumber, String>{
    
            public void initialize(PhoneNumber arg0) {}
    
            public boolean isValid(String phoneNumberStr, ConstraintValidatorContext unused) {
                return phoneNumberStr.replaceAll("[^\\d|x]", "").matches("\\d{10,12}(x\\d+$)?");
            }
    
        }
    
    }
    

    因此,PhoneNumberValidator是这个特定验证器(或生产者方法或拦截器等)的实现,我们不太可能经常更改实现。

    这是一种通过将实现和接口放在附近来为代码提供内聚的好方法,还是一种紧密耦合两段不应该耦合的代码的代码味道?

    你参加过这样的项目吗?如果是这样的话,它是让事情变得更好还是更糟?如果不是,你会觉得这种做法令人困惑吗?

    1 回复  |  直到 16 年前
        1
  •  0
  •   Adam    16 年前

    我经常将samll实用程序类嵌套在使用它们的地方。我认为这比producer更直截了当,因为它在同一个文件中可用,并且通常涉及较少的函数调用。我的“意见”和做法与你的类似。