개정 비교

컴포지션

선택한 두 보관본의 본문 변경입니다. 코드는 실행하지 않습니다.

비교 전 원문: 2026-06-08 13:50:10 UTC 비교 후 원문: 2026-06-08 14:04:23 UTC

변경 구간 23개

− 삭제+ 추가변경 없는 본문 127개는 생략했습니다.

본문 블록 없음 → 19

(내용 없음)

개인 메모: 인터페이스 기반 컴포지션이라는 건 흔히 현장에선 꽤 쓰이지만 실제 학술적 용어는 없고, 다형적 위임이나 인터페이스를 통한 위임으로 쓴다.

본문 블록 없음 → 55

(내용 없음)

개인 메모: 한국 쇼핑몰들 절대다수가 정가를 고가로 책정한 후, 쿠폰을 통해서 싸게 보이는 착시를 유지하는데, 실제 옷 도매상 원가를 생각하면 얼마나 마진이 남는지 모른다. 어쨌건 이런 쿠폰을 통한 앵커링 효과가 고객들에게 호의를 사는데 효과적일진 몰라도 그걸 작성해야하는 프로그래머에게는 분노를 사는데 효과적이다

본문 블록 80 → 82

컴포지션의 힘은 변화 축이 둘 이상일 때 더 잘 ~~보인다~~.

컴포지션의 힘은 변화 축이 둘 이상일 때 효과를 보기가 좋다.

본문 블록 84 → 86

Law of Demeter는 "낯선 객체와 너무 깊게 대화하지 말라"는 식으로 요약된다. Lieberherr와 Holland의 1989년 논문 Assuring Good Style for Object-Oriented Programs에서 정리된 원칙이다.~~6(#ref-~~6)

Law of Demeter는 "낯선 객체와 너무 깊게 대화하지 말라"는 식으로 요약된다. Lieberherr와 Holland의 1989년 논문 Assuring Good Style for Object-Oriented Programs에서 정리된 원칙이다.[각주 6]

본문 블록 89 → 91-92

컴포지션은 "내가 직접 내부를 뒤지지 않고, 가까운 협력 객체에게 일을 맡긴다"는 점에서 Law of Demeter와 연결된다. 하지만 자동으로 좋은 설계가 되는 것은 아니다. 객체를 너무 잘게 쪼개면 오히려 위임 홉이 늘고, a.GetB().GetC().Do() 같은 train-wreck이 생길 수 있다.

컴포지션은 "내가 직접 내부를 뒤지지 않고, 가까운 협력 객체에게 일을 맡긴다"는 점에서 Law of Demeter와 연결된다. 하지만 이것이 자동으로 좋은 설계가 되는 것은 아니다. 객체를 너무 잘게 쪼개면 오히려 위임 홉이 늘고, a.GetB().GetC().Do() 같은 train-wreck이 생길 수 있다.

본문 블록 92 → 95

다음 질문에 "예"가 많으면 컴포지션을 먼저 본다.

다음 질문에 "예"가 많으면 컴포지션을 먼저 고려해본다.

본문 블록 94 → 97-99

특히 다음 이름이 보이면 컴포지션 ~~후보가~~ ~~많다.~~ 다만 이름은 근거가 아니라 냄새다. Policy라는 이름을 붙였다고 자동으로 분리할 가치가 생기지는 않는다.

특히 다음 이름이 보이면 컴포지션 후보로 할 근거가 충분하다. 다만 이름은 근거가 아니라 냄새다. 프로그래머 감각이라고 해야하나. 작업해서 겪는 상황 그 자체들이 쌓여서 코드 냄새가 된다. Policy라는 이름을 붙였다고 자동으로 분리할 가치가 생기지는 않는다.

본문 블록 101-103 → 106-109

개인 메모: 상속은 가끔 "공짜 재사용"처럼 보이는데, 실제로는 부모 클래스의 인생사까지 물려받는 경우가 많다. 부모가 빚을 ~~졌으면~~ ~~자식도~~ 같이 ~~갚는다~~. 상속만 ~~자연스럽게~~ 주는 것: open recursion 상속이 컴포지션보다 자연스러운 대표 지점은 open recursion이다. 부모 메서드가 this.SomeStep()을 호출했을 때, 실제 런타임 타입의 override로 디스패치되는 성질이다. Cook, Hill, Canning의 Inheritance Is Not Subtyping도 상속과 서브타이핑을 구분해 다룬다.~~12(#ref-12)~~

개인 메모: 상속은 가끔 "공짜 재사용"처럼 보이는데, 실제로는 부모 클래스의 인생사까지 물려받는 경우가 많다. 부모가 돈이 많다면 자식이 기꺼이 물려받겠지만, 가난할 경우 그 부모를 벗어나고 싶듯이, 상속도 좋은 부모한테 물려받을 게 있을때만 받는 것이 좋다. 상속만 쓰는게 자연스러운 것: open recursion 상속이 컴포지션보다 자연스러운 대표 지점은 open recursion이다. 부모 메서드가 this.SomeStep()을 호출했을 때, 실제 런타임 타입의 override로 디스패치되는 성질이다. Cook, Hill, Canning의 Inheritance Is Not Subtyping도 상속과 서브타이핑을 구분해 다룬다.[각주 7]

본문 블록 109 → 115

컴포지션도 ~~공짜가~~ ~~아니다~~. 상속의 문제를 없애는 것이 아니라, 복잡성을 다른 위치로 ~~옮기는~~ ~~경우가~~ 많다.

컴포지션도 제약이 많다. 상속의 문제를 없애는 것이 아니라, 복잡성을 다른 위치로 옮긴다. 대신 그게 프로그래머의 눈에 한 눈에 보이지 않는 곳으로 옮길뿐.

본문 블록 114-115 → 120-121

객체지향 프로그램은 객체와 포인터에 많이 의존하기 때문에 cache/TLB miss에 취약할 수 있다는 연구도 있다.~~8(#ref-8)~~ 포인터 기반 자료구조의 locality를 개선하려는 연구가 따로 있는 것도 같은 이유다.~~9(#ref-~~9) 그래서 게임 엔진, 시뮬레이션, 고성능 금융 시스템처럼 많은 데이터를 매 프레임/매 틱 순회하는 영역에서는 객체지향 컴포지션보다 데이터 지향 프로그래밍이나 ECS(Entity Component System)가 더 맞을 수 있다.~~10(#ref-~~10)

객체지향 프로그램은 객체와 포인터에 많이 의존하기 때문에 cache/TLB miss에 취약할 수 있다는 연구도 있다.[각주 8]포인터 기반 자료구조의 locality를 개선하려는 연구가 따로 있는 것도 같은 이유다.[각주 9] 그래서 게임 엔진, 시뮬레이션, 고성능 금융 시스템처럼 많은 데이터를 매 프레임/매 틱 순회하는 영역에서는 객체지향 컴포지션보다 데이터 지향 프로그래밍이나 ECS(Entity Component System)가 더 맞을 수 있다.[각주 10]

본문 블록 120 → 126-127

즉 컴포지션은 설계 유연성을 ~~산다.~~ 대신 데이터 locality를 팔 수 있다. 이 비용은 웹 CRUD에서는 거의 안 보이지만, 내부 루프에서는 바로 보인다.

즉 컴포지션은 설계 유연성을 얻지만, 대신 데이터 locality를 팔 수 있다. 이 비용은 웹 CRUD에서는 거의 안 보이지만, 내부 루프에서는 바로 보인다. 개인 메모: 프로그래밍의 핵심은 결국 트레이드 오프다. 프로그래머가 보기 좋으면 기계가 불편해 하는 경우가 많고, 반대도 비슷하다.

본문 블록 126 → 133-134

이건 설계 원칙을 모르는 것이 ~~아니다.~~ 아직 모르는 변경 축에 돈을 쓰지 않는 것이다.

이건 설계 원칙을 모르는 것이 아니고, 아직 모르는 변경 축에 돈을 쓰지 않는 것이다. 개인 메모: 스타트 업 프로그래머는 단순하고 빠르게 MVP로 하드코딩 해도 된다. 하지만 규모를 키우거나 나같이 여러곳에 납품해야하는 프로그래머일 수록 템플릿화와 추상화 해야한다.

본문 블록 130 → 138

작은 객체가 많아지면 테스트는 쉬워질 수 있지만, 실제 런타임에 어떤 구현체가 들어왔는지 추적하기는 어려워진다. 특히 DI 설정이 여러 모듈에 흩어져 있으면 코드를 읽는 사람은 "이 인터페이스의 실제 구현이 뭐지?"부터 찾아야 한다.

작은 객체가 많아지면 테스트는 쉬워질 수 있지만, 실제 런타임에 어떤 구현체가 들어왔는지 추적하기는 어려워진다. 특히 DI 설정이 여러 모듈에 흩어져 있으면 코드를 읽는 사람은 "이 인터페이스의 실제 구현이 뭐지?"부터 찾아야 한다. 너무 잘게 쪼개면 '샷건 수술'이라는 안티 패턴에 빠질 수 있다.

본문 블록 135 → 143

order.Customer.Name이 항상 나쁜 것은 아니다. 문제는 외부 코드가 order.Customer.Wallet.CreditCard.Provider.RetryPolicy처럼 깊은 내부 구조와 정책 결정까지 알아야 하는 경우다. 단순 조회까지 전부 감추려고 하면 wrapper 메서드 폭발이 생긴다.

order.Customer.Name이 항상 나쁜 게 아니다. 문제는 외부 코드가 order.Customer.Wallet.CreditCard.Provider.RetryPolicy처럼 깊은 내부 구조와 정책 결정까지 알아야 하는 경우다. 단순 조회까지 전부 감추려고 하면 wrapper 메서드 폭발이 생긴다.

본문 블록 137 → 145

프레임워크가 특정 base class의 hook method를 요구하면 상속이 현실적인 답일 수 있다. UI 프레임워크, 게임 엔진, 테스트 프레임워크, ORM 일부 확장점은 "이 메서드를 override하라"는 계약으로 만들어져 있다.

프레임워크가 특정 base class의 hook method를 요구하면 상속이 현실적인 답일 수 있다. UI 프레임워크, 게임 엔진, 테스트 프레임워크, ORM 일부 확장점은 "이 메서드를 override하라"는 계약으로 만들어져 있다. 특히 C#에서 자주 쓰이는 대표적 게임 엔진인 Unity가 그렇다.

본문 블록 141 → 149

내가 컴포지션을 판단할 때 쓰는 기준은 이렇다.

내가 컴포지션을 판단할 때 쓰는 기준은 보통은 이렇다.

본문 블록 143-144 → 151-152

~~한 줄로 줄이면:~~ 상속은 "정체성"을 표현할 때 조심해서 쓰고, 컴포지션은 "역할"과 "정책"을 조립할 때 먼저 고려한다. 다만 핫 루프와 초기 제품에서는 유연성보다 단순함과 데이터 locality가 먼저일 수 있다.

요약하자면 상속은 "정체성"을 표현할 때 조심해서 쓰고, 컴포지션은 "역할"과 "정책"을 조립할 때 먼저 고려한다. 다만 핫 루프와 초기 제품에서는 유연성보다 단순함과 데이터 locality가 먼저일 수 있다.

본문 블록 147-161 → 없음

참고문헌 [1] Alan Snyder. "Encapsulation and Inheritance in Object-Oriented Programming Languages". OOPSLA 1986. DOI: 10.1145/28697.28702. 상속이 캡슐화의 장점을 약화할 수 있다는 초기 논의. [2] Barbara Liskov; Jeannette Wing. "A Behavioral Notion of Subtyping". ACM Transactions on Programming Languages and Systems, 16(6), 1811-1841, 1994. DOI: 10.1145/197320.197383. [3] Antero Taivalsaari. "On the Notion of Inheritance". ACM Computing Surveys, 28(3), 438-479, 1996. DOI: 10.1145/243439.243441. [4] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. 온라인 서지: InformIT [5] Joshua Bloch. Effective Java, 3rd edition. Addison-Wesley, 2018. Item 18: "Favor composition over inheritance." [6] Karl J. Lieberherr; Ian M. Holland. "Assuring Good Style for Object-Oriented Programs." IEEE Software, 1989. 참고: Law of Demeter bibliography, Law of Demeter: Principle of Least Knowledge [7] Ralph E. Johnson; Brian Foote. "Designing Reusable Classes". Journal of Object-Oriented Programming, 1(2), 22-35, 1988. 재사용 가능한 클래스 설계와 프레임워크 논의. [8] Martin Hirzel et al. "Data layouts for object-oriented programs". SIGMETRICS 2007. 객체지향 프로그램의 객체/포인터 의존성과 cache/TLB miss 문제를 다룬 연구. [9] Trishul M. Chilimbi; Mark D. Hill; James R. Larus. "Making Pointer-Based Data Structures Cache Conscious". IEEE Computer, 33, 67-74, 2000. 포인터 기반 구조의 locality 개선 논의. [10] Shawn M. Harris. "Implementation and Analysis of the Entity Component System Architecture". California Polytechnic State University, 2022. ECS를 데이터 지향 컴포지션 패턴으로 보고 객체지향 구조와 성능을 비교한 석사 논문. [11] Ulrich Drepper. "What Every Programmer Should Know About Memory". 2007. CPU cache, locality, memory hierarchy를 이해하기 위한 고전적 참고 자료. [12] William R. Cook; Walter L. Hill; Peter S. Canning. "Inheritance Is Not Subtyping". POPL 1990. DOI: 10.1145/96709.96721. 상속과 서브타이핑을 같은 것으로 보면 안 된다는 고전적 논의. [horizontalRule] 분류: 프로그래밍 패턴 | 객체지향_프로그래밍 | 디자인 패턴 | WIKI

(내용 없음)

각주 6

(내용 없음)

Karl J. Lieberherr; Ian M. Holland. "Assuring Good Style for Object-Oriented Programs." IEEE Software, 1989. 참고: [Law of Demeter bibliography](https://www2.ccs.neu.edu/research/demeter/biblio/LoD.html), [Law of Demeter: Principle of Least Knowledge](https://khoury.northeastern.edu/home/lieber/LoD.html)

각주 7

(내용 없음)

William R. Cook; Walter L. Hill; Peter S. Canning. ["Inheritance Is Not Subtyping"](https://www.cs.utexas.edu/~wcook/papers/InheritanceSubtyping90/CookPOPL90.pdf). POPL 1990. DOI: [10.1145/96709.96721](https://doi.org/10.1145/96709.96721). 상속과 서브타이핑을 같은 것으로 보면 안 된다는 고전적 논의.

각주 8

(내용 없음)

Martin Hirzel et al. ["Data layouts for object-oriented programs"](https://research.ibm.com/publications/data-layouts-for-object-oriented-programs). SIGMETRICS 2007. 객체지향 프로그램의 객체/포인터 의존성과 cache/TLB miss 문제를 다룬 연구.

각주 9

(내용 없음)

Trishul M. Chilimbi; Mark D. Hill; James R. Larus. ["Making Pointer-Based Data Structures Cache Conscious"](https://www.microsoft.com/en-us/research/publication/making-pointer-based-data-structures-cache-conscious/). IEEE Computer, 33, 67-74, 2000. 포인터 기반 구조의 locality 개선 논의.

각주 10

(내용 없음)

Shawn M. Harris. ["Implementation and Analysis of the Entity Component System Architecture"](https://digitalcommons.calpoly.edu/theses/2389/). California Polytechnic State University, 2022. ECS를 데이터 지향 컴포지션 패턴으로 보고 객체지향 구조와 성능을 비교한 석사 논문.

컴포지션

선택한 두 보관본의 본문 변경입니다. 코드는 실행하지 않습니다.

변경 구간 23개

− 삭제+ 추가변경 없는 본문 127개는 생략했습니다.

본문 블록 없음 → 19

(내용 없음)

본문 블록 없음 → 55

(내용 없음)

본문 블록 80 → 82

컴포지션의 힘은 변화 축이 둘 이상일 때 더 잘 ~~보인다~~.

컴포지션의 힘은 변화 축이 둘 이상일 때 효과를 보기가 좋다.

본문 블록 84 → 86

본문 블록 89 → 91-92

본문 블록 92 → 95

다음 질문에 "예"가 많으면 컴포지션을 먼저 본다.

다음 질문에 "예"가 많으면 컴포지션을 먼저 고려해본다.

본문 블록 94 → 97-99

본문 블록 101-103 → 106-109

본문 블록 109 → 115

컴포지션도 ~~공짜가~~ ~~아니다~~. 상속의 문제를 없애는 것이 아니라, 복잡성을 다른 위치로 ~~옮기는~~ ~~경우가~~ 많다.

본문 블록 114-115 → 120-121

본문 블록 120 → 126-127

즉 컴포지션은 설계 유연성을 ~~산다.~~ 대신 데이터 locality를 팔 수 있다. 이 비용은 웹 CRUD에서는 거의 안 보이지만, 내부 루프에서는 바로 보인다.

본문 블록 126 → 133-134

이건 설계 원칙을 모르는 것이 ~~아니다.~~ 아직 모르는 변경 축에 돈을 쓰지 않는 것이다.

본문 블록 130 → 138

본문 블록 135 → 143

본문 블록 137 → 145

본문 블록 141 → 149

내가 컴포지션을 판단할 때 쓰는 기준은 이렇다.

내가 컴포지션을 판단할 때 쓰는 기준은 보통은 이렇다.

본문 블록 143-144 → 151-152

본문 블록 147-161 → 없음

(내용 없음)

각주 6

(내용 없음)

각주 7

(내용 없음)

각주 8

(내용 없음)

각주 9

(내용 없음)

각주 10

(내용 없음)