2nd/10_Wiki/Topics/DevOps_and_Security/응집도 (Cohesion).md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-응집도-cohesion	응집도 (Cohesion)	10_Wiki/Topics	verified	self	Cohesion 응집도 Module Cohesion	none	A	0.9	applied	software-design modularity srp		2026-05-10	pending	language framework any any

응집도 (Cohesion)

매 한 줄

"매 한 module, 매 한 reason to change". 매 module 내부 element 가 매 single purpose 의 향해 의 얼마나 의 tightly 의 related 의 measure. 매 Larry Constantine (1974) 의 7-level taxonomy. 매 SOLID 의 SRP 의 conceptual ancestor.

매 핵심

매 7 levels of cohesion (low → high)

Level	매 의미	예
Coincidental	매 unrelated	Util.java kitchen sink
Logical	매 same category	IOHandler (file + net + console)
Temporal	매 same time	init() 의 mixed setup
Procedural	매 same flow	step1 → step2 → step3
Communicational	매 same data	report 의 multiple formatting
Sequential	매 output → input	parse → validate → transform
Functional	매 single task	calculateTax(invoice)

매 Functional cohesion (target)

• 매 module 의 모든 element 의 한 well-defined task 의 contribute.
• 매 reusable, testable, maintainable.
• 매 SRP 의 satisfied.

매 측정 (informal)

• 매 module 의 description 의 "and" / "or" 의 포함? → 매 likely low cohesion.
• 매 reason to change 의 한 가지? → 매 high cohesion.
• 매 LCOM (Lack of Cohesion of Methods) — Chidamber-Kemerer metric.

💻 패턴

매 Functional cohesion (best)

class TaxCalculator:
    def calculate(self, amount: Decimal, jurisdiction: str) -> Decimal:
        rate = self._lookup_rate(jurisdiction)
        return amount * rate

매 Coincidental → split

# Before — 매 coincidental
class Utils:
    def format_phone(p): ...
    def calculate_tax(a): ...
    def send_email(e): ...

# After — 매 functional
class PhoneFormatter: ...
class TaxCalculator: ...
class EmailSender: ...

매 Temporal → procedural / functional

# Before — 매 temporal "everything at startup"
def init():
    connect_db()
    load_config()
    warm_cache()
    start_metrics()

# After — 매 explicit phases
class Bootstrap:
    def configure(self): load_config()
    def connect(self): connect_db()
    def warm(self): warm_cache()
    def observe(self): start_metrics()

매 Logical → polymorphism

# Before — 매 logical "all I/O"
class IOHandler:
    def read_file(self, p): ...
    def read_socket(self, s): ...
    def read_stdin(self): ...

# After — 매 functional via interface
class Reader(Protocol):
    def read(self) -> bytes: ...

class FileReader(Reader): ...
class SocketReader(Reader): ...
class StdinReader(Reader): ...

매 LCOM 측정 (Java)

// 매 ckjm tool / SonarQube 의 LCOM4 metric
// LCOM4 = 1 → 매 perfectly cohesive
// LCOM4 > 1 → 매 split candidates

매 Communicational cohesion 예

class InvoiceReport:
    def __init__(self, invoice: Invoice):
        self.invoice = invoice  # 매 shared data

    def to_pdf(self): ...
    def to_csv(self): ...
    def to_json(self): ...

매 결정 기준

상황	Approach
매 class 의 method 의 의 unrelated	매 Split into multiple classes
매 method 의 의 multiple responsibilities	매 Extract method, then class
매 utility class 의 grow	매 Domain-specific helper 의 의 split
매 god class 의 LCOM 의 high	매 Refactor by responsibility

기본값: 매 functional cohesion 의 추구. 매 SRP — 매 한 class, 매 한 reason to change.

🔗 Graph

• 부모: 응집도와 결합도 (Cohesion and Coupling)
• 응용: SOLID · Single Responsibility Principle (SRP)
• Adjacent: 결합도

🤖 LLM 활용

언제: 매 class / module 의 design review. 매 god class refactoring 의 priority. 언제 X: 매 trivial DTO / value object — 매 cohesion 의 의 trivially high.

❌ 안티패턴

• God class: 매 매 모든 의 처리 → 매 lowest cohesion.
• Utility dumping ground: 매 Helpers, Common, Misc 의 class.
• Manager class: 매 XxxManager 의 vague responsibility.
• Feature envy: 매 method 의 다른 class 의 data 의 access — 매 wrong class 의 의 belong.

🧪 검증 / 중복

• Verified — Constantine & Yourdon, Structured Design (1979); Robert C. Martin, Clean Architecture.
• 신뢰도 A.

🕓 Changelog

날짜	변경
2026-05-08	Phase 1
2026-05-10	Manual cleanup — 7 cohesion levels + refactor recipes