Interfaces, classes internes statiques et les meilleures pratiques

Question

Alors, ceci est une question de style de codage plus ou moins. J'utilise Bean Validation ici, mais l'idée est la même pour toute interface qui a des implémentations simples qui ne sont pas susceptibles de se changer si souvent que ça.

@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+$)?");
        }

    }

}

Alors, PhoneNumberValidator est la mise en œuvre de ce validateur particulier (ou une méthode de production ou intercepteur, etc.) et il n'y a pas beaucoup de chances que nous changerions la mise en œuvre très souvent.

Est-ce une bonne façon de donner cohésion à mon code en mettant la mise en œuvre et les interfaces à proximité ou est-ce une odeur de code qui est le couplage bien deux morceaux de code qui ne devrait pas être accouplées?

Avez-vous été sur des projets qui ont fait des choses comme ça? Si oui, at-il fait mieux ou pire? Sinon, auriez-vous trouver cette pratique confusion?

Communauté Wiki'd car il est de demander des avis.

Answer 1

Je niche souvent des classes utilitaires samll où ils sont utilisés. Je pense que cela est plus direct qu'un producteur car il est disponible dans le même fichier et implique souvent moins d'appels de fonction. Mon « opinion » et la pratique a été semblable à la vôtre.