0

したがって、これは多かれ少なかれコーディング スタイルの問題です。ここでは 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 はこの特定のバリデーター (またはプロデューサー メソッドまたはインターセプターなど) の実装であり、実装を頻繁に変更する可能性はあまりありません。

これは、実装とインターフェイスを近くに配置することでコードにまとまりを与える良い方法ですか、それとも、結合してはならない 2 つのコードを密結合しているコードのにおいですか?

このようなことを行うプロジェクトに参加したことがありますか? もしそうなら、それは物事を良くしましたか、それとも悪くしましたか? そうでない場合、この慣行は混乱を招くと思いますか?

コミュニティ Wiki は、意見を求めているためです。

4

1 に答える 1

0

私はしばしば、それらが使用されている場所にsamllユーティリティクラスをネストします。同じファイルで利用でき、関数呼び出しが少ないことが多いため、これはプロデューサーよりも簡単だと思います。私の「意見」と実践はあなたのものと似ています。

于 2010-01-14T00:46:22.637 に答える