Интерфейсы, статические внутренние классы и лучшие практики - PullRequest
Новая
       20

Интерфейсы, статические внутренние классы и лучшие практики

0 голосов
/ 14 января 2010

Итак, это вопрос стиля кодирования более или менее. Я использую 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 является реализацией этого конкретного валидатора (или метода-производителя, или перехватчика и т. Д.), И маловероятно, что мы будем часто менять реализацию.

Это хороший способ обеспечить согласованность моего кода, поместив реализацию и интерфейсы рядом, или это запах кода, который тесно связывает два куска кода, которые не должны быть связаны?

Вы были в проектах, которые делали подобные вещи? Если так, то стало ли лучше или хуже? Если нет, сочтете ли вы эту практику запутывающей?

Сообщество Wiki'd, так как оно спрашивает мнения.

1 Ответ

0 голосов
/ 14 января 2010

Я часто вкладываю служебные классы samll там, где они используются. Я думаю, что это более прямолинейно, чем продюсер, потому что он доступен в том же файле и часто включает меньше вызовов функций. Мое "мнение" и практика были похожи на ваши.

...