코드 메트릭 - 클래스 결합
클래스 결합은 원래 CK94에 의해 정의된 CBO(개체 간 결합)라는 이름으로도 통합니다. 기본적으로 클래스 결합은 단일 클래스가 사용하는 클래스 수의 측정값입니다. 이 메트릭에서는 숫자가 높을수록 나쁘고 숫자가 낮을수록 일반적으로 좋습니다. 클래스 결합은 소프트웨어 실패를 정확하게 예측하는 것이 입증되었으며, 최근 연구에 따르면 상한 값 9가 가장 효율적입니다. S2010
Microsoft 설명서에 따르면 클래스 결합은 “매개 변수, 지역 변수, 반환 형식, 메서드 호출, 제네릭 또는 템플릿 인스턴스화, 기본 클래스, 인터페이스 구현, 외부 형식에 정의된 필드 및 특성 장식을 통해 고유한 클래스에 대한 결합을 측정합”니다. 좋은 소프트웨어 디자인은 형식과 메서드에 높은 응집력과 낮은 결합이 있어야 합니다. 높은 결합은 다른 형식에 대한 상호 종속성이 많기 때문에 다시 사용 및 유지 관리하기 어려운 디자인을 나타냅니다.
결합 개념과 응집력 개념은 분명히 관련되어 있습니다. 이 논의에 집중하기 위해 KKLS2000의 간단한 정의를 제공하는 것 외에는 응집력에 대해 깊이 설명하지 않겠습니다.
"모듈 응집력은 Yourdon과 Constantine에 의해 '모듈의 내부 요소가 서로 얼마나 긴밀하게 바인딩되거나 관련되어 있는가'로 소개되었습니다. YC79. 모듈이 정확히 하나의 작업[...]을 나타내고 모든 요소가 이 단일 작업에 기여하는 경우 모듈에는 강력한 응집력이 있습니다. 이들은 응집력을 코드가 아닌 디자인의 특성, 재사용성, 유지 관리 가능성, 변경 가능성을 예측하는 데 사용할 수 있는 특성으로 설명합니다."
클래스 결합 예
클래스 결합을 직접 살펴보겠습니다. 먼저 새 콘솔 애플리케이션을 만들고 일부 속성을 사용하여 Person이라는 새 클래스를 만든 다음 코드 메트릭을 즉시 계산합니다.
이 클래스는 다른 클래스를 사용하지 않으므로 클래스 결합은 0입니다. 이제 Person의 인스턴스를 만들고 속성 값을 설정하는 메서드를 사용하여 PersonStuff라는 다른 클래스를 만듭니다. 코드 메트릭을 다시 계산합니다.
클래스 결합 값이 어떻게 올라가는지 확인하세요. 또한 설정한 속성 수에 관계없이 클래스 결합 값은 다른 값이 아니라 1씩 올라갑니다. 클래스 결합은 사용되는 양에 관계없이 이 메트릭에 대해 각 클래스를 한 번만 측정합니다. 또한 DoSomething()의 값은 1이지만 생성자인 PersonStuff()의 값은 0인 것이 보이나요? 현재 다른 클래스를 사용 중인 생성자에는 코드가 없습니다.
다른 클래스를 사용한 생성자에 코드를 넣으면 어떻게 될까요? 결과는 다음과 같습니다.
이제 생성자에 다른 클래스를 사용하는 코드가 분명히 있고, 클래스 결합 메트릭은 이 사실을 보여 줍니다. 마찬가지로 PersonStuff()의 전체 클래스 결합이 1이고, DoSomething() 역시 1이어서 사용하는 내부 코드의 양에 관계없이 하나의 외부 클래스만 사용되고 있음을 볼 수 있습니다.
다음으로 다른 새 클래스를 만듭니다. 이 클래스에 이름을 지정하고 그 안에 몇 가지 속성을 만듭니다.
이제 PersonStuff 클래스 내의 DoSomething() 메서드에서 클래스를 사용하고 코드 메트릭을 다시 계산합니다.
보시는 것처럼 PersonStuff 클래스에 대한 클래스 결합은 2까지 올라가며, 클래스를 드릴다운하면 DoSomething() 메서드에 가장 많은 결합이 있지만 생성자는 여전히 1개의 클래스만 사용한다는 것을 알 수 있습니다. 이러한 메트릭을 사용하여 지정된 클래스의 전체 최대 수를 확인하고 멤버별로 세부 정보를 드릴다운할 수 있습니다.
매직 넘버
순환 복잡성과 마찬가지로 모든 조직에 적합한 한도는 없습니다. 그러나 S2010은 한도 9가 최적임을 보여 줍니다.
"따라서 이 임계값[...]을 가장 효과적이라고 생각합니다. 이러한 임계값(단일 멤버의 경우)은 CBO = 9[...]입니다."(강조 추가)
코드 분석
코드 분석에는 유지 관리 규칙 범주가 포함됩니다. 자세한 내용은 유지 관리 규칙을 참조하세요. 레거시 코드 분석을 사용하는 경우 확장 디자인 지침 규칙 집합에는 유지 관리 영역이 포함됩니다.
유지 관리 영역 내에는 클래스 결합에 대한 규칙이 있습니다.
이 규칙은 클래스 결합이 과도하면 경고를 발생시킵니다. 자세한 내용은 CA1506: 과도한 클래스 결합 방지를 참조하세요.
인용문
CK94
치담버, S. R. & 케머, C. F. (1994). A Metrics Suite for Object Oriented Design (IEEE Transactions on Software Engineering, Vol. 20, No. 2011년 5월 14일, University of Pittsburgh 웹 사이트(http://www.pitt.edu/~ckemerer/CK%20research%20papers/MetricForOOD_ChidamberKemerer94.pdf)에서 검색
KKLS2000
Kabaili, H., Keller, R., Lustman, F., and Saint-Denis, G. (2000). Class Cohesion Revisited: An Empirical Study on Industrial Systems (Proceedings of the Workshop on Quantitative Approaches in Object-Oriented Software Engineering). 2011년 5월 20일, Université de Montréal 웹 사이트(http://www.iro.umontreal.ca/~sahraouh/qaoose/papers/Kabaili.pdf)에서 검색
SK2003
&Subramanyam, R. & Krishnan, M. S. Empirical Analysis of CK Metrics for Object-Oriented Design Complexity: Implications for Software Defects (IEEE Transactions on Software Engineering, Vol. 29, No.
S2010
Shatnawi, R. (2010). A Quantitative Investigation of the Acceptable Risk Levels of Object-Oriented Metrics in Open-Source Systems (IEEE Transactions on Software Engineering, Vol. 36, No.
YC79
Edward Yourdon and Larry L. Constantine. Structured Design. Prentice Hall, Englewood Cliffs, N.J., 1979.