팩토리 디자인이 아닌 다른 객체를 생성하는 객체가 깨끗한가요?

Question

ZipFile 클래스와 Content 클래스라고 해봅시다.
ZipFile에는 zip 아카이브의 모든 파일 내용을 읽고이를 Content 객체에 넣는 load() 메서드가 있습니다.
가장 적합한 OOP 디자인은 무엇입니까?

이

1) ZipFile.load은()) 콘텐츠 객체

class ZipFile 
{ 
    public function load() 
    { 
     // Load all files in zip 
     // ... 
     Content content = new Content(); 
     content->set(data); 
     return(content); 
    } 
} 
ZipFile zf = new ZipFile(); 
Content ct = zf->load(); 
ct->print(); 

B를 만들 ZipFile를 생성자에게 기본적으로

class ZipFile 
{ 
    private Content content; 

    public function ZipFile(content) // constructor 
    { 
     this->content = content; 
    }  
    public function load() 
    { 
     // Load all files in zip 
     // ... 
     this->content->set(data); 
    } 
} 
Content ct = new Content(); 
ZipFile zf = new ZipFile(ct); 
zf->load(); 
ct->print(); 

을 채우기 위해 콘텐츠 객체를 제공합니다 더 나은입니다 물체 분리 (느슨한 커플 링)? 구식 절차 프로그래머로서 나는 OOP를 디자인하는 몇 가지 방법에 대해 질문하는 것을 멈출 수 없다. 나는 그것을 통해 생각하는 무엇을 OOP이. 어떤 조언하는 가장 좋은 방법은 무엇입니까? 책? 웹 사이트 "에 많은 시간을 잃게? 당신의 도움에 대한

감사를 두 경우에 대한

Answer 1

일반화가 다르다 :.

첫번째 경우는 그 내용의 구체적인 클래스를 알고, 및 인터페이스의 일부 구현 복귀 ZipFile로 일반화

번째 경우는 그 내용에 대한 인터페이스를 알고, 및 콘크리트를 수용 ZipFile로 일반화 te 클래스 (나중에 초기화하려면 ??).

다른 말로 표현하면, 첫 번째 경우는 ZipFile이고 구체적인 콘텐츠 클래스는 무엇이든 연결됩니다. 두 번째는 ZipFile 클라이언트와 구체적인 내용 클래스를 연결합니다.

ZipFile이 내용에 특정 구체 클래스를 사용하는 경우가 많으므로 첫 번째 일반화는 아마도 자연스러운 것입니다.