클래스를 리팩토링하고 새로운 의존성을 추가하고 있습니다. 클래스는 현재 생성자에서 기존 종속성을 사용하고 있습니다. 일관성을 위해 생성자에 매개 변수를 추가합니다.
물론 단위 테스트를위한 몇 가지 서브 클래스와 그 밖의 여러 클래스가 있으므로 이제 모든 생성자를 변경하여 게임을 진행하고 있습니다.
setter와 함께 속성을 사용하는 것이 종속성을 얻는 더 좋은 방법이라고 생각합니다. 주입 된 의존성이 클래스의 인스턴스를 구성하는 인터페이스의 일부라고 생각하지 않습니다. 종속성을 추가하면 이제 모든 사용자 (서브 클래스 및 직접 인스턴스화하는 사람)가 갑자기이를 알게됩니다. 캡슐화가 깨지는 것 같습니다.
이것은 기존 코드의 패턴이 아닌 것 같으므로 생성자 대 속성의 장단점에 대한 일반적인 합의가 무엇인지 찾고 있습니다. 속성 설정기를 사용하는 것이 더 낫습니까?
답변:
글쎄, 그것은 :-)에 달려 있습니다.
클래스가 종속성없이 작업을 수행 할 수 없으면 생성자에 추가하십시오. 클래스 에는 새로운 종속성이 필요 하므로 변경 사항이 변경되기를 원합니다. 또한 완전히 초기화되지 않은 클래스 ( "2 단계 구성")를 만드는 것은 반 패턴 (IMHO)입니다.
클래스가 종속성없이 작동 할 수 있다면 setter가 좋습니다.
클래스의 사용자가되는 가정 주어진 클래스의 종속성에 대해 알고. 예를 들어 데이터베이스에 연결된 클래스가 있고 지속성 계층 종속성을 주입하는 수단을 제공하지 않은 경우 사용자는 데이터베이스에 대한 연결을 사용할 수 있어야한다는 것을 절대 알 수 없습니다. 그러나 생성자를 변경하면 지속성 계층에 대한 종속성이 있음을 사용자에게 알립니다.
또한 이전 생성자의 모든 사용을 변경하지 않으려면 이전 생성자와 새 생성자의 임시 브리지로 생성자 체인을 적용하기 만하면됩니다.
public class ClassExample
{
public ClassExample(IDependencyOne dependencyOne, IDependencyTwo dependencyTwo)
: this (dependnecyOne, dependencyTwo, new DependnecyThreeConcreteImpl())
{ }
public ClassExample(IDependencyOne dependencyOne, IDependencyTwo dependencyTwo, IDependencyThree dependencyThree)
{
// Set the properties here.
}
}
의존성 주입의 포인트 중 하나는 클래스가 갖는 의존성을 밝히는 것입니다. 클래스가 너무 많은 의존성을 가지고 있다면, 일부 리팩토링이 일어날 시간이다 : 클래스의 모든 메소드가 모든 의존성을 사용 하는가? 그렇지 않다면, 그것은 수업이 어디로 나뉘어 질 수 있는지를보기에 좋은 출발점입니다.
일반적으로 선호되는 방법은 생성자 주입을 가능한 많이 사용하는 것입니다.
생성자 주입은 객체가 올바르게 작동하기 위해 필요한 종속성이 무엇인지 정확하게 나타냅니다. 일부 종속성이 설정되지 않았기 때문에 객체를 새로 고치고 메소드를 호출 할 때 충돌하는 것보다 더 성가신 것은 없습니다. 생성자가 반환 한 객체는 작동 상태에 있어야합니다.
생성자를 하나만 사용하면 디자인이 단순하고 모호함을 피할 수 있습니다 (인간이 아닌 경우 DI 컨테이너의 경우).
Mark Seemann 이 자신의 저서 ".NET에 의존성 주입 (Dependency Injection in .NET)"에서 로컬 기본값 을 호출 할 때 특성 주입을 사용할 수 있습니다 . 종속성은 선택 사항입니다. 제대로 작동하는 구현을 제공 할 수 있지만 호출자가 다른 경우를 지정할 수 있기를 바랍니다. 필요합니다.
(아래의 이전 답변)
주입이 필수 인 경우 생성자 주입이 더 좋다고 생각합니다. 생성자가 너무 많으면 생성자 대신 팩토리를 사용하는 것이 좋습니다.
주입이 선택 사항이거나 반쯤 통과 시키려면 세터 주입이 좋습니다. 나는 일반적으로 세터를 좋아하지 않지만 맛의 문제입니다.
그것은 개인적인 취향의 문제입니다. 개인적으로 나는 setter 주입을 선호하는 경향이 있습니다. 왜냐하면 런타임에 구현을 대체 할 수있는 방식으로 더 많은 유연성을 제공하기 때문입니다. 또한 많은 인수를 가진 생성자는 내 의견으로는 깨끗하지 않으며 생성자에서 제공되는 인수는 비 선택적 인수로 제한되어야합니다.
클래스 인터페이스 (API)가 작업을 수행하는 데 필요한 것이 명확하다면, 좋습니다.
나는 개인적으로 생성자에 의존성을 주입 하는 것보다 추출 및 재정의 "패턴"을 선호합니다 . 주로 귀하의 질문에 요약 된 이유 때문입니다. 속성을로 설정 virtual한 다음 파생 된 테스트 가능 클래스에서 구현을 재정의 할 수 있습니다 .
이것이 가장 논리적으로 보이기 때문에 생성자 주입을 사용합니다. 그것의 내 수업을 말하는 등 필요로 그 일을하기 위해 이러한 종속성을. 선택적인 의존성이라면 속성이 합리적으로 보입니다.
또한 컨테이너를 사용하여 만든 발표자의 ASP.NET View와 같은 컨테이너에 참조가없는 것을 설정하기 위해 속성 삽입을 사용합니다.
나는 그것이 캡슐화를 깨뜨릴 것이라고 생각하지 않는다. 내부 작업은 내부적으로 유지되어야하며 종속성은 다른 문제를 처리합니다.
고려해야 할 한 가지 옵션은 간단한 단일 종속성으로 복잡한 다중 종속성을 구성하는 것입니다. 즉, 복합 종속성에 대한 추가 클래스를 정의하십시오. 이렇게하면 WRT 생성자 주입이 훨씬 쉬워집니다 (호출 당 더 적은 매개 변수).
물론 어떤 종류의 의존성에 대한 논리적 그룹이있는 경우 가장 합리적이므로 화합물은 임의의 집합 이상이며 단일 화합물 의존성에 대해 여러 개의 의존성이있는 경우 가장 적합합니다.하지만 매개 변수 블록 "pattern"은 오랫동안 주변에 있었고, 내가 본 대부분은 꽤 임의적이었습니다.
하지만 개인적으로 저는 메소드 / 프로퍼티 세터를 사용하여 의존성, 옵션 등을 지정하는 것을 좋아합니다. 통화 이름은 진행 상황을 설명하는 데 도움이됩니다. 그러나이 방법은 설정하는 스 니펫 예제를 제공하고 종속 클래스가 충분한 오류 검사를 수행하는지 확인하는 것이 좋습니다. 설정에 유한 상태 모델을 사용할 수 있습니다.
최근 에 클래스에 여러 종속성이 있는 상황이 발생했지만 각 구현에서 종속성 중 하나만 변경되어야합니다. 데이터 액세스 및 오류 로깅 종속성은 테스트 목적으로 만 변경 될 수 있으므로 선택적 매개 변수를 추가했습니다. 해당 종속성에 대한 를 하고 생성자 코드에서 해당 종속성의 기본 구현을 제공했습니다. 이런 식으로 클래스는 소비자가 클래스를 재정의하지 않는 한 기본 동작을 유지합니다.
선택적 매개 변수 사용은 .NET 4와 같이 매개 변수를 지원하는 프레임 워크에서만 수행 할 수 있습니다 (VB.NET에는 항상 있었지만 C # 및 VB.NET 용). 물론, 클래스의 소비자가 재 할당 할 수있는 속성을 사용하여 유사한 기능을 수행 할 수 있지만, 개인 인터페이스 객체를 생성자의 매개 변수에 할당하면 불변성의 이점을 얻을 수 없습니다.
모든 소비자가 제공해야하는 새로운 종속성을 도입하는 경우 생성자와 클래스를 소비자로 사용하는 모든 코드를 리팩터링해야합니다. 위의 제안은 실제로 모든 현재 코드에 기본 구현을 제공 할 수 있지만 필요한 경우 기본 구현을 무시할 수있는 기능을 제공하는 경우에만 적용됩니다.
이것은 오래된 게시물이지만 나중에 필요할 경우 유용합니다.
https://github.com/omegamit6zeichen/prinject
나는 비슷한 생각을 가지고이 프레임 워크를 생각해 냈습니다. 아마도 완전하지는 않지만 속성 삽입에 중점을 둔 프레임 워크의 아이디어입니다.
구현 방법에 따라 다릅니다. 구현에 들어가는 값이 자주 바뀌지 않는다고 느낄 때마다 생성자 주입을 선호합니다. 예 : compag 전략이 오라클 서버와 함께 진행되는 경우, 생성자 주입을 통해 bean achiveing 연결에 대한 내 데이터 소스 값을 구성합니다. 그렇지 않으면 내 앱이 제품이고 고객의 모든 DB에 연결할 수있는 경우 setter injection을 통해 이러한 DB 구성 및 다중 브랜드 구현을 구현합니다. 방금 예를 들었지만 위에서 언급 한 시나리오를 구현하는 더 좋은 방법이 있습니다.
생성자 주입은 의존성을 명시 적으로 보여 주므로 생성자에서 인수를 확인하면 코드를 더 읽기 쉽고 처리 할 수없는 런타임 오류가 덜 발생하지만 실제로는 개인적인 견해로 귀결되며 DI를 많이 사용할수록 더 많이 사용할 수 있습니다 프로젝트에 따라 어떤 방향 으로든 앞뒤로 흔들리는 경향이 있습니다. 개인적으로 긴 인수 목록을 가진 생성자와 같은 코드 냄새 문제가 있으며, 어쨌든 객체 소비자는 객체를 사용하기 위해 종속성을 알아야한다고 생각하므로 속성 삽입을 사용하는 경우가됩니다. 나는 속성 주입의 내재적 특성을 좋아하지 않지만 더 우아하게 보이고 코드를 더 깨끗하게 만듭니다. 다른 한편으로, 생성자 주입은 더 높은 수준의 캡슐화를 제공합니다.
특정 시나리오에 따라 생성자 또는 속성별로 주입을 현명하게 선택하십시오. DI가 필요한 것처럼 보이고 DI가 나쁜 디자인 및 코드 냄새를 방지 할 수 있다고 생각할 필요는 없습니다. 노력과 복잡성이 이점보다 큰 경우 패턴을 사용하려는 노력이 가치가없는 경우가 있습니다. 간단하게 유지하십시오.