팩토리를 주입하면 종속성이 숨겨 집니까?

Question

클래스 A에는 제품 B을 생성하는 factory 필드가 있습니다. factory은 의존성 주입을 사용하여 주입됩니다. factory을 주입하면 A 클래스의 종속성이 클래스 Product에 숨겨져 있습니까?

이 질문을하기위한 목적 : 코딩 할 때 예제 코드와 같은 코드를 만들었으므로 좋은 디자인인지 여부를 알 수 없습니다. 의존성을 숨기는 것이 나쁜 설계라고 생각합니다.

예제 코드 :

class A 
{ 
    private Factory factory; 

    public A(Factory factory) 
    { 
     this.factory=factory; 
    } 

    public Product getProduct() 
    { 
     return factory.produce(); 
    } 

    public void doSomething() 
    { 
     Product B = getProduct(); 
     // use Product to do something 
    } 

} 

Answer 1

아니, 의존성을 숨기지 않습니다 Factory에서 Product를 받고. A은 Product을 반환하는 getProduct을 정의하므로 A은 Product에 따라 다릅니다. 당신이 getProduct, A 차례로 결합으로 단지가 될 것이다, Product에 따라 Factory에 따라 달라 인라인하더라도

.

Product에서 A가 인터페이스 Product 및 클래스 ProductImpl (또는 무엇이든)에 클래스 Product을 분리하고, 의존성 주입 또는 공장 중 하나를 사용하는 것입니다 분리하는 일반적인 방법으로 얻을 수 (한 번에 모두 일반적으로 과잉이다) 구현 클래스를 모른 채 Product의 인스턴스 그러면 A은 클래스에 의존하는 것보다 덜 결합 된 인터페이스에만 의존합니다.

사이드 노트 : B은 상수 또는 클래스 이름처럼 보이기 때문에 혼란스러운 변수 이름입니다. b을 사용하는 것이 더 일반적입니다.

Answer 2

코드가 Product가 추상적이고 "Product B"가 실제로 "MobileProduct", 과 같이 해당 클래스의 파생물 인스턴스 인 경우에만 코드가 종속성을 숨 깁니다. "그것이 존재하지 않습니다.

공장이 추상적 인 경우 실제로는 제품을 생산할 수있는 여러 가지 방법을 숨 깁니다. 예를 들어 "SqlProductFactory"또는 "InMemoryProductFactory"가있는 경우 그런 다음 제품의 저장, 생성 또는 원본에 대한 의존성을 숨 깁니다.

날씨가 좋든 없든간에 공장은 설계에 좋든 그렇지 않든간에 문제는 매우 다르며 해결 방법은 무엇입니까? 예를 들어 큰 API 또는 라이브러리를 작성하는 경우 소비자가 알 필요가없는 일부 종속성을 숨길 수 있습니다. 그러나 "Hello World"또는 "FizzBuzz"만 해결하면 클래스는 필요하지 않습니다. 공장은 말할 것도 없습니다.

질문에 대한 답변을 보려면 코드가 종속성을 숨기고 있습니까? 좋은 디자인인가요? 두 경우 모두 그것은 현재의 문제에 달려 있습니다. 여기

EnemyBase { 
int Hitpoints; 
int Damage; 
void Speak(); 
} 

EasyEnemy : EnemyBase { 
    public int Hitpoints = 100; 
    public int Damage = 20; 
    private string Name = "EZGuy"; 
    public void Speak(){ 
     print this.Name + ": I shall destroy you!"; 
    } 
} 

HardEnemy : EnemyBase { 
    public int Hitpoints = 200; 
    public int Damage = 40; 
    private string Name = "Da hard1"; 
    public void Speak(){ 
     print this.Name + ": Your days are numbered!"; 
    }{ 
} 

EnemyFactory { 
    private int EnemiesProduced = 0; 
    public EnemyBase getEnemy(){ 
    if(IsOdd(++this.EnemiesProduced)){ 
     return new EasyEnemy(); 
    } else { 
     return new HardEnemy(); 
    } 
    } 
} 

Game { 
    EnemyFactory enemies; 
    public Game(EnemyFactory factory){ 
    enemies = factory; 
    } 
    public void Start(){ 
    EnemyBase e = factory.getEnemy(); 
    } 
} 

게임 그것은 단지 EnemyBase을 얻기에 대한 관심, HardEnemy 또는 EasyEnemy에 대해 아무것도 알지 못한다. 또한 EnemyBase 클래스가 제공하는 두 가지 공개 필드 및 말하기 메서드에 대해서만 알 수 있습니다. 좋은 일일 수도 있고 그렇지 않을 수도 있습니다. 예를 들어 여기서는 게임을 변경하지 않고 적의 구현을 변경할 수 있습니다. 게임 개발에 관심을 두지 않고 적을 개발하고 게임에 어떤 영향을 미치는지 테스트 해 봅시다.그래서 그것은 정말 좋은 일이 될 수 있습니다. 당신이 일을 더 빨리, 어쩌면 팀간에, 또는 미래의 솔루션을 증명하도록 해봅시다. [

그래서 결론 : 정말 따라 달라집니다 : (말 장난이 또는 구성되지 않을 수 있음)