SOLID : 동일한 클래스 생성자 호출이 허용됩니까?

Question

실제로 솔리드 코드의 중요한 속성은 생성자 호출이 실제 응용 프로그램 코드 내에서 발생하지 않지만 주로 필요한 경우 컴포지션 루트 및 팩터 리 메서드에서 발생한다는 사실입니다. 이것은 나에게 많은 의미가 있으며, 나는이 모든 것을 할 수있다.

나는 그것이 허용되는 것만 큼 단순한 클래스를 만들었지 만 위의 규칙에서 벗어나는 것이 맞습니다. 의 OpenSubKey() 방법은 실제로 공장을 사용하지 않고이 같은 클래스의 인스턴스를 생성

public class RegistryKeyProxy : IRegistryKey 
{ 
    private RegistryKey registrykey; 

    public RegistryKeyProxy(RegistryKey registrykey) 
    { 
     this.registrykey = registrykey; 
    } 

    public IRegistryKey OpenSubKey(string subKeyName) 
    { 
     var subkey = this.registrykey.OpenSubKey(subKeyName); 

     return (null == subkey ? null : new RegistryKeyProxy(subkey)); 
    } 

    public IEnumerable<string> GetSubKeyNames() 
    { 
     return this.registrykey.GetSubKeyNames(); 
    } 

    public object GetValue(string valueName) 
    { 
     return this.registrykey.GetValue(valueName); 
    } 
} 

하지만 때문에 폐쇄 개념 레지스트리 선물 : 이것은 다른 코드의 단위 테스트를 용이하게하기 위해 몇 가지 간단한 레지스트리 쿼리를 추상화 실제로는 은 레지스트리 키처럼 보이지만 실제로는 현재 개체와 정확히 같은 방식으로 작동하는 것을 반환하지 않는 것이 바람직합니다.

결국 나는 그것이 일하기를 얼마나 열심히하는지 알고 있습니다. 그러나 이것이 일반적으로 기본 개념의 본질 때문에 가능한 실현 가능한 길인지 알고 싶습니다. 규칙의 예외는 아니지만 실제로 SOLID 위반입니다.

Answer 1

당신은 Dependency Inversion principle에 대해 이야기하고 있습니다. 이 원칙은 객체를 전혀 새로 작성하지 말아야한다고 말하지는 않지만 두 유형의 객체를 구별합니다. 행동 (서비스)을 구현하는 객체 및 데이터 (DTO, 값 유형, 엔터티)를 포함하는 객체.

추상화 할 동작이 없으므로 DTO를 새로 만드는 것이 바람직하지 않습니다. 단지 데이터 만 포함합니다. (마찬가지로 Person DTO에 IPerson 인터페이스를 추가하는 것은 어리 석다.)

Miško Hevery는 그 (것)들을 injectables and newables, 좋은 terminolgoy이라고 칭한다. 생성자 (코드의 파괴하지 않고 어쨌든 대체 할 수없는 기본 프레임 워크 클래스에 대한 저장한다는 사실이 Why not use an IoC container to resolve dependencies for entities/business objects?