'커플 링이 낮고 응집력이 높다'는 것은

진술을 이해하는 데 문제가 있습니다 low in coupling and high in cohesion . 나는 구글에 대해 이것에 대해 많이 읽었지만 여전히 이해하기 어렵다.

내가 이해하는 것은 High cohesion 하는 것은 특정 기능을 수행하는 데 특화된 클래스가 있어야한다는 것을 의미합니다. 이것이 맞기를 바랍니다. 신용 카드 만 검증하는 신용 ​​카드 검증 클래스와 같습니다.

그리고 여전히 낮은 커플 링이 무엇을 의미하는지 이해하지 못합니까?

내가 믿는 것은 이것입니다 :

응집력은 모듈 / 클래스의 요소가 서로 속하는 정도를 말하며, 관련 코드는 서로 가까이 있어야하므로 높은 응집력을 위해 노력하고 모든 관련 코드를 가능한 한 가깝게 묶어야합니다. 그것은 안에 있는 요소와 관련이 있습니다.모듈 / 클래스 있습니다.

커플 링은 서로 다른 모듈 / 클래스가 서로 의존하는 정도를 나타내며, 모든 모듈은 가능한 한 독립적이어야하므로 커플 링이 낮습니다. 다른 모듈 / 클래스 간의 요소와 관련이 있습니다.

전체 그림을 시각화하는 것이 도움이 될 것입니다.

스크린 샷은 Coursera 에서 가져 왔습니다 .

실제와 마찬가지로 소프트웨어 엔지니어링의 응집력 은 전체를 구성하는 요소 (우리의 경우 클래스를 말합시다)가 실제로 함께 속해 있다고 말할 수있는 정도입니다. 따라서 소프트웨어 모듈의 소스 코드로 표현 된 각 기능이 얼마나 밀접하게 관련되어 있는지를 측정 한 것입니다.

OO와 관련하여 응집력을 보는 한 가지 방법은 클래스의 메소드가 개인 속성을 사용하는 경우입니다.

토론은 이것보다 크지 만 응집력 은 높습니다 (또는 응집력이 가장 좋은 유형-기능적 응집력)은 모듈의 일부가 그룹화되어있을 때 모듈의 단일 정의 된 작업에 기여하기 때문입니다.

간단한 단어로의 결합 은 한 구성 요소가 (필수는 아니지만 클래스를 상상하지는 않지만) 다른 구성 요소의 내부 작동 또는 내부 요소에 대해 얼마나 많이 알고 있는지, 즉 다른 구성 요소에 대한 지식이 얼마나 많은지입니다.

느슨한 결합 은 시스템 또는 네트워크에서 구성 요소를 상호 연결하여 해당 구성 요소가 실제로 가능한 한 최소한으로 서로 종속되도록하는 방법입니다.

나는 이것에 관한 블로그 게시물을 썼다 . 예제 등을 통해이 모든 내용에 대해 자세히 설명합니다. 또한 이러한 원칙을 따라야하는 이유의 이점도 설명합니다.

소프트웨어 디자인에서 높은 응집력 은 클래스가 한 가지 일을 잘 수행해야 함을 의미합니다. 높은 응집력은 단일 책임 원칙 과 밀접한 관련이 있습니다.

낮은 커플 링 은 클래스가 가능한 최소한의 종속성을 가져야 함을 나타냅니다. 또한 존재해야하는 종속성은 약한 종속성이어야합니다. 구체적인 클래스에 대한 종속성보다는 인터페이스에 대한 종속성을 선호하거나 상속보다 컴포지션을 선호해야합니다.

높은 응집력과 낮은 결합은 유지하기 쉬운 더 나은 코드를 제공합니다.

짧고 명확한 답변

• 높은 응집력 : 하나의 클래스 / 모듈 내의 요소는 기능적으로 함께 속해야하며 하나의 특정 작업을 수행해야합니다.
• 느슨한 결합 : 서로 다른 클래스 / 모듈 중에서 최소한의 종속성이 있어야합니다.

낮은 커플 링은 두 개 또는 많은 모듈과 관련이 있습니다. 한 모듈의 변경으로 인해 다른 모듈에서 많은 변경이 발생하면 서로 관련이 있다고합니다. 인터페이스 기반 프로그래밍이 도움이됩니다. 모듈 간의 인터페이스 (상호 작용 평균)가 변경되지 않았으므로 모듈 내의 변경 사항은 다른 모듈에 영향을 미치지 않습니다.

높은 응집력-비슷한 것들을 함께 모으십시오. 따라서 클래스에는 관련 작업을 수행하는 메소드 또는 동작이 있어야합니다. 과장된 나쁜 예를 들기 위해 : List 인터페이스의 구현에는 String과 관련된 작업이 없어야합니다. String 클래스는 String과 관련된 메소드와 필드를 가져야하며 마찬가지로 List 구현에는 해당하는 것이 있어야합니다.

희망이 도움이됩니다.

이해하기 쉬운 긴 이야기 짧고 낮은 커플 링은 시스템의 올바른 기능에 영향을 미치지 않고 구성 요소를 교체 할 수 있음을 의미했습니다. 기본적으로 시스템을 손상시키지 않고 개별적으로 업데이트 할 수있는 기능적인 구성 요소로 시스템을 변조

스마트 폰 있어요? 하나의 큰 앱이나 많은 작은 앱이 있습니까? 한 앱이 다른 앱에 응답합니까? 다른 앱을 설치, 업데이트 및 / 또는 제거하는 동안 하나의 앱을 사용할 수 있습니까? 각 앱이 자체 포함되어 있다는 것은 높은 응집력입니다. 각 앱이 다른 앱과 독립적이라는 것은 낮은 커플 링입니다. DevOps는이 아키텍처를 선호합니다. 즉, 시스템 전체를 중단시키지 않고 개별 연속 배포를 수행 할 수 있기 때문입니다.

상속 또는 일반화는 높은 커플 링 (즉, 높은 상호 의존성)의 예입니다. 내가 의미하는 것은 상속에서 종종 부모 클래스가 자식 클래스가 사용하는 기본 기능을 정의하고 부모 클래스의 메소드 변경이 자식 클래스에 직접 영향을 미친다는 것입니다. 따라서 우리는 클래스 사이에 더 큰 상호 의존성이 있다고 말할 수 있습니다.

인터페이스의 실현 또는 사용은 높은 응집력 (예 : 낮은 상호 의존성)의 예입니다. 이것이 의미하는 것은 인터페이스가 그것을 구현하는 모든 클래스에 대한 계약을 제시하지만 각 클래스는 인터페이스에서 선언 된 메소드를 자체 방식으로 구현할 권리가 있으며 한 클래스에서 선언 된 메소드의 변경은 다른 클래스에 영향을 미치지 않는다는 것입니다.

응집력 -모든 것이 서로 밀접하게 관련되어 있습니다.
커플 링 -모든 것이 서로 연결되는 방법.

예를 들어 봅시다-우리는 자율 주행 자동차를 설계하고 싶습니다.

(1) 모터가 제대로 작동해야합니다.

(2) 우리는 스스로 운전할 차가 필요하다.

(1) 모터를 시동하고 함께 작동시키는 모든 클래스와 기능은 함께 작동하지만 차량 조향에는 도움이되지 않습니다. 따라서 이러한 클래스를 엔진 컨트롤러 뒤에 배치합니다.

(2)의 모든 클래스와 기능은 자동차가 조향, 가속 및 제동되도록 훌륭하게 작동합니다. 그들은 자동차가 피스톤을 시작하거나 휘발유를 보내도록 도와주지 않습니다. 그래서 우리는이 클래스들을 고유 한 Driving Controller 뒤에 배치합니다.

이 컨트롤러는 사용 가능한 모든 클래스 및 기능과 통신하는 데 사용됩니다. 그런 다음 컨트롤러는 서로 통신합니다. 이것은 자동차 페달 속도를 높이기 위해 가스 페달 클래스에서 피스톤 클래스의 기능을 호출 할 수 없다는 것을 의미합니다.

페달 클래스는 구동 컨트롤러에게 엔진 컨트롤러와 통신하도록 요청한 다음 피스톤 클래스에 더 빨리 가도록 지시합니다. 이를 통해 프로그래머는 문제를 찾을 수 있고 걱정없이 큰 프로그램을 결합 할 수 있습니다. 코드가 컨트롤러 뒤에서 모두 작동했기 때문입니다.

낮은 커플 링과 높은 응집력은 권장되는 현상입니다.

커플 링은 다양한 모듈이 어느 정도 상호 의존적이며 다른 모듈이 모듈의 일부 / 상당한 기능 변경에 어떤 영향을 미치는지를 의미합니다. 의존성이 낮게 유지되어야하므로 다른 커플 링에 대해 최소한의 / 최소한의 변경이 이루어 지므로 낮은 결합이 강조된다.

예가 도움이 될 수 있습니다. 데이터를 생성하여 디스크 나 데이터베이스의 파일 인 데이터 저장소에 넣는 시스템을 상상해보십시오.

데이터 저장소 코드와 데이터 생산 코드를 분리하여 높은 응집력을 달성 할 수 있습니다. (실제로 데이터베이스 스토리지에서 디스크 스토리지를 분리).

데이터 생산에 데이터 저장소에 대한 불필요한 지식이 없는지 확인하여 낮은 커플 링을 달성 할 수 있습니다 (예 : 데이터 저장소에 파일 이름 또는 db 연결에 대해 요청하지 않음).

다음은 약간의 추상 그래프 이론 각도의 대답입니다.

상태 저장 객체 사이의 (지시 된) 의존성 그래프 만보고 문제를 단순화합시다.

종속성 그래프의 두 가지 제한 사례 를 고려하여 매우 간단한 답변을 설명 할 수 있습니다 .

첫 번째 제한 사례 : 클러스터 그래프 .

클러스터 그래프는 높은 응집력과 낮은 결합 (클러스터 크기 세트가 제공됨) 종속성 그래프를 가장 완벽하게 구현합니다.

클러스터 간 종속성은 최대 (완전히 연결됨)이며 클러스터 간 종속성은 최소 (0)입니다.

이것은 제한 사례 중 하나의 답을 추상 적으로 보여줍니다 .

두 번째 제한 사례 는 모든 것이 모든 것에 의존하는 완전히 연결된 그래프입니다.

현실은 저의 어딘가에 있으며, 클러스터 그래프에 가까울수록 나의 겸손한 이해가 더 좋습니다.

다른 관점에서 : 지향성 종속성 그래프 를 볼 때 이상적으로는 비순환이어야합니다. 그렇지 않으면 가장 작은 군집 / 구성 요소를 순환합니다.

계층에서 한 단계 위 / 아래로 소프트웨어에서 느슨한 결합, 긴밀한 응집력의 "한 인스턴스"에 해당하지만이 느슨한 결합 / 긴밀한 응집성 원리를 비 주기적 방향 그래프의 다른 깊이에서 반복되는 현상으로 볼 수 있습니다. 스패닝 트리 중 하나).

시스템을 계층 구조로 분해하면 지수 복잡성을 극복 할 수 있습니다 (각 클러스터에 10 개의 요소가 있음). 그런 다음 6 층에서 이미 백만 개의 객체입니다.

10 개의 클러스터는 1 개의 슈퍼 클러스터를 형성하고 10 개의 슈퍼 클러스터는 1 개의 하이퍼 클러스터를 형성합니다.

따라서 이것은 이야기의 진정한 중요성 일 수 있으며 단지 두 층 내에서의 높은 응집력의 낮은 결합력 만이 아닙니다. 더 높은 수준의 추상화와 상호 작용을 고려할 때 진정한 중요성이 분명해집니다.

나는 당신이 너무 많은 정의를 가지고 있다고 생각하지만 여전히 의심 스럽거나 프로그래밍에 익숙하지 않은 경우이 비디오에 대해 자세히 알고 싶다면 https://youtu.be/HpJTGW9AwX0 다형성에 대한 더 많은 정보를 얻을 수있는 참고 자료 일뿐입니다.

낮은 커플 링 :-매우 간단하게 유지합니다. 모듈을 변경하면 다른 모듈에 어떤 영향을 미칩니 까?

예 :-서비스 API가 JAR로 노출 된 경우 메소드 서명을 변경하면 API 호출 (고 / 고 결합)이 중단됩니다.

모듈과 다른 모듈이 비동기 메시지를 통해 통신하는 경우 메시지를받는 한, 메소드 변경 서명은 모듈에 로컬입니다 (낮은 커플 링).

메시지 형식에 변화가있을 경우, 외출 클라이언트는 약간의 변경이 필요합니다.