13장 컴포넌트 응집도

13장 컴포넌트 응집도

태그

비어 있음

날짜

2024년 5월 8일

어느 클래스를 어느 컴포넌트에 포함 시켜야 할까? 소프트웨어 엔지니어링 원칙의 도움을 받아보자 컴포넌트 응집도와 관련된 세 가지 원칙

🏁 REP: 재사용/릴리스 등가 원칙

재사용 단위는 릴리스 단위와 같다.

릴리스 절차를 통해 추적해서 관리되지 않는다면 컴포넌트를 재사용 할 수 없을 것이다.

⇒ 컴포넌트가 서로 호응되는지 보증할 방법이 없다.

새로운 버전이 언제 출시되고 무엇이 변했는지를 소프트웨어 개발자들이 알아야한다.

적절한 공지와 문서도 작성되어야 함

💡

소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다.

다음에 나오는 원칙 CCP,CRP는 이원칙에 제약을 가하는 측면에서 정의한다.

🏁 CCP: 공통 폐쇄 원칙

동일한 시점에 동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라. 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라.

단일 책임 원칙을 컴포넌트 관점에서 쓴 것

컴포넌트 수준의 SRP

→ 단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안 된다.

여러 컴포넌트에서 변경 < 단일 컴포넌트에서 변경

CCP는 같은 이유로 변경될 가능성이 있는 클래스는 모두 한 곳으로 묶을 것을 권한다.

이를 통해 소프트웨어 릴리즈, 재검증, 배포하는 일의 작업량을 최소화 할 수 있다.

개방 폐쇄 원칙(OCP)과도 밀접한 관련이 있다. closure

CCP에서는 동일한 유형의 변경에 대해

닫혀 있는 클래스들을 하나의 컴포넌트로 묶음으로써 OCP의 교훈을 확대 적용한다.

요구사항 발생 → 변경을 받는 컴포넌트 최소한으로 한정

🏁 CRP: 공통 재사용 원칙

컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라.

CRP는 같이 재사용되는 클래스들을 같은 컴포넌트에 포함해야 한다고 말한다.

상호작용하는 클래스와 모듈들은 동일한 컴포넌트에 포함되어야 한다.

수많은 의존성이 있을 것이다.

⇒ CRP는 각 컴포넌트에 어떤 클래스를 포함시켜야 하는지를 설명한다.

⇒ CRP는 동일한 컴포넌트로 묶어서는 안되는 클래스를 말해준다.

컴포넌트A가 다른 컴포넌트B의 한 클래스만 의존한다고 의존성이 약해지는 것은 아니다. 이것을 인지하지 않으면 많은 컴포넌트를 재배포하게 될 수 있다.

강하게 결합이 되지 않은 클래스를 동일한 컴포넌트에 위치시키면 안됨.

“한 컴포넌트에 속한 클래스들은 더 작게 그룹지을 수 없다.” → 이해가 잘 안됨

gpt : 한 컴포넌트 내의 클래스들이 그 자체로 최소한의 의존성을 가지고 최대한 재사용 가능하게 설계되어야 한다는 의미입니다. 다시 말해, 이들 클래스는 그룹을 더 세분화할 필요 없이, 컴포넌트로서의 역할을 충분히 수행할 수 있어야 합니다.

⇒ 최소한의 의존성을 가진 것들끼리 원자성을 띄게 그룹지어야함!

CRP ⊂ ISP

사용하지 않은 메서드가 있는 클래스에 의존하지 말라고 조언

사용하지 않는 클래스를 가진 컴포넌트에 의존하지 말라고 조언

🏁 컴포넌트 응집도에 대한 균형 다이어그램

REP와 CCP는 포함 원칙, CRP는 배제 원칙

균형을 이룰 수 있게 해야 한다.

프로젝트 초기에는 CCP>REP → 개발 가능성 > 재사용성

프로젝트 진행에 따라 “왼쪽 ←오른쪽” 이동한다.

즉, 프로젝트의 컴포넌트 구조는 시간과 성숙도에 따라 변한다.

프로젝트가 발전되고 사용되는 방법과 관련이 깊다.

🏁 결론

어느 클래스들을 묶어서 컴포넌트로 만들지를 결정할 때, 재사용성과 개발가능성이라는 상충하는 힘을 반드시 고려해야 한다.

균형점은 유동적이다. 시간이 흐름에 따라 프로젝트의 초점이 개발가능성에서 재사용성으로 바뀌고 그에 따라 컴포넌트를 구성하는 방식도 조금씩 흐트러지고 또 진화한다.

링크

Cohesion and Coupling in Software Engineering - ArtOfTesting

Coupling and Cohesion arе two kеy concepts in software engineering that arе usеd to measure thе quality of a software systеm’s dеsign.  Coupling is defined as the degree of interdеpеndеncе and connection between modules within a software system.  Cohеsion rеfеr to thе degree to which elements within a module work togеthеr to perform a single, wеll-dеfinеd purpose.   Both cohеsion and coupling rеfеr to

https://artoftesting.com/cohesion-and-coupling-in-software-engineering

Principles of Component Cohesion | DevLead.io

Design components to enable a change to one component without the need to redeploy any of the others.  These principles provide guidance on which classes are best grouped together within a component and which ones should be separated to facilitate independent deployability.  Component partitioning will likely change as the quality model matures and expectations shift from adaptability toward reuse.

https://devlead.azurewebsites.net/DevTips/PrinciplesOfComponentCohesion

결합도와 응집도는 무엇일까?

낮은 결합도(Coupling)와 높은 응집도(Cohesion)를 갖도록 설계해야 하는 이유는 무엇일까?

https://madplay.github.io/post/coupling-and-cohesion-in-software-engineering#google_vignette

Software Engineering | Coupling and Cohesion - Scaler Topics

Explore cohesion and coupling in software engineering Design quality insights. Learn to balance code relationships for efficient, maintainable systems on Scaler Topics.

https://www.scaler.com/topics/cohesion-and-coupling-in-software-engineering/

Coupling and Cohesion - Software Engineering - GeeksforGeeks

A Computer Science portal for geeks. It contains well written, well thought and well explained computer science and programming articles, quizzes and practice/competitive programming/company interview Questions.

https://www.geeksforgeeks.org/software-engineering-coupling-and-cohesion/

표