모델 클래스에 인터페이스 구현 설계에 대한 내용

웹 프로그래밍에서 MVC패턴을 사용하는데
Model에 대해 인터페이스를 만드는 것이 과연.. 좋을까?
StackOverflow

The general answer is no, because you should never add code without having a specific, concrete reason for it, and there is no general reason for such an interface.
일반적인 대답은 "노"다. 모델에 인터페이스를 구현하는 것은 명확한 이유없이 코드를 추가하면 안되기 때문이다. 그리고 인터페이스 대한 일반적인 이유가 아니다.

That being said, sometimes there can be a good reason. 
그렇긴해도, 때때로 좋은 사유가 있으면 가능하다.

But in all cases I have seen, these interfaces were partial, covering only one or a few properties shared by multiple classes I wanted to use polymporphically without giving them a common superclass. 
하지만 내가 본 대부분의 경우, 인터페이스 일부분과 커버링이 다수의 클래스에 의해 하나 혹은 소수의 프로퍼티를 공유한다면 나는 공통 부모 클래스 없이 가지각색의 형태로 사용하기 원합니다.

Typical candidates are an Id property to use in some sort of registry or a Name property to display to the user. But it can be useful in any case where you want some code to handle everything that has an X - just create an XSource interface that contains the getX (and, only if required, the setX) methods.
보통 후보자들은 id 프로퍼티를 사용하고 등록된거나 프로퍼티 이름의 종류를 사용자에게 보여줍니다. 하지만 너가 원하는 모든 것을 핸들링하기 위한 몇몇 코드에서 유용하게 사용할 수 있고 단지 XSource 인터페이스를 만들어 getX 메서드들을 포함하면 된다.(그리고 필요하다면 setX도)

But a separate interface for every model class, containing all the properties? I can't imagine a good reason to do that. A bad reason would be a badly designed framework that requires it; Entity EJBs did just that, if I remember correctly. Thankfully they were so bad they never gained much traction and are deprecated since EJB 3.0
하지만 모든 모델 클래스를 위한 각각의 인터페이스가 전체 프로퍼티를 포함해야할까요? 저는 그건 좋은 생각이라고 들지 않습니다. 안 좋은 이유는 잘못된 디자인이 된 프레임워크가 됩니다. 내 기억이 맞다면.. 엔터티 EJBs가 그렇다. 다행스럽게도 그들은 많은 노력으로 더 나빠지게 하지 않았고 EJB 3.0에서는 Deprecated되었습니다.

Sidenote: please avoid using the term "value object" to describe Java beans with only trivial getters and setters - it conflicts with the more common definition of value object as something with no identity that is usually immutable. 
단지 getter, setter만 있는 Java beans를 말할 때 VO객체라는 단어 사용을 지양해주세요. 
- 그 용어는 충돌이 납니다. 더 공통으로 정의한 VO 객체는 특색 없고 Value Object는 불변 객체로 사용합니다.

A better term would be DTO or model class - though in the latter case note that anemic domain models are considered an antipattern.
DTO 혹은 모델 클래스라는 용어가 더 좋습니다.  적은 케이스에서 소수의 도메인 모델에서 안티 패턴으로 고려되었습니다.

- 발 번역, 오역이 있을 수 있습니다. 그냥.. 참고로만 읽어주세요 ㅠㅠ
참조
- http://programmers.stackexchange.com/questions/185636/should-i-create-interfaces-for-data-transfer-objects 개인적인 의견
- 그래도 나는 아직 동의를 못하겠다.
- 전체 모델에 대한 프로퍼티(멤버)를 가지고 인터페이스를 만들지 않는 것은 맞다고 판단이 되지만 ...
일부분의 멤버는 인터페이스로 만들어 활용할 수 있다고 생각이 듭니다.