Files

T

koriweb 5ba5a55c78 feat: Wiki 지식 자산 업데이트 - UX Scenarios, Frontend, Game Design, Topics 추가 [2026-05-08]

2026-05-08 19:52:07 +09:00

6.0 KiB

Raw Blame History

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

title

Preserve Whole Object (객체 통째로 넘기기)

📌 한 줄 통찰 (The Karpathy Summary)

'Preserve Whole Object(객체 통째로 넘기기)'는 단일 객체에서 여러 데이터 값을 추출하여 메서드의 매개변수로 각각 전달하는 대신, 데이터를 추출한 원본 객체 전체를 매개변수로 전달하는 리팩토링 기법입니다 [1, 2]. 이 기법은 메서드 호출을 단순화하는 데 사용되며, 길고 복잡한 매개변수 목록을 줄여 코드의 가독성과 유지보수성을 높이는 것을 목적으로 합니다 [3-5]. 주로 '데이터 뭉치(Data Clumps)' 스멜을 해결하거나 '긴 매개변수 목록(Long Parameter List)'을 정리할 때 유용하게 활용됩니다 [4, 6].

📖 구조화된 지식 (Synthesized Content)

문제 상황 및 적용: 특정 객체에서 여러 개의 값을 가져와 다른 메서드의 매개변수로 전달하는 상황에서 주로 적용됩니다. 값을 개별적으로 넘기게 되면, 나중에 호출되는 객체가 새로운 데이터 값을 필요로 할 때마다 해당 메서드의 모든 호출부를 찾아 매개변수를 추가하고 수정해야 하는 번거로움이 발생합니다. 대신 객체 전체를 전달하면 호출된 객체가 필요한 데이터를 원본 객체에 직접 요청할 수 있으므로 이러한 변경의 어려움이 해결됩니다 [1, 2].
가독성 향상 및 중복 제거: 긴 매개변수 목록은 호출자와 피호출자 모두가 어떤 값이 포함되어 있는지 기억해야 하므로 코드를 다루기 어렵게 만듭니다. 또한, 피호출 객체가 원본 객체의 다른 메서드를 활용하여 중간 값을 계산할 수 없게 만들어 결과적으로 코드 중복을 유발합니다. 객체를 통째로 넘기면 매개변수 목록이 변경에 더 유연해지고 가독성이 크게 향상됩니다 [2].
실행 절차:
1. 데이터를 제공하는 전체 객체에 대한 새로운 매개변수를 생성합니다 [7].
2. 전체 객체에서 얻을 수 있는 매개변수를 확인하여, 메서드 본문 내의 기존 매개변수 참조를 전체 객체의 메서드 호출로 대체합니다 [7].
3. 기존 매개변수를 삭제하고 컴파일 및 테스트를 진행하며 이를 반복합니다 [7, 8].
4. 마지막으로 호출하는 메서드 측에서 삭제된 매개변수를 얻어오던 코드를 제거합니다 [7].
연관된 리팩토링: 이 기법은 '매개변수 객체 만들기(Introduce Parameter Object)'와 함께 긴 매개변수 목록을 줄이는 데 핵심적인 역할을 합니다 [4, 6]. 또한, 호출된 메서드가 다른 객체의 값을 너무 많이 사용한다는 것은 해당 메서드가 데이터가 있는 객체에 정의되어야 함을 암시하는 신호일 수 있으므로, '객체 통째로 넘기기'를 적용하는 대신 '메서드 이동(Move Method)'을 대안으로 고려해볼 수도 있습니다 [9].

⚠️ 모순 및 업데이트 (Contradictions & Updates)

의존성(Dependency) 증가 위험: 이 기법의 가장 큰 부작용은 의존성 문제입니다. 값을 개별적으로 전달할 때 피호출 객체는 그 값들에만 의존할 뿐, 값이 추출된 원본 객체 자체에는 의존하지 않습니다. 하지만 객체 전체를 전달하게 되면, 요구되는 원본 객체와 호출되는 객체 사이에 새로운 의존성이 발생합니다. 이러한 변경이 시스템의 의존성 구조를 엉망으로 만들 우려가 있다면 '객체 통째로 넘기기'를 사용해서는 안 됩니다 [10].
단일 값 전달에 대한 이견: 호출하는 객체가 요구되는 객체에서 오직 단일 값(하나의 데이터)만 필요로 할 때는 전체 객체보다 그 값 하나만 전달하는 것이 낫다는 의견도 존재합니다. 하지만 마틴 파울러(Martin Fowler)는 가독성 측면에서 값 하나를 전달하는 것과 객체 하나를 전달하는 것은 큰 차이가 없다고 보며, 결국 **이 기법의 적용을 결정하는 가장 중요한 원동력은 '의존성(Dependency) 문제'**라고 강조합니다 [10].

Last updated: 2026-05-03

🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

(TODO)

언제 쓰면 안 되는가:

(TODO)

🧪 검증 상태 (Validation)

정보 상태: needs_review
출처 신뢰도: A
검토 이유: (P-Reinforce Phase 1 자동 정규화. 본문 검증 필요.)

🧬 중복 검사 (Duplicate Check)

기존 유사 문서: (TODO: 인덱서 클러스터 리포트 참조)
처리 방식: UPDATE (자동 정규화)
처리 이유: Phase 1 정규화 — 옛 템플릿/누락 필드 보강.

🔗 지식 연결 (Graph)

Parent: 10_Wiki/Topics
Related: (TODO: 최소 2개)
Opposite / Trade-off: (TODO)
Raw Source: 직접 입력

🕓 변경 이력 (Changelog)

날짜	변경 내용	처리 방식	신뢰도
2026-05-08	P-Reinforce Phase 1 정규화 (frontmatter + 헤더 표준화)	UPDATE	A

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

(TODO)

선택 B를 써야 할 때:

(TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

[안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)

6.0 KiB Raw Blame History