Question

所以，这或多或少都是编码风格的问题。我在这里使用的是Bean Validation，但对于任何具有简单实现的接口来说，这个想法是相同的，这些接口不太可能经常被改变。

@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是这个特定验证器（或生产者方法或拦截器等）的实现，并且我们很可能不经常更改实现。

这是通过将实现和接口放在附近来为我的代码提供内聚的好方法吗？或者这是一种代码气味，它紧密耦合了两段不应该耦合的代码？

您是否曾参与过这样的项目？如果是这样，它会使事情变得更好还是更糟？如果没有，你会发现这种做法令人困惑吗？

社区维基，因为它在征求意见。

Answer 1

我经常将samll实用程序类嵌套在使用它们的位置。我认为这比生产者更直接，因为它在同一个文件中可用，并且通常涉及较少的函数调用。我的“意见”和做法与你的相似。

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

1 个答案: