Efferent / Afferent 커플 링이 좋은지 나쁜지

이번 주에 소프트웨어 패턴 시험을 보았으며 우리가 공부해야 할 주제 중 하나는 Efferent and Afferent coupling입니다.

패키지가 다른 많은 유형에 의존하는 경우 높은 Ce (efferent coupling) 패키지를 알고 있습니다.

예를 들면 다음과 같습니다.

class Car{
    Engine engine;
    Wheel wheel;
    Body body;
}

이 클래스는 엔진, 휠 및 바디 유형에 따라 다르기 때문에 높은 원심력 커플 링을 갖습니다.

반면 "Wheel"유형은 다른 여러 패키지 (Car, Plane, Bicycle)에 의존하는 경우 높은 Ca (카페트 커플 링)를 갖습니다.

시험에서 가능한 질문 중 하나는 언제 Efferent / Afferent 커플 링이 좋은지 나쁜지입니다. 논리적으로 프로그램에 높은 Efferent / Afferent 커플 링이 모두있는 패키지 / 클래스가 필요하기 때문에 이것은 이상하게 보입니다.

누구든지 언제 / 높은 구 심성 또는 구 심성 결합이 좋은지 / 나쁜지에 대한 예가 있습니까?

감사 !

구 심성 커플 링은 변화의 필요성 또는 가능성으로 인해 얼마나 많은 통증이 발생 / 저장되는지에 관해 가장 쉽게 평가 될 수 있습니다. 예를 들어, 당신의 휠 클래스를 가지고 다른 많은 모듈들이이를 사용하여 다양한 종류의 차량을 제작한다고 가정 해 봅시다. 휠 클래스가 매우 안정적이라면 차량에 휠이 필요하고 신뢰할 수있는 휠을 사용하기 때문에 이러한 구 심성 커플 링이 유리합니다. 반면, 휠 클래스가 유지 보수 측면에서 변동이 심할 경우, 이러한 구 심성 커플 링은 많은 코드에 반복적 인 변경 사항을 반복적으로 도입함에 따라 어려움이 될 것입니다.

서로 다른 커플 링 개념은 비슷하지만 약간 다른 가치 제안을 보게 될 것입니다. 많은 개별 부품에 직접 의존하는 자동차 클래스가있는 경우 ( "엔진"및 "섀시"만 말하고 다른 하위 파트로 구성됨) 클래스는 많은 작업을 수행 할 수 있으므로 유지 보수 병목 현상. 해당 클래스의 변경은 복잡성으로 인해 어렵고 위험 할 수 있습니다. 반면에, efferent coupling이 높지만 실제로 꽤 응집적이고 명확하다면 걱정할 객체와 관계의 계층 구조가 없습니다.

아키텍처 / 디자인과 관련하여 실제로 고려해야 할 것은 끝없는 트레이드 오프이며 이러한 메트릭은 다르지 않습니다. 좋은지 나쁜지에 대한 예를 찾으려면 "what if"게임을하십시오. 예를 상상하고 "X를하고 싶다면 어떻게해야합니까?" 답변이 "많은"X의 경우 단점이 있으며, "실제로 쉬운"답변이있는 X의 경우 이점이 있습니다.

일반적으로 말하면 느슨한 결합 :

긍정적 : 시스템의 일부가 시스템에 의존하는 것의 변화로부터 보호

부정 : 관계를 이해하기가 더 어려울 수 있습니다

예를 들어, HTTTP에 의존하는 시스템을 개발하는 경우 HTTP에 단단히 연결해야하는지 아니면 느슨한 연결을 사용해야하는지 결정합니다. 시스템이 다른 프로토콜로 전환 될 가능성이 있다고 생각되면 느슨하게 연결하도록 선택할 수 있지만 HTTP가 내 프로토콜이라는 사실을 받아들이면 이해하기 쉽게 해당 프로토콜에 밀접하게 연결할 수 있습니다.

WS *의 일부 복잡성은 HTTP와 프로토콜의 분리에 있다고 생각하십시오.

구 심성

무언가가 많은 다른 물건 (많은 수의 구 심성 결합)을 사용한다면, 그러한 것들 중 하나라도 바뀌면 깨지기 쉽습니다.

_{불안정성 = 1}

독립성

여러 가지 물건 (많은 수의 원심 분리기)에 의해 무언가가 사용된다면, 그것이 바뀌면 많은 것들을 깨뜨리기 쉽습니다.

_{불안정성 = 0}

안정

"안정성"에 대한 마틴의 정의는 "변화하기 어렵다"와 "변화 할 이유가 거의 없음"의 이국적인 조화입니다. 그러나 그의 불안정성 지표는 "변화의 어려움"만을 설명합니다. "변경 사유"는 적절한 추상화 수준에서 인터페이스를 적절하게 디자인하고 사용자 엔드 요구 사항을보다 명확하게 이해하는 것과 같이 쉽게 계산할 수없는 요소와 더 관련이 있습니다.

따라서 낮은 구 심성 결합을 갖는 높은 구 심성 결합은 안정성을 제공합니다 (많은 물건을 깰 것이기 때문에 변경하기 어려운 것과 같음), 반대의 수율 불안정성 (많은 물건을 끊지 않기 때문에 변경하기 쉬운 것) .

많은 수의 구 심성 커플 링은 설계에 초점이 없다는 지표 일 수 있습니다. 이는 여러 가지 다른 재료를 사용하므로 명확하고 단일 한 책임이 없을 수 있습니다.

많은 수의 독립형 커플 링은 설계가 광범위하게 재사용되고 있음을 나타내므로 처음에는 정말 좋은 것으로 해석 될 수 있습니다. 그러나 모든 것을 망가 뜨리는 방식으로 디자인을 자주 바꾸고 싶은 유혹이 있다면 그것은 나쁠 것입니다. 따라서 많은 수의 독립형 커플 링을 사용하면 이러한 패키지가 "변경할 이유가 거의 없거나 전혀"없어야합니다. 디자인은 변경해야 할 이유가 전혀없는 이상적인 의미에서 안정적이어야합니다. 디자인도 변경하기가 매우 어렵 기 때문입니다.

안정적인 추상화 원리

의존성 반전 (자연스럽게 의존성 주입을 요구하는)과 SAP (안정적인 추상화 원칙)와 같은 개념은 의존성이 추상화를 향해 흐르고 있음을 암시합니다. 그리고 "변경할 몇 가지 이유"가있는 상황에서 "안정성"을 고려할 때 간단한 이유가 있습니다. 추상 인터페이스는 구체적인 세부 사항을 언급하지 않으며 "무엇이 무엇인지"대신 "무엇을해야하는지"에만 초점을 맞추므로 변경해야 할 이유가 적습니다. 마더 보드의 가속 그래픽 포트 (추상 인터페이스)에는 GPU에 연결하는 것보다 구체적인 변경 사항이 적은 이유가 있습니다 (구체적인 인터페이스).

재사용 성 대 재사용

Martin과 다소 충돌하는 것을 제안 할 수 있다면 나 자신의 개인적인 종류의 메트릭은 가장 재사용 가능한 라이브러리가 최소한 다른 코드를 재사용하려고 노력해야한다는 생각입니다. 이는 불안정성을 0으로 향하게합니다. 변경해야 할 최소한의 이유가있는 실제적인 이유 때문에 가장 배포하기 쉬운 라이브러리를 장려합니다. 십여 개의 다른 라이브러리에 의존하는 범용 범용 라이브러리는 변경해야 할 이유가 많으며 배포하기 어려운 어색하게 번들 된 배포판이 있습니다. 여기서의 차이점은 필자의 경우 "변경 이유"는 라이브러리의 안정적인 버전을 출시하려고하는 라이브러리 중심의 관점에서 나오기 때문에 구현까지 확장된다는 것입니다. Martin은 구현을 매우 별도의 부분으로 할인 할 수 있습니다.

배포 관점에서 구현과 인터페이스는 함께 흐려져 사용자 의존성을 안정적이거나 불안정한 라이브러리로 만듭니다. 인터페이스 관점에서는 인터페이스 만 사용되며 연관된 구현 세부 사항은 완전히 분리되어 있습니다.