어댑터 패턴 및 종속성

Question

어댑터 클래스에 대해 조금 의심의 여지가 있습니다. 나는 어댑터 클래스의 목표가 무엇인지 압니다. 그리고 언제 사용해야합니다. 나의 의심은 계급 건설에 관한 것이다. 나는 몇몇 자습서를 확인했고 그들 모두는 "Adaptee"클래스를 내 "Adapter"에 대한 의존성으로 전달해야한다고 말한다. 예 :

Class SampleAdapter implements MyInterface 
{ 
    private AdapteeClass mInstance; 
    public SampleAdapter(AdapteeClass instance) 
    { 
     mInstance=instance; 
    } 
} 

이 예제는 위키 백과에서 복사됩니다. 보시다시피 AdapteeClass가 종속 객체로 객체에 전달됩니다. 그 이유는 무엇입니까? 객체의 인터페이스를 변경하는 경우 "새로운"인터페이스를 사용할 것이 분명하며 "오래된"인터페이스는 필요하지 않습니다. 왜 어댑터 외부에 "old"클래스의 인스턴스를 만들어야합니까? 누군가 내가 의존성 삽입을 사용해야 만 원하는대로 전달할 수 있다고 말할 수도 있지만, 이것은 어댑터입니다. 구체적인 클래스의 인터페이스를 변경해야합니다. 개인적으로 나는 코드 울부 짖음이 더 좋다고 생각한다.

Class SampleAdapter implements MyInterface 
{ 
    private AdapteeClass mInstance; 
    public SampleAdapter() 
    { 
     mInstance= new AdapteeClass(); 
    } 
} 

귀하의 의견은 무엇입니까?

Answer 1

커플 링을 줄이고 코드를 더 잘 테스트 할 수 있도록 복잡한 객체 (클래스가 Builder 또는 Factory 인 경우 제외)는 항상 새로운 연산자를 사용하지 않는 것이 좋습니다. 클래스 나 메소드 또는 값 객체와 같은 수업 객체는 클래스 메소드 내에서 구성 될 수 있습니다 (클래스 메소드의 목적 일 수 있습니다).

예를 들어 AdapteeClass가 Remote Proxy입니다. Unit Testing을 사용하기를 원한다면 단위 테스트에서 그것을 대체 할 방법이 없으므로 단위 테스트는 실제 프록시 클래스를 사용해야합니다.

첫 번째 방법을 사용하는 경우 단위 테스트를 실행할 때 생성자에 모의 또는 위조를 삽입하여 모든 코드 경로를 테스트 할 수 있습니다.

구글은 더 자세하게 설명하지만, 몇 가지 중요한 포인트가됩니다 guide on writing testable code 있습니다

은하지 검증 코드에 대한 징후를

생성자 또는 필드 선언에서
• 새 키워드
• 생성자 또는 필드 선언의 정적 메서드 호출
• 생성자의 필드 할당 이외의 것
완전히 생성자가 완료된 후 초기화되지 6,
• 개체 생성자에서
• 제어 (조건부 또는 반복 논리) 흐름을 (초기화 방법에 대한 조심)
• 코드 않는 복잡한 객체 그래프의 생성자 내부 구조보다는 공장 또는 빌더를 사용하여
• 추가 또는 하나 이상의 비 단순 생성자를 가질 수 초기화 블록

Answer 2

AdapteeClass을 사용. 이 경우 동일한 유연성을 갖기 위해 모든 사용자를 SampleAdapter 생성자에 복제해야합니다. 이미 생성 된 객체를 전달하는 것이 더 간단합니다.

Answer 3

어댑터 내부에 Adaptee를 만드는 것이 제한적이라고 생각합니다. 기존 인스턴스를 적용하려는 언젠가라면 어떨까요?

솔직히 말해서 가능한 한 둘 다 할 것입니다.

Class SampleAdapter implements MyInterface 
{ 

    private AdapteeClass mInstance; 

    public SampleAdapter() 
     : base (new AdapteeClass()) 
    { 
    } 

    public SampleAdapter(AdapteeClass instance) 
    { 
     mInstance=instance; 
    } 
}