개정 비교

컴포지션

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

비교 전 원문: 2026-06-08 14:04:23 UTC 비교 후 원문: 2026-10-25 06:18:01 UTC

변경 구간 13개

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

본문 블록 8 → 8

개인 메모: 사실 이런 것은 흔하다. 특정 정보를 전달할때 이해하기 쉽게 일부 정보를 제거하는데, 이 과정에서 정보 손실이 일어나고, 정보가 왜곡되고 또 밈화 된다.

본문 블록 19 → 19

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

본문 블록 26 → 26

상속은 코드 재사용, 타입 계층, 개념 분류, 차이 기반 프로그래밍을 ~~동시에~~ ~~가지게~~ 된다.

상속은 코드 재사용, 타입 계층, 개념 분류, 차이 기반 프로그래밍을 하나의 문법 안에 묶어 놓는다.

본문 블록 40 → 40

개인 메모: ~~유전작적으로~~ 부모가 자식에게 물려받아야지 자식이 부모에게 물려주면 말이 안된다고 생각하면 된다. 다만 ~~정신 문화적으로는~~ 말이 되긴한다. 자식은 부모에게 변화를 주니까. 나는 이 나이먹고 안정적이게 자리잡지 못해서, 우리 부모님 등골을 한 서너개쯤 빼먹어서 부모님 등이 굽은 것 같긴하다.

개인 메모: 유전자적으로 부모가 자식에게 물려받아야지 자식이 부모에게 물려주면 말이 안된다고 생각하면 된다. 다만 정신적으로는 말이 되긴한다. 자식은 부모에게 변화를 주니까. 나는 이 나이먹고 안정적이게 자리잡지 못해서, 우리 부모님 등골을 한 서너개쯤 빼먹어서 부모님 등이 굽은 것 같긴하다.

본문 블록 55 → 55

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

본문 블록 85-86 → 85-86

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

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

본문 블록 91 → 91

컴포지션은 "내가 직접 내부를 뒤지지 않고, 가까운 협력 객체에게 일을 맡긴다"는 점에서 ~~Law of~~ ~~Demeter와~~ 연결된다.

컴포지션은 "내가 직접 내부를 뒤지지 않고, 가까운 협력 객체에게 일을 맡긴다"는 점에서 디미터의 법칙과 연결된다.

본문 블록 93 → 93

따라서 ~~Law of~~ ~~Demeter의~~ 핵심은 점 개수를 세는 것이 아니다. 외부 코드가 내부 구조를 알아야만 판단할 수 있는 상태를 줄이는 것이다.

따라서 디미터의 법칙의 핵심은 점 개수를 세는 것이 아니다. 외부 코드가 내부 구조를 알아야만 판단할 수 있는 상태를 줄이는 것이다.

본문 블록 106-107 → 106-107

개인 메모: 상속은 가끔 "공짜 재사용"처럼 보이는데, 실제로는 부모 클래스의 인생사까지 물려받는 경우가 많다. 부모가 돈이 많다면 자식이 기꺼이 물려받겠지만, 가난할 경우 그 부모를 벗어나고 싶듯이, 상속도 좋은 부모한테 물려받을 게 있을때만 받는 것이 좋다. ~~상속만~~ ~~쓰는게~~ 자연스러운 것: open recursion

개인 메모: 상속은 가끔 "공짜 재사용"처럼 보이는데, 실제로는 부모 클래스의 인생사까지 물려받는 경우가 많다. 부모가 돈이 많다면 자식이 기꺼이 물려받겠지만, 가난할 경우 그 부모를 벗어나고 싶듯이, 상속도 좋은 부모한테 물려받을 게 있을때만 받는 것이 좋다. 상속에서 특히 자연스러운: open recursion

본문 블록 121 → 121

그래서 게임 엔진, 시뮬레이션, 고성능 금융 시스템처럼 많은 데이터를 매 프레임/매 틱 순회하는 영역에서는 ~~객체지향~~ ~~컴포지션보다~~ ~~데이터~~ 지향 ~~프로그래밍이나~~ ECS~~(Entity~~ ~~Component~~ System)가 더 맞을 수 있다.[각주 10]

그래서 게임 엔진, 시뮬레이션, 고성능 금융 시스템처럼 많은 데이터를 매 프레임/매 틱 순회하는 영역에서는 객체 참조 기반 컴포지션보다 SoA, ECS, Job System 같은 데이터 지향 컴포지션이 더 적합할 수 있다.[각주 10]

본문 블록 138-140 → 138-140

작은 객체가 많아지면 테스트는 쉬워질 수 있지만, 실제 런타임에 어떤 구현체가 들어왔는지 추적하기는 어려워진다. 특히 DI 설정이 여러 모듈에 흩어져 있으면 코드를 읽는 사람은 "이 인터페이스의 실제 구현이 뭐지?"부터 찾아야 한다. 너무 잘게 쪼개면 '샷건 수술~~'이라는~~ 안티 ~~패턴에~~ 빠질 수 있다. 4. ~~Law of~~ ~~Demeter~~ 남용 Law of ~~Demeter는~~ 내부 구조를 줄이라는 원칙이지, 모든 접근을 포워딩 메서드로 감싸라는 뜻이 아니다.

작은 객체가 많아지면 테스트는 쉬워질 수 있지만, 실제 런타임에 어떤 구현체가 들어왔는지 추적하기는 어려워진다. 특히 DI 설정이 여러 모듈에 흩어져 있으면 코드를 읽는 사람은 "이 인터페이스의 실제 구현이 뭐지?"부터 찾아야 한다. 너무 잘게 쪼개면 하나의 정책 변경이 여러 객체와 DI 설정을 동시에 건드리는 형태가 되고, 결과적으로 샷건 수술(Shotgun Surgery)과 같은 안티 패턴 냄새가 생길 수 있다. 4. 디미터의 법칙의 남용 디미터의 법칙(Law of Demeter)은 내부 구조를 줄이라는 원칙이지, 모든 접근을 포워딩 메서드로 감싸라는 뜻이 아니다.

본문 블록 없음 → 144-145

(내용 없음)

이 딜레마를 줄이는 방법 중 하나는 'Tell, Don't Ask(묻지 말고 시켜라)' 원칙을 적용하는 것이다. 객체 내부의 데이터를 꺼내와서(Ask) 밖에서 로직을 처리하려 하지 말고, 데이터를 가장 잘 아는 객체에게 계산이나 행위를 위임(Tell)해야 한다. 그러면 래퍼 폭발 없이도 자연스럽게 캡슐화가 유지되고 컴포지션의 책임을 나눌 수 있다.

본문 블록 없음 → 157-159