2011-01-04 8 views
32

생성자에 전달할 매개 변수가 12 개인 클래스가 있습니다. 따라서이 수업의 디자인에는 문제가 있다고 생각합니다.생성자의 매개 변수 수

클래스, 특히 생성자의 디자인과 관련하여 디자인 패턴이나 일반적인 규칙 모음이 있는지 묻고 싶습니다.

+2

12 개의 매개 변수를 사용하는 생성자는 코드 냄새입니다. 가장 가능성이 높은 클래스는 너무 많이하려고합니다. –

+0

이 질문을보십시오 : [how-many-variables-should-a-constructor-have] (http://stackoverflow.com/questions/1434498/how-many-variables-should-a-constructor-have) OP가 C#을 사용하고 있지만 답변은 C++에 적용됩니다. – Tony

답변

34

12 매개 변수가 너무 많아서 나에게 너무 많이 들립니다. 옵션은 숫자가 감소합니다 :

  1. Introduce Parameter Object 객체로 논리적으로 관련 매개 변수를 그룹화하고 개별 매개 변수 대신 그 객체를 전달하여.

  2. Builder (임의로 method chaining)을 도입하십시오. 이렇게하면 실제 매개 변수 목록이 줄어들지 않지만 코드를보다 읽기 쉽게 만들 수 있으며 매개 변수가 여러 개인 여러 작성 시나리오가있는 경우 특히 유용합니다. 그래서 그 대신

    MyClass someObject = new MyClass(aFoo, aBar, aBlah, aBaz, aBorp, aFlirp, 
         andAGoo); 
    MyClass anotherObject = new MyClass(aFoo, null, null, aBaz, null, null, 
         andAGoo); 
    

    의 당신이

    MyClass someObject = new MyClassBuilder().withFoo(aFoo).withBar(aBar) 
         .withBlah(aBlah).withBaz(aBaz).withBorp(aBorp).withFlirp(aFlirp) 
         .withGoo(aGoo).build(); 
    MyClass anotherObject = new MyClassBuilder().withFoo(aFoo).withBaz(aBaz) 
         .withGoo(aGoo).build(); 
    
  3. 가 (아마이 시작해야 할 수 있습니다 ;-) 매개 변수를 분석 - 그들 모두는 정말 (즉, 필수) 생성자에 필요합니까? 매개 변수가 선택적이면 생성자 대신 일반 설정자를 통해 매개 변수를 설정할 수 있습니다. 나쁜 디자인 나쁜 디자인에 대한 호출 함수가 열한 매개 변수를 사용하는 경우

+3

+1 빌더 접근법에 대한, 그것은 우아한 솔루션입니다 – stijn

+4

나는 1이나 2를 시도하기 전에 확실히 3 할 것입니다 : –

2

예를 들어 State 패턴을 사용할 때 이것이 받아 들일 수 있다고 생각합니다. 그러나 해당 매개 변수가 대신 제공되는 개체 (적절한 경우)를 전달할 것을 제안 할 수 있습니까? 그런 다음 생성자에서 데이터를로드하는 중입니까?

4

가능한 경우 클래스별로 매개 변수를 그룹화하고 해당 인스턴스를 생성자에 전달할 수 있습니다.

+0

이것은 취한 접근법입니다. Win32 API 함수에 의해. –

9

, 당신은 아마 그것을 전부 요약 때문에 나는이 문장을 사랑 한 번 더

를 잊어 버렸습니다.

나는 Herb Sutter, Andrei Alexandrescu의 C++ 코딩 표준 : 101 규칙, 가이드 라인 및 모범 사례에서 가져 왔습니다.

편집 : 직접 견적은 입니다. 매개 변수가 10 개있는 프로 시저가있는 경우이 누락 된 것일 수 있습니다. 자체는 a quote from Alan Perlis입니다.

매개 변수가 너무 많은 함수는 잘못된 디자인의 증상입니다. 정의 된 목표를 가진 엔티티/클래스에서 이러한 매개 변수의 일부를 캡슐화 할 가능성이 있습니다. (의미있는 구조없이 모든 매개 변수를 나열하는 가비지 클래스가 아님).


결과로서 Single Responsibility Principle 을 잊지 못할 그 생성자에 필요한 매개 변수의 크기가 제한 따라서, 클래스 크기가 제한 유지, 그리고 결과적으로, 회원 paramters의 수를 제한합니다.아래의 주석 중 하나와 같이 너무 많은 생성자 매개 변수를 가진 클래스는 주요 목표와 별개로 쓸데없는 세부 사항을 너무 많이 처리 할 수 ​​있습니다.


이 하나에보기가 너무 좋습니다 : How many parameters are too many?

+0

그것은 풍자입니다! :-) – ltjax

+0

풍자, 아이러니 ;-) 당신이 느끼는대로 :-) –

+2

+1 코드 냄새입니다. 수업이 많은 세부 사항을 돌보는 것처럼 들립니다. 하지만 매개 변수 클래스가 실제로 냄새를 감추고 있다고 생각합니다. – daramarak

5

12 매개 변수, 뭔가 아마 디자인에 문제가 있습니다.

매개 변수로 수행되는 작업은 무엇입니까?

  • 클래스가 다른 생성자로 전송하나요? 그러면 아마도 준비된 객체에 대한 인터페이스 만 받아 들여야합니다.
  • 클래스가 크고 이러한 모든 매개 변수를 사용하여 많은 작업을 수행합니까? 그런 다음 클래스는 많은 책임을지고 대신 세부 정보를 처리하는 클래스를 받아 들여야합니다.
  • 매개 변수에 "클러스터"가 있습니까? 아마도 생성시 클래스의 일부입니다. 그들을 캡슐화하고 그들에게 적절한 책임을 부여하십시오.

대안으로 이것은 낮은 수준의 성능 중요한 구성을위한 매개 변수이며,이 경우 디자인은 좌석을 다시 가져와야하지만 그럴 경우는 거의 없습니다.