소프트웨어가 고도로 결합되어 있는지 어떻게 알 수 있습니까?

나는 "높은 결합"이라는 용어에 익숙하지만 코드가 높은 결합을 나타내는 신호 (코드 냄새)가 있는지 궁금합니다. 현재 Java EE로 작업하고 있지만 모든 언어에 적용 할 수 있습니다.

편집하다:

관심있는 사람이 있다면이 기사가 도움이 될 것입니다. 코드 품질 추구 : 꽉 조이는 커플을 조심하십시오! (IBM)

제 생각에 잘못 결합 된 모듈의 가장 큰 지표는 양자 의존성입니다. 예를 들어, Module1 1은 Module2에서 일부 함수를 호출하고 Module2는 Module1에서 일부 함수를 호출합니다.

대부분의 인터페이스는 단방향이어야합니다. 호출 된 모듈이 호출의 일부로 리턴되지 않은 일부 정보를 호출 모듈에 전달해야하는 경우 메시지 큐와 같은 일종의 메시지 전달 또는 이벤트 트리거 메커니즘을 사용해야합니다. 이상적으로는 일부 초기화 또는 등록 프로세스 중에 메시지 전달 인터페이스 핸들을 전달해야합니다. 이것은 모듈이 실제로 이벤트의 대상을 신경 쓰지 않는 방식으로 인터페이스를 완전히 추상화하므로 분리됩니다.

또 다른 표시는 한 모듈이 특정 데이터 세트에 대해 다른 모듈을 지속적으로 호출하는 경우입니다. 그러면 누가 실제로 데이터 세트를 소유해야하는지 질문해야합니다. 이 모듈이 항상 다른 모듈에 속하는 데이터를 볼 필요가있는 이유는 무엇입니까?

말할 세 번째 도구는 "이 모듈을 꺼내서 다른 모듈을 변경하지 않고 교체 할 수 있습니까?"

이것은 완전한 목록은 아니지만 소프트웨어를 설계 할 때 내가 직접 요구하는 세 가지 사항입니다.

오래된 디자인의 말은 "친구를 만질 수 있고, 사적인 것을 만질 수는 있지만 친구의 사적인 것은 만질 수 없다는 것입니다." 간단히 말해서 커플 링입니다.

고도로 결합 된 코드의 징후에는 구현에 대한 개인 정보를 사람들에게 알려주는 매우 큰 인터페이스와 "서로 많은 것을 알고있는"객체가 포함됩니다. 자동 분석 도구는 밀접하게 결합 된 것처럼 보이는 코드를 표시합니다. 임의의 것은 http://www.scitools.com/features/metricsintro.php 를 참조 하십시오 . (어떻게 작동하는지 잘 모르겠습니다. Google 검색에서 상당히 높았습니다.)

수업에 대한 단위 테스트를 작성해보십시오. 많은 지원 클래스 또는 db / ui를 생성 / 모의 할 필요없이 클래스를 쉽게 테스트 할 수없는 경우 잘못된 커플 링 / 의존성에 대한 확실한 신호입니다.

또한 최고의 치료법 중 하나이지만 TDD와 같은 코딩 중에 정직하게 유지해야합니다.

나에게 명백한 신호는 모든 것이 공개되어 있다는 것입니다.

다른 표시는 Demeter Laws of Demeter 위반입니다.

나는 데이터 입력 양식을 즉석에서 구축 한 "puppetmaster class"라고 불렀습니다. 다른 몇 가지 소프트웨어 설계 위반이 있었으므로 과도한 커플 링이 가장 큰 문제였습니다.

생성 된 컨트롤에서 데이터를 검색 할 때 다음과 같이되었습니다.

var control = activeDataEntryControl as CustomTextBox;
if (control != null)
   result = control.NestedTextBox.Text;

/* several other controls */

파급 효과 .

모든 변경 사항은 단단히 결합 된 모든 모듈을 통해 파급 효과가 있습니다.

"폐쇄"원칙은 올바르게 닫히지 않고 누출이 발생한다는 점을 위반했습니다.

클래스 / 패키지 / dll / jars / whatnots 사이의 # include / imports 등의 수를 확인하십시오. 정신적으로, 수동으로 또는 어떤 종류의 도구를 사용하여 그래프를 그리십시오.

• 해당 그래프가 밀도가 높으면 (즉, 여러 곳에서 많은 연결이있는 경우) 시스템은 모 놀리 식이며 고도로 결합됩니다.
• 계층 간 / 통과 계층없이 연결이 명확하게 구분되어 있고 연결이 거의없는 경우 모듈 식 및 분리 된 시스템이 있습니다.

특정 책임이 어디로 가는지 모르기 때문에 기능을 구현할 수없는 경우 시스템이 너무 밀접하게 연결되어 있습니다.

매우 기본적인 표시의 경우, 서로 다른 패키지의 클래스 간 인터페이스 수와 그 사용법 (보통 느슨하게 결합 된 코드에 인터페이스가 포함되어 있고 다른 패키지의 개별 클래스간에 직접 상호 작용이 제한되어 있음), 클래스 이름 수를 고려할 수 있습니다. 다른 클래스를 그룹화하는 데 사용됩니다 (느슨하게 결합 된 코드에서 다른 작업을 갖는 클래스 간의 실제 상호 작용은 인터페이스 함수 또는 더 일반적인 / 그룹화 클래스의 함수에 의해 수행됨) 또는 클래스 내부의 공용 변수 수 (더 느리게 / 덜 공용 변수 없음) ).

거의 모든 코드 냄새가 어떤 방식으로 불필요한 커플 링을 나타냅니다. 나는 "부적절한 친밀감"(내가 가장 좋아하는 냄새)일지도 모르지만 커플 링을 가장 많이 나타내는 냄새가 있다고 가정합니다.

UML 다이어그램에서 줄을 계산하는 것이 합리적인 합리적인 방법이라고 생각합니다. N 개의 객체가 있고 그 사이에 N ^ N (또는 그 이상) 줄이 있으면 코드가 거의 최대로 결합됩니다. N 줄은 아마도 당신이 얻을 수있는 한 최소한 일 것입니다.