클래스 결합은 원래 CK94에서 정의한 대로 CBO(개체 간 결합)라는 이름으로도 사용됩니다. 기본적으로 클래스 결합은 단일 클래스에서 사용하는 클래스 수의 측정값입니다. 높은 숫자가 잘못되고 낮은 숫자는 일반적으로 이 메트릭에 적합합니다. 클래스 결합은 소프트웨어 오류의 정확한 예측 변수로 나타났으며 최근 연구에 따르면 상한값 9가 가장 효율적인 S2010입니다.
Microsoft 설명서에 따르면 클래스 결합은 "매개 변수, 지역 변수, 반환 형식, 메서드 호출, 제네릭 또는 템플릿 인스턴스화, 기본 클래스, 인터페이스 구현, 외부 형식에 정의된 필드 및 특성 장식을 통해 고유 클래스에 대한 결합을 측정합니다. 좋은 소프트웨어 디자인은 형식과 메서드가 높은 응집력과 낮은 결합을 가져야 한다는 것을 지시합니다. 높은 결합은 다른 형식의 상호 종속성이 많기 때문에 재사용 및 유지 관리가 어려운 디자인을 나타냅니다."
결합과 응집력의 개념은 명확하게 관련이 있습니다. 이 주제에 대한 논의를 유지하기 위해, KKLS2000에서 가져온 간단한 정의를 제공하는 것을 제외하고는 응집력에 대해 깊이 있게 논의하지 않을 것입니다.
모듈 응집력은 Yourdon과 Constantine에 의해 '모듈의 내부 요소가 서로 얼마나 긴밀하게 결합되거나 관련되어 있는지' 개념으로 소개되었습니다 YC79. 모듈은 정확히 하나의 작업 [...]을 나타내고 모든 요소가 이 단일 작업에 기여하는 경우 강력한 응집력을 갖습니다. 이러한 특성은 응집력을 코드가 아닌 디자인의 특성으로 설명하고 재사용성, 유지 관리 가능성 및 변경 가능성을 예측하는 데 사용할 수 있는 특성입니다."
클래스 결합 예제
작동 중인 클래스 결합을 살펴보겠습니다. 먼저 새 콘솔 애플리케이션을 만들고 일부 속성을 사용하여 Person이라는 새 클래스를 만든 다음 코드 메트릭을 즉시 계산합니다.
이 클래스는 다른 클래스를 사용하지 않으므로 클래스 결합은 0입니다. 이제 Person 인스턴스를 만들고 속성 값을 설정하는 메서드를 사용하여 PersonStuff라는 다른 클래스를 만듭니다. 코드 메트릭을 다시 계산합니다.
클래스 결합 값이 어떻게 올라가는지 확인하세요. 또한 설정한 속성 수에 관계없이 클래스 결합 값은 다른 값이 아니라 1로 올라갑니다. 클래스 결합은 사용되는 양에 관계없이 이 메트릭에 대해 각 클래스를 한 번만 측정합니다. 또한 DoSomething()가 1인 것을 확인할 수 있지만, 생성자 PersonStuff()의 값이 0인지 볼 수 있습니까? 현재 생성자에 다른 클래스를 사용하는 코드가 없습니다.
다른 클래스를 사용하는 생성자에 코드를 넣으면 어떻게 될까요? 얻을 수 있는 것은 다음과 같습니다.
이제 생성자에는 다른 클래스를 사용하는 코드가 분명히 있으며 클래스 결합 메트릭은 이 사실을 보여줍니다. 다시 말하지만, PersonStuff()의 전체 클래스 결합은 1이고, DoSomething()도 1로 표시되어, 사용하는 내부 코드 양에 관계없이 하나의 외부 클래스만 사용되고 있음을 알 수 있습니다.
다음으로, 다른 새 클래스를 만듭니다. 이 클래스에 이름을 지정하고 그 안에 몇 가지 속성을 만듭니다.
이제 DoSomething() 클래스를 PersonStuff 클래스 내부의 메서드에서 사용하여 코드 메트릭을 다시 계산합니다.
볼 수 있듯이 PersonStuff 클래스의 클래스 커플링은 최대 2까지 올라가며, 클래스를 자세히 살펴보면 DoSomething() 메서드에 가장 많은 커플링이 있지만 생성자는 여전히 단 1개의 클래스만 사용한다는 것을 알 수 있습니다. 이러한 메트릭을 사용하여 지정된 클래스의 전체 최대 수를 확인하고 멤버별로 세부 정보를 드릴다운할 수 있습니다.
매직 넘버
주기적 복잡성과 마찬가지로 모든 조직에 맞는 제한은 없습니다. 그러나 S2010 은 9의 제한이 최적임을 나타냅니다.
"따라서 임계값을 고려합니다.[...] 가장 효과적입니다. 이러한 임계값(단일 멤버의 경우)은 CBO = 9[...]입니다." (강조 추가됨)
코드 분석
코드 분석에는 유지 관리 규칙 범주가 포함됩니다. 자세한 내용은 유지 관리 규칙참조하세요. 레거시 코드 분석을 사용하는 경우 확장 디자인 지침 규칙 집합에는 유지 관리 영역이 포함됩니다.
유지 관리 영역 내에는 클래스 결합에 대한 규칙이 있습니다.
이 규칙은 클래스 결합이 과도하면 경고를 발생합니다. 자세한 내용은 CA1506: 과도한 클래스 결합 방지를 참조하세요.
인용
CK94
치담버, S. R. & 케머, C. F. (1994). 객체 지향 설계를 위한 메트릭스 스위트 (IEEE 소프트웨어 엔지니어링 트랜잭션, 제20권, 제6호). 2011년 5월 14일 피츠버그 대학교 웹 사이트에서 검색: http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf
KKLS2000
Kabaili, H., 켈러, R., 루스트만, F., 생드니, G. (2000). 클래스 응집력 재조명: 산업 시스템에 대한 경험적 연구 (객체 지향 소프트웨어 공학의 양적 접근 방식에 대한 워크샵 논문집). 2011년 5월 20일, Université de Montréal 웹사이트에서 가져옴 http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf
SK2003
수브라마니암, R. & 크리슈난, 엠 에스 (2003). 객체 지향 설계 복잡성에 대한 CK 메트릭스의 경험적 분석: 소프트웨어 결함에 대한 영향 (IEEE 소프트웨어 엔지니어링 논문집, 제 29권, 제 4호).
S2010
샤트나위, R. (2010). 오픈 소스 시스템에서 객체 지향 메트릭의 허용 가능한 위험 수준에 대한 정량적 조사 (IEEE 소프트웨어 엔지니어링 트랜잭션, Vol. 36, No. 2).
YC79
에드워드 네이든과 래리 엘 콘스탄틴. 구조화된 디자인. 프렌티스 홀, 잉글우드 클리프, 뉴저지, 1979년.