데이터 전송 객체를위한 인터페이스를 만들어야합니까?

19

데이터 전송 개체에 대한 인터페이스를 만드는 것이 좋은 생각입니까? 객체가 일반적으로 변경 가능한 것으로 가정합니다.

내 예제는 Java로되어 있지만 유사한 개념을 가진 다른 언어에도 적용 할 수 있어야합니다.

interface DataTransferObject  {
    String getName();
    void setName(String name);
}

class RealDataTransferObject  implements DataTransferObject {

    String name;
    String getName() {
        return name;
    } 
    void setName(String name) {
        this.name = name;
    }
}

물론 이것은 단순화 된 예입니다. 실제로는 더 많은 필드가있을 수 있습니다.

java object-oriented-design

— 아르키메데스 트라 야노
소스

24

일반적인 대답은 아니 당신이 그것을위한 구체적이고 구체적인 이유를하지 않고 코드를 추가해서는 안됩니다, 이러한 인터페이스에 대한 일반적인 이유가 없기 때문이다.

즉, 때로는 합당한 이유가있을 수 있습니다. 그러나 내가 본 모든 경우에, 이러한 인터페이스는 부분적이었습니다. 여러 클래스가 공유하는 하나 또는 몇 개의 속성 만 포함하므로 공통 슈퍼 수퍼 클래스를주지 않고 polymporphically를 사용하고 싶었습니다. 일반적인 후보는 Id일종의 레지스트리에서 사용할 Name속성 또는 사용자에게 표시 할 속성입니다. 그러나 X가있는 모든 것을 처리하는 코드를 원하는 경우에 유용 할 수 있습니다- (필요한 경우에만 ) 메소드 XSource를 포함 하는 인터페이스를 작성하십시오 .getXsetX

그러나 모든 속성을 포함하는 모든 모델 클래스에 대한 별도의 인터페이스? 나는 그것을 할 좋은 이유를 상상할 수 없습니다. 나쁜 이유는 잘못 설계된 프레임 워크 일 것입니다. 내가 올바르게 기억한다면 엔티티 EJB가 그렇게했습니다. 고맙게도 그들은 너무 나빠서 많은 견인력을 얻지 못했고 EJB 3.0부터 더 이상 사용되지 않습니다.

참고 사항 : "가치 객체"라는 용어를 사용하여 사소한 게터 및 세터 만있는 Java Bean을 설명하지 마십시오 . 일반적으로 불변 인 아이디가없는 것으로서 값 객체 의보다 일반적인 정의와 충돌합니다 . 더 나은 용어는 DTO 또는 모델 클래스입니다. 후자의 경우 빈혈 도메인 모델 은 반 패턴으로 간주됩니다.

— 마이클 보그 워드
소스

3

PEA에서 Martin Fowler는 수십 년 동안 "매우 성공적으로"그런 방식으로 일한 사람들을 알고 있다는 사실을 인정하고있다. 따라서 나는 반 패턴이 적고 파울러가 아닌 일을하는 것이 좋습니다. 그럼에도 불구하고 좋은 대답은 +1입니다.

— pdr

4

@pdr : 파울러는이 용어를 만들어 냈을 수도 있지만, 반 패턴으로 생각하는 유일한 사람은 결코 아닙니다. 실제로 OO를 이해하는 사람은 도메인 모델에서 도메인 별 로직을 유지하는 것이 좋은 생각이라고 생각하지 않습니다.

— Michael Borgwardt 2013

용어 수정에 감사드립니다. DTO는 지난 밤에 제가 찾던 단어 였지만 제 인생을 기억할 수 없었습니다. 이름을 바꾸면 디자인이 더 현명 해졌습니다.

— Archimedes Trajano

@ pdr 나는 그것을 넣는 가장 좋은 방법은 OO 프로그래밍의 맥락에서 반 패턴이라는 것입니다. 완벽하게 괜찮은 다른 많은 패러다임이 있으며 OO 언어로 성공적으로 작업 할 수도 있습니다 (특히 객체 지향적이지는 않습니다).

— Daniel B

3

@MichaelBorgwardt : 본인은 혼자가 아닙니다. 그러나 동의하지 않는 사람들도 없습니다. "무기 도메인 모델은 안티 패턴으로 간주됩니다"라고 말한 적이 없다면 아무 말도하지 않았습니다. 솔직히 말해서, 당신의 모든 대답은 어쨌든 마지막 단락없이 더 좋을 것이라고 생각합니다. 전반부는 더 나은 논평을했을 것이다. 후반은이 질문에 아무 것도 제공하지 않습니다.

— pdr

2

인터페이스 만들기는 괜찮지 만 예제가 작동하는 방식은 아닙니다. 인터페이스에서 setter를 제거하면 정상입니다.

interface ValueObject {
  String getName();
};

데이터베이스에서 이름을 가져올 수있는 것과 같이 여러 가지 다른 구현이 가능합니다. Setter는 다른 인터페이스에 있어야합니다.

— tp1
소스

2

인터페이스는 인터페이스를 구현하는 클래스와 해당 클라이언트 간의 계약을 정의합니다. 이것들은 추상화 메카니즘으로 사용되어 클라이언트가 "특정 행동을 가진 것들"을 조작 할 수 있습니다.

따라서 "이 인터페이스를 만들어 사용해야합니까?"라는 질문에 대한 일반적인 대답은 무엇입니까? 예 : 고객과 의미 적으로 관련이있는 단일 개념을 연결할 수 있다면

예를 들어, Comparable 은 좋은 인터페이스입니다. 메소드 중 하나를 사용하여 항목을 비교할 수 있다고 설명하고 클라이언트로서 비슷한 객체를 처리하는 데 관심이 있습니다 (예 : 정렬). 반대로 CoolStuff 는 멋진 객체에 특정 동작이 없다는 것을 인정하면 좋은 인터페이스가 아닙니다 (사실, 멋진 객체를 다루는 소프트웨어가 beCool 방법).

귀하의 특별한 경우에는 인터페이스가 쓸모 없다고 생각합니다. 누가 언제 어떻게 사용합니까? 변경 가능한 각 값에 대한 인터페이스를 작성할 수 없습니다. 따라서 메서드 뒤에 관련성이 있고 흥미로운 속성이 무엇인지 스스로에게 물어보십시오.

원하는 메소드가 두 개의 메소드를 통해 액세스 가능한 모든 변경 가능한 값을 갖는 오브젝트를 처리하는 경우 Java Bean 개념과 클래스가 해당 규칙을 채택하도록 강제 할 수있는 방법을 살펴보십시오.

— mgoeminne
소스

2

Michael이 말했듯이, 특별한 필요가 없다면 인터페이스를 추가하지 마십시오.

테스트는 좋은 이유의 예입니다. 실제 공동 작업자를 호출 할 때 "값 개체"인 경우 실제 공동 작업자를 선호하지만 실제 단위 테스트 격리를 위해서는 테스트를 위해 가짜 개체를 만들어야 할 수 있습니다.이 경우 인터페이스가 매우 유용합니다.

— jhewlett
소스

1

연령대에 조롱 프레임 워크를 사용하기 위해 인터페이스가 필요하지 않았습니다.

— Michael Borgwardt

원숭이 패치를 옹호하는 것처럼 들립니다. 나는 C #에서 Moles와 함께 그 길을 갔다. 가능하면 공동 작업자를 전달하는 것이 좋습니다.

— jhewlett 2012

1

Mockito와 easyMock을 사용하는 두 가지 조롱 프레임 워크는 최종 클래스를 변경할 수없는 경우 모의 할 수 없습니다.

— Archimedes Trajano 2019

1

이 개체가 나중에 일종의 필드 유효성 검사를 받도록하려면 초기 단계에서 캡슐화해야합니다.

— Goodfella
소스

0

'값 객체의 인터페이스'는 접근자를 호출하는 데 사용되는 것입니다.

접근 자의 필요에 관한 다른 정책을 경험했습니다. 어떤 사람들은 가능한 한 많은 것을 옹호하고 다른 사람들은 작성할 코드의 양을 줄이는 것을 금지합니다.

접근 자 (또는 직접 값 사용)에 대한 일부 이론적 근거는 다음과 같습니다.

접근자는 나중에 값이 저장되는 방식을 변경할 수 있습니다
접근자는 소프트웨어를 디버깅 할 때 액세스 로그를 추가 할 수 있습니다 (단일 방법으로 로그 호출을 추가 할 때 모든 값 변경을 캡처 함)
접근자는 객체 프로그래밍에 더 적합하며 모든 변수는 메소드에 의해 캡슐화됩니다.
접근자는 코드 표현력을 줄입니다 (같은 결과를 위해 더 많은 SLOC)
접근자는 일부 CPU를 사용합니다

나는 개인적으로 접근 자의 수를 줄이고 나중에 setter (setName)가 단순한 애정 이상이 될 것으로 기대할 때 접근자를 사용하도록 옹호합니다.

— 마크-엠마누엘 쿠퍼 벤트 데 그라
소스

0

이런 종류의 가치 객체는 상당히 낮은 수준입니다. 나는 그것을 두 방향 중 하나로 추진할 것을 제안한다 : (1) 가치 객체를 불변, 즉 실제 가치처럼 만들 거나, (2) 가변성을 더 높은 수준의 도메인 지향 비즈니스 기능으로 높이십시오. 도메인 관련 기능 단위 측면에서 인터페이스.

— 에릭 아이 트
소스