接口、静态内部类和最佳实践
所以，这或多或少是一个编码风格的问题。我在这里使用 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 是这个特定验证器（或生产者方法或拦截器等）的实现，并且我们不太可能经常更改实现。
这是通过将实现和接口放在一起来为我的代码提供凝聚力的好方法，还是将两段不应该耦合的代码紧密耦合在一起的代码味道？
您参与过类似的项目吗？如果是这样，它会让事情变得更好还是更糟？如果没有，您会觉得这种做法令人困惑吗？
社区维基百科因为它在征求意见。
So, this is a question of coding style more or less. I'm using Bean Validation here but the idea is the same for any interface that has simple implementations that aren't likely to get changed all that often.
@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+$)?");
}
}
}
So, PhoneNumberValidator is the implementation of this particular validator (or producer method or interceptor, etc.) and there isn't much likelihood that we would change the implementation very often.
Is this a good way to provide cohesion to my code by putting the implementation and the interfaces close by or is this a code smell that is tightly coupling two pieces of code that shouldn't be coupled?
Have you been on projects that did things like this? If so, did it make things better or worse? If not, would you find this practice confusing?
Community Wiki'd since it's asking opinions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我经常会在使用它们的地方嵌套一些小实用程序类。我认为这比生产者更直接，因为它可以在同一文件中使用，并且通常涉及更少的函数调用。我的“意见”和做法与你的类似。
I will often nest samll utility classes where they are being used. I think this is more straight forward than a producer because it is available in the same file and often involves less function calls. My "opinion" and practice has been similar to yours.