接口，靜態內部類和最佳實踐

所以，這是一個或多或少的編碼風格問題。我在這裏使用了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是這個特定的驗證器（或生產方法或攔截器等）的實施，並沒有太多的可能性，我們將改變執行非常頻繁。

這是一種很好的方式，通過將實現和接口放在附近，或者這是一種代碼氣味，它緊密耦合不應該耦合的兩段代碼，從而爲我的代碼提供內聚性？

您是否參與過這樣的項目？如果是這樣，它會讓事情變得更好還是更糟？如果不是，你會發現這種做法混亂嗎？

社區維基因爲它提出了意見。

來源

2010-01-13 Drew

我會經常在他們正在使用的地方嵌套samll實用程序類。我認爲這比生產者更直接，因爲它在同一個文件中可用，並且通常涉及較少的函數調用。我的「意見」和做法與你的相似。

來源

2010-01-14 00:46:22 Adam

接口，靜態內部類和最佳實踐

回答

相關問題