응집력과 커플 링의 차이점은 무엇입니까?
커플 링과 응집력은 어떻게 소프트웨어 설계를 좋거나 나쁘게 만들 수 있습니까?
이 둘의 차이점과 전반적인 코드 품질에 미치는 영향을 설명하는 몇 가지 예는 무엇입니까?
답변
응집력 은 클래스 (또는 모듈)가 할 수있는 일을 말합니다. 응집력이 낮 으면 클래스가 다양한 행동을 수행한다는 것을 의미합니다. 응집력이 높다는 것은 수업이해야 할 일, 즉 수업의 의도와 관련된 방법에만 집중한다는 것을 의미합니다.
낮은 응집력의 예 :
-------------------
| Staff |
-------------------
| checkEmail() |
| sendEmail() |
| emailValidate() |
| PrintLetter() |
-------------------
높은 응집력의 예 :
----------------------------
| Staff |
----------------------------
| -salary |
| -emailAddr |
----------------------------
| setSalary(newSalary) |
| getSalary() |
| setEmailAddr(newEmail) |
| getEmailAddr() |
----------------------------
관해서 결합 , 두 개의 클래스 / 모듈이 서로를 향해 얼마나 관련 또는 의존성을 의미한다. 낮은 결합 클래스의 경우 한 클래스에서 중요한 것을 변경하면 다른 클래스에 영향을 미치지 않아야합니다. 커플 링이 높으면 코드를 변경하고 유지하기가 어려워집니다. 클래스가 밀접하게 연결되어 있으므로 변경하려면 전체 시스템을 개선해야합니다.
좋은 소프트웨어 디자인은 높은 응집력 과 낮은 커플 링을 가지고 있습니다.
답변
응집력 은 모듈 내의 관계를 나타냅니다 .
커플 링 은 모듈 간의 관계 를 나타냅니다 .
응집력
- 응집력은 모듈 내의 관계를 나타냅니다.
- 응집력은 모듈의 상대적 기능 강도를 보여줍니다.
- 응집력은 구성 요소 / 모듈이 단일 것에 집중하는 정도 (품질)입니다.
- 설계하는 동안 시스템의 다른 모듈과의 상호 작용이 거의없는 단일 작업 (즉, 단일 사고)에 대한 응집력있는 구성 요소 / 모듈 포커스를 위해 노력해야합니다.
- 응집력은 기본적으로 가시성을 가진 패키지로 모든 멤버를 볼 수있는 클래스 등 데이터 숨기기의 자연스러운 확장입니다. 응집력은 인트라 – 모듈 개념입니다.
커플 링
- 커플 링은 모듈 간의 관계를 나타냅니다.
- 커플 링은 모듈 간의 상대적 의존성 / 상호 의존성을 보여줍니다.
- 커플 링은 구성 요소 / 모듈이 다른 모듈에 연결되는 정도입니다.
- 설계하는 동안 낮은 커플 링을 위해 노력해야합니다. 즉 모듈 간의 종속성이 적어야합니다.
- 개인 필드, 개인 메소드 및 비 공용 클래스를 작성하면 느슨한 결합이 제공됩니다.
- 커플 링은 모듈 간 개념입니다.
이 링크를 확인
답변
모듈 내에서의 높은 응집력 과 모듈 간의 낮은 결합 은 종종 OO 프로그래밍 언어의 고품질과 관련된 것으로 간주됩니다.
예를 들어, 각 Java 클래스의 코드는 내부 응집력이 높아야하지만 다른 Java 클래스의 코드에 가능한 한 느슨하게 연결되어 있어야합니다.
Meyer의 객체 지향 소프트웨어 구성 (제 2 판) 3 장 에서는 이러한 문제에 대해 자세히 설명합니다.
답변
응집력 은 소프트웨어 요소의 책임이 얼마나 관련되고 집중되어 있는지를 나타냅니다.
커플 링 은 소프트웨어 요소가 다른 요소에 얼마나 강력하게 연결되어 있는지를 나타냅니다.
소프트웨어 요소는 클래스, 패키지, 구성 요소, 서브 시스템 또는 시스템 일 수 있습니다. 시스템을 설계하면서 그리고이 소프트웨어 요소가하는 것이 좋습니다 높은 응집력 및 지원 낮은 커플 링을 .
응집력이 낮 으면 유지 보수, 이해 및 재사용이 어려운 모 놀리 식 클래스가 생성됩니다. 마찬가지로 High Coupling 은 밀접하게 결합 된 클래스를 생성하며 변경은 로컬이 아니고 변경이 어렵고 재사용이 감소하는 경향이 있습니다.
ConnectionPool
다음 요구 사항으로 일반적인 모니터 가능 을 설계하는 가상 시나리오를 취할 수 있습니다 . 간단한 클래스와 같이 너무 많이 보일 수도 ConnectionPool
있지만 기본적인 의도는 간단한 예제와 함께 낮은 결합 과 높은 응집력 을 나타내는 것이므로 도움이 될 것입니다.
- 연결 지원
- 연결을 해제하다
- 연결 대 사용 횟수에 대한 통계 얻기
- 연결 대 시간에 대한 통계 얻기
- 나중에 검색 할 수 있도록 연결 검색 및 릴리스 정보를 데이터베이스에 저장하십시오.
응집력 이 낮 으면ConnectionPool
이 모든 기능 / 책임을 아래처럼 단일 클래스에 강제로 채워 클래스를 설계 할 수 있습니다. 이 단일 클래스는 연결 관리를 담당하고 데이터베이스와 상호 작용하고 연결 통계를 유지 관리합니다.
로 높은 응집력 우리는 클래스에서 이러한 책임을 할당하고 더 유지 보수 및 재사용 할 수 있습니다.
낮은 커플 링 을 설명하기 위해 ConnectionPool
위 의 높은 응집력 다이어그램을 계속합니다 . 위의 다이어그램을 보면 높은 응집력을 지원하지만 클래스와 ConnectionPool
밀접하게 연결 되어 있으며 직접 상호 작용합니다. 대신 커플 링을 줄이기 위해 인터페이스를 도입 하고이 두 클래스가 인터페이스를 구현하고 클래스에 등록하도록 할 수 있습니다 . 그리고는 이 청취자를 반복 및 연결 GET 및 출시 이벤트를 통보하고 덜 커플 링을 허용합니다.ConnectionStatistics
PersistentStore
ConnectionListener
ConnectionPool
ConnectionPool
참고 / 단어 또는주의 : 이 간단한 시나리오에서는 과도하게 보일 수 있지만 응용 프로그램이 여러 타사 서비스와 상호 작용하여 트랜잭션을 완료해야하는 실시간 시나리오를 상상하는 경우 : 코드를 타사 서비스와 직접 연결 이는 타사 서비스의 변경으로 인해 여러 위치에서 코드가 변경 될 수 있음을 의미합니다. 대신 Facade
이러한 여러 서비스와 내부적으로 상호 작용하고 서비스의 모든 변경이 로컬에 Facade
적용 되고 타사와의 낮은 연결을 강제 할 수 있습니다. 서비스.
답변
응집력이 증가하고 커플 링이 감소하면 소프트웨어 디자인이 향상됩니다.
Cohesion은 기능을 분할하여 기능과 관련이있는 데이터와 간결하고 밀접한 관계를 유지하며, 분리는 기능 구현이 시스템의 나머지 부분과 분리되도록합니다.
디커플링을 사용하면 소프트웨어의 다른 부분에 영향을주지 않고 구현을 변경할 수 있습니다.
응집력 은 구현이 기능에 더 구체적이고 유지 관리가 더 쉬워 지도록합니다.
결합을 줄이고 응집력을 높이는 가장 효과적인 방법은 인터페이스에 의한 설계 입니다.
즉, 주요 기능 객체는 구현하는 인터페이스를 통해서만 서로 ‘알아야’합니다. 인터페이스의 구현은 자연스러운 결과로서 응집력을 도입합니다.
일부 시나리오에서는 현실적이지 않지만 작동하는 디자인 목표가되어야합니다.
예 (매우 스케치) :
public interface IStackoverFlowQuestion
void SetAnswered(IUserProfile user);
void VoteUp(IUserProfile user);
void VoteDown(IUserProfile user);
}
public class NormalQuestion implements IStackoverflowQuestion {
protected Integer vote_ = new Integer(0);
protected IUserProfile user_ = null;
protected IUserProfile answered_ = null;
public void VoteUp(IUserProfile user) {
vote_++;
// code to ... add to user profile
}
public void VoteDown(IUserProfile user) {
decrement and update profile
}
public SetAnswered(IUserProfile answer) {
answered_ = answer
// update u
}
}
public class CommunityWikiQuestion implements IStackoverflowQuestion {
public void VoteUp(IUserProfile user) { // do not update profile }
public void VoteDown(IUserProfile user) { // do not update profile }
public void SetAnswered(IUserProfile user) { // do not update profile }
}
코드베이스의 다른 곳에서는 질문에 관계없이 질문을 처리하는 모듈을 가질 수 있습니다.
public class OtherModuleProcessor {
public void Process(List<IStackoverflowQuestion> questions) {
... process each question.
}
}
답변
Cohesion에 대한 최고의 설명은 Bob 아저씨의 Clean Code에서 나옵니다
클래스에는 적은 수의 인스턴스 변수가 있어야합니다. 클래스의 각 메소드는 하나 이상의 해당 변수를 조작해야합니다. 일반적으로 메소드가 더 많은 변수를 조작할수록 해당 메소드가 클래스에 더 응집력이 있습니다. 각 메소드에서 각 변수를 사용하는 클래스는 최대한 응집력이 있습니다.
일반적으로 그러한 최대 응집력있는 클래스를 만드는 것은 바람직하지도 않습니다. 반면에 응집력을 높이고 싶습니다 . 응집력이 높으면 클래스의 메소드와 변수가 서로 의존적이며 논리적 전체로서 함께 매달려 있음을 의미합니다.
함수를 작게 유지하고 매개 변수 목록을 짧게 유지하는 전략으로 인해 일부 메소드가 사용하는 인스턴스 변수가 확산 될 수 있습니다. 이런 일이 발생하면 거의 항상 다른 클래스가 더 큰 클래스에서 벗어나려고한다는 것을 의미합니다. 변수와 메소드를 둘 이상의 클래스로 분리하여 새 클래스가 더 응집력이 있도록해야합니다.
답변
간단히 말해서 Cohesion 은 코드베이스의 일부가 논리적으로 단일 원자 단위를 형성하는 정도를 나타냅니다. 반면 커플 링 은 단일 유닛이 다른 유닛과 독립된 정도를 나타냅니다. 즉, 둘 이상의 장치 간 연결 수입니다. 숫자가 적을수록 커플 링이 낮아집니다.
본질적으로 높은 응집력은 서로 관련된 코드 기반의 일부를 한 곳에 유지하는 것을 의미합니다. 낮은 결합은 동시에 코드베이스의 관련되지 않은 부분을 가능한 많이 분리하는 것입니다.
응집력 및 결합 관점의 코드 유형 :
지침을 따르는 코드가 이상적 입니다. 느슨하게 결합되고 응집력이 있습니다. 이 그림으로 그러한 코드를 설명 할 수 있습니다.
God Object 는 높은 응집력과 높은 결합력을 도입 한 결과입니다. 안티 패턴이며 기본적으로 모든 작업을 한 번에 수행하는 단일 코드 조각을 나타냅니다. 다른 클래스 또는 모듈 사이의 경계가 잘못 선택 되면
잘못 선택 됩니다.
파괴적인 디커플링 이 가장 흥미로운 것입니다. 프로그래머가 코드베이스를 너무 많이 분리하여 코드가 완전히 초점을 잃을 때 종종 발생합니다.