2010-12-02 3 views
2

저는 회사에서 진행된 다른 Java 프로젝트를 살펴 보았습니다.이 프로젝트에서 개발자는 거의 모든 도메인 엔티티 (수백 개가 존재)에 대한 인터페이스를 만들었습니다. 어떤 경우에는 추상화가 작동한다고 생각하지만 다른 경우에는 현재로서는 필요하지 않은 것처럼 보입니다.모든 Java 도메인 클래스가 인터페이스를 구현해야합니까?

인스턴스가 전달 될 때마다 인터페이스를 통해 항상 참조되고 액세스됩니다.

미래의 교정이 너무 길어 지나요? 아니면이 건전한 엔지니어링 관행인가?

+0

dup of http://stackoverflow.com/questions/152077/programming-against-interfaces-do-you-write-interfaces-for-all-your-domain-class? –

+0

내가 겪어 본 낯선 상황 : 서비스가 아닌 도메인 객체를위한 인터페이스. 이 코드를 추상화하여 내 코드에 삽입하는 완전한 PITA로 만들었습니다. 그리고 그들은 도메인 객체에 대해 각각 하나씩 구현했습니다. !?!?!?! –

답변

3

인터페이스는 구현하지 않고 필요한 동작을 지정합니다. 이것들을 사용하면 클라이언트에 영향을주지 않고 구현을 교환 할 수 있습니다. 이들은 aspect 지향 프로그래밍이나 프록시 생성과 같은 기술에 특히 유용 할 수 있습니다.

그러나 구현이 변경되지 않으면 인터페이스에 대한 정당성이 없습니다.

대부분의 모델 객체가 해당 범주에 속합니다. 구현상의 차이점이 없으면 인터페이스를 사용하지 마십시오.

인터페이스는 서비스 및 지속성 클래스에 매우 뛰어나지 만 인터페이스 모델을 추상화하는 데 익숙하지 않았습니다.

+0

지속성 클래스로 DAO를 의미합니까? – HDave

+0

네, 맞습니다. – duffymo

3

주로 인터페이스는 분명히 공통된 특징을 가진 이질적인 클래스를 통합하는 디자인 도구입니다.

그러나 인터페이스 테스트는 단위 테스트를 작성할 때 많은 도움이 될 수 있습니다. easymock 같은 도구는 인터페이스와 잘 작동합니다.

개인적으로 나는 도메인 객체가 얼마나 풍부한 지에 따라 서비스에 대한 인터페이스가 있지만 도메인 객체 일 필요는 없습니다. 예를 들어 파일 시스템을 많이 사용하거나 서비스/DAO 계층과 밀접한 관계가 있다면 인터페이스 테스트를 쉽게 할 수 있습니다. 단위 테스트가 쉬워집니다.

+0

사실이 말을 바꾸어 보겠습니다. 나는 피곤해서 테스트를 위해 인터페이스를 보는 것처럼 들린다. ... –

+1

도메인 객체가 아닌 서비스에 대한 +1 –

+0

@ martin-algesten 테스트는 IMHO가 다른 이들과 인터페이스가되는 좋은 이유이다. – stacker

1

나는 그들이 복잡함을 과시하고 싶다고 생각한다. 구현이 여러 개인 경우 또는 확장 점이 될 것임을 나타내는 경우에만 인터페이스가 있어야합니다.

+0

그들은 나중에 추가 구현이 제공되고 인터페이스가 생성되면 도메인 객체를 사용하는 서비스 메소드가 변경되어야한다고 주장합니다. – HDave

+1

그런 다음 물어보십시오, 왜 그들이 구현 변경으로 자주 인터페이스를 변경해야합니다 ;-) (그냥 내 경험) – stacker

0

아니요. 모든 도메인에 대해 인터페이스가 만들어진다고 말하면 요점은 무엇입니까? 인터페이스는 실제로 여러 클래스를 그룹화하고 공통적 인 동작을 나타내는 데 유용합니다.

추상화가 과대 평가되어 쉽게 과장 될 수 있습니다.

1

인터페이스를 사용하면 동일한 기능을 여러 개 독립적으로 구현할 수 있으므로 구현 세부 정보를 줄일 수 있습니다.

클래스를 직접 참조하는 경우 사용할 유혹을받을 수있는 구현의 공개 클래스가있을 수 있습니다. 인터페이스 만 사용하면 호출 코드가 허용되는 대상에 대해 호출하지 않는다는 것을 보증 할 수 있습니다.

인터페이스를 처리 할 때 모든 종류의 고급 트릭을 수행 할 수 있습니다. 디버깅을 추가해야합니다. 각 메서드에 대해 로깅을 수행 한 다음 래핑 된 인스턴스를 호출하는 래퍼를 작성합니다.

목록이 계속 켜져 있습니다. 인터페이스 코드. 귀하의 코드가 더 좋을 것입니다.

+1

"코드 인터페이스"는 당신이 인터페이스의 구현을 두 개 이상 가지고있는 경우에만 의미가 있습니다. 인터페이스와 구현간에 1 : 1 관계가있는 경우 실제로 의미가 없으며 단순히 유지 관리 오버 헤드가 증가합니다. –

+0

외부 코드에서 사용할 클래스를 생각하고있었습니다. 질문을 다시 읽은 후에도 구현에서 내부적으로 사용된다는 것을 알 수 있습니다. 나는 그것을 과도하게하는 것에 동의한다. 테스트가 필요할 때만 내부 코드에서 수행하십시오 (그렇습니까?) 또는 모의가 있습니다. 가능한 한 간단하게 유지하십시오. –

2

좋은 경험 법 : 추상화를 위해 추상화를 도입하지 마십시오. 프로젝트를 어떻게 든 가능케하는 경우에만 수행하십시오. 유닛 테스트가 쉬워 지거나 업그레이드가 더 쉬워 지거나 의존성 삽입 등이 가능하면 프로젝트를 더 복잡하게 만들지 마십시오.

도메인 객체의 경우 POJO 인 경우 인터페이스를 만들면 어떤 이점도 없습니다. 그들이 POJO가 아니라면 실제로 도메인 객체가 아닐지도 모른다고 주장 할 것입니다 ... 그러나 나는 그것이 다른 주장이라고 생각합니다.

관련 문제