[G1-Sync] Manual knowledge update
This commit is contained in:
Antigravity Agent
@@ -2,100 +2,209 @@
|
||||
id: wiki-2026-0508-introduce-null-object-널-객체-도입하기
|
||||
title: Introduce Null Object (널 객체 도입하기)
|
||||
category: 10_Wiki/Topics
|
||||
status: needs_review
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: []
|
||||
aliases: [Null Object Pattern, Null Object Refactoring]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.92
|
||||
tags: [uncategorized]
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [refactoring, design-pattern, null-safety]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-08
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
inferred_by: Claude Opus 4.7 (auto-normalize 2026-05-08)
|
||||
tech_stack:
|
||||
language: unspecified
|
||||
framework: unspecified
|
||||
language: typescript
|
||||
framework: none
|
||||
---
|
||||
|
||||
# [[Introduce Null Object (널 객체 도입하기)]]
|
||||
# Introduce Null Object (널 객체 도입하기)
|
||||
|
||||
## 📌 한 줄 통찰 (The Karpathy Summary)
|
||||
Introduce Null Object(널 객체 도입하기)는 코드 내에 반복적으로 등장하는 널(Null) 값 검사 로직을 제거하기 위해, 널 값을 대체할 수 있는 '널 객체(Null Object)'를 도입하는 리팩토링 기법이다 [1, 2]. 이 기법은 객체 지향 프로그래밍의 다형성(Polymorphism)을 활용하여 객체가 자신의 타입에 맞는 적절한 동작을 스스로 수행하게 함으로써 조건부 로직을 단순화한다 [2, 3]. 널 객체는 실제 객체와 동일한 인터페이스에 응답하여, 클라이언트가 널 값 여부를 직접 확인하지 않고도 기본 동작을 일관되게 처리할 수 있도록 돕는다 [2, 4].
|
||||
## 매 한 줄
|
||||
> **"매 null check 의 polymorphism 으로 대체"**. Fowler 의 Refactoring 카탈로그 entry — `if (x == null)` scattered checks 를 default-behavior object 로 collapse. 2026 modern 에서는 Optional/Maybe monad, sealed class hierarchy, TypeScript discriminated union 으로 evolve 했지만 core idea 는 동일.
|
||||
|
||||
## 📖 구조화된 지식 (Synthesized Content)
|
||||
* **다형성을 통한 조건문 제거**: 시스템 전반에서 특정 객체가 존재하는지 검사한 후 메서드를 호출하는 중복 코드(`if (foo == null)`)가 많을 때 유용하다 [2]. 조건문을 다형성으로 대체하여 절차적 코드를 크게 줄이고, 객체의 행위를 단일한 위치에 집중시킬 수 있다 [5, 6].
|
||||
* **구현 방법 (Mechanics)**:
|
||||
* 원본 클래스의 하위 클래스(Subclass)로 널 객체 클래스를 생성하거나 테스트 인터페이스를 활용한다 [7, 8].
|
||||
* 기존 클래스와 널 클래스에 `isNull` 연산을 추가하여 원본은 `false`를, 널 클래스는 `true`를 반환하도록 한다 [7, 9].
|
||||
* 기존에 널을 반환하던 코드가 널 객체를 반환하도록 수정하고, 기존의 `foo == null` 형태의 비교문을 `foo.isNull()`로 교체한다 [7, 10-12].
|
||||
* **주요 활용 사례**:
|
||||
* 화면 표시(Display) 로직에서 수많은 인스턴스 변수의 널 여부를 확인해야 하는 복잡성을 제거할 때 사용된다 [5].
|
||||
* 테스트 환경에서 실제 데이터베이스를 사용하지 않기 위해 가짜(Missing) 데이터베이스 세션 객체로 사용된다 [13].
|
||||
* 급여 계산 시 비어있는 데이터 집합을 빈 컨테이너로 제공하여 0원으로 일괄 처리하는 등 중복된 객체 생성과 로직을 피하기 위해 활용된다 [13].
|
||||
* **싱글톤(Singleton) 패턴 적용**: 널 객체는 일반적으로 내부 상태가 변하지 않는 상수(Constant)와 같은 성격을 띠므로, 싱글톤 패턴을 이용해 단일 인스턴스로 구현하는 것이 권장된다 [4].
|
||||
* **특수 사례(Special Case) 패턴으로의 확장**: 널 객체 패턴은 더 큰 개념인 '특수 사례(Special Case)' 패턴의 일환이다 [14]. 단순히 비어있다는 것을 넘어 "알 수 없는 고객"과 "아직 입주하지 않은 새 건물(고객 없음)"을 구분하기 위해 여러 종류의 널 클래스를 별도로 구현하거나, 나중에 사용할 수 있도록 데이터를 임시로 담아두는 널 객체를 만들 수도 있다 [14, 15].
|
||||
## 매 핵심
|
||||
|
||||
## ⚠️ 모순 및 업데이트 (Contradictions & Updates)
|
||||
* **오류 발견의 어려움**: 널 객체는 실제 객체와 동일한 메시지에 정상적으로 응답하기 때문에, 널 객체가 시스템 내의 잘못된 위치에 존재하더라도 프로그램이 중단(blow up)되거나 예외를 던지지 않는다 [4]. 시스템이 겉으로는 정상적으로 동작하는 것처럼 보여, 실제로 버그가 발생했을 때 즉각적으로 발견하거나 원인을 추적하기 어려워질 수 있다 [4].
|
||||
* **제한적인 적용 조건**: 널 객체로 로직을 이동시키는 것은 '대부분의 클라이언트가 널 상황에 대해 동일한 기본 응답(동작)을 원할 때'에만 이점을 얻는다 [16]. 클라이언트마다 널 상황에서 수행해야 하는 동작이 제각각 다르다면 널 객체의 기본 동작에만 의존할 수 없으므로, 여전히 `isNull` 검사를 통해 개별적인 분기 처리를 해야 한다 [16].
|
||||
* **초기 적용의 번거로움과 복잡성**: 널 객체를 도입하는 과정은 매우 까다로울 수 있다. 널을 반환하는 모든 코드 출처와 이를 검사하는 조건문을 샅샅이 찾아내 수정해야 한다 [17]. 만약 객체가 시스템의 여러 곳으로 광범위하게 전달되고 있다면, 이를 추적하고 변경하는 것을 안전한 작은 단계로 나누어 리팩토링하기 어려울 수 있다 [17].
|
||||
### 매 문제
|
||||
- Repeated null guards: `customer == null ? "unknown" : customer.name()` 의 매 caller 마다 반복.
|
||||
- Null-aware logic 의 매 client code 에 leak — encapsulation violation.
|
||||
- NullPointerException / undefined error 의 매 production crash 의 top cause.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-03*
|
||||
### 매 solution
|
||||
- Null state 를 dedicated subclass 로 represent: `NullCustomer extends Customer`.
|
||||
- Default behavior 를 polymorphic method 로 push down.
|
||||
- Caller 는 `customer.name()` 의 null check 없이 호출.
|
||||
|
||||
## 🤖 LLM 활용 힌트 (How to Use This Knowledge)
|
||||
### 매 응용
|
||||
1. Fowler refactoring step-by-step (Replace Conditional with Polymorphism 의 sibling).
|
||||
2. Domain-driven design 의 missing aggregate handling.
|
||||
3. Strategy pattern 의 default no-op variant.
|
||||
|
||||
**언제 이 지식을 쓰는가:**
|
||||
- *(TODO)*
|
||||
## 💻 패턴
|
||||
|
||||
**언제 쓰면 안 되는가:**
|
||||
- *(TODO)*
|
||||
### 1. Before (null check scattered)
|
||||
```typescript
|
||||
class Site {
|
||||
constructor(public customer: Customer | null) {}
|
||||
}
|
||||
|
||||
## 🧪 검증 상태 (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: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)*
|
||||
|
||||
```text
|
||||
# TODO
|
||||
const customer = site.customer;
|
||||
const name = customer === null ? "occupant" : customer.name;
|
||||
const plan = customer === null ? BillingPlan.basic() : customer.plan;
|
||||
const history = customer === null ? new PaymentHistory([]) : customer.history;
|
||||
```
|
||||
|
||||
## 🤔 의사결정 기준 (Decision Criteria)
|
||||
### 2. After (Null Object)
|
||||
```typescript
|
||||
abstract class Customer {
|
||||
abstract get name(): string;
|
||||
abstract get plan(): BillingPlan;
|
||||
abstract get history(): PaymentHistory;
|
||||
isNull(): boolean { return false; }
|
||||
}
|
||||
|
||||
**선택 A를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
class RealCustomer extends Customer {
|
||||
constructor(
|
||||
public name: string,
|
||||
public plan: BillingPlan,
|
||||
public history: PaymentHistory,
|
||||
) { super(); }
|
||||
}
|
||||
|
||||
**선택 B를 써야 할 때:**
|
||||
- *(TODO)*
|
||||
class NullCustomer extends Customer {
|
||||
get name() { return "occupant"; }
|
||||
get plan() { return BillingPlan.basic(); }
|
||||
get history() { return new PaymentHistory([]); }
|
||||
isNull() { return true; }
|
||||
}
|
||||
|
||||
**기본값:**
|
||||
> *(TODO)*
|
||||
class Site {
|
||||
constructor(public customer: Customer = new NullCustomer()) {}
|
||||
}
|
||||
|
||||
## ❌ 안티패턴 (Anti-Patterns)
|
||||
// Caller — 매 null check 없이
|
||||
const name = site.customer.name;
|
||||
```
|
||||
|
||||
- **[안티패턴]:** *(TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)*
|
||||
### 3. Special Case (richer variant)
|
||||
```typescript
|
||||
class UnknownCustomer extends Customer {
|
||||
get name() { return "unknown"; }
|
||||
// ... default
|
||||
}
|
||||
|
||||
class DeceasedCustomer extends Customer {
|
||||
get name() { return "[deceased]"; }
|
||||
// ... distinct semantics
|
||||
}
|
||||
|
||||
// Factory dispatch
|
||||
function loadCustomer(id: string): Customer {
|
||||
const row = db.find(id);
|
||||
if (!row) return new UnknownCustomer();
|
||||
if (row.deceased) return new DeceasedCustomer(row);
|
||||
return new RealCustomer(row.name, row.plan, row.history);
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Optional / Maybe (functional alternative)
|
||||
```typescript
|
||||
type Maybe<T> = { kind: "some"; value: T } | { kind: "none" };
|
||||
|
||||
const customer: Maybe<Customer> = loadCustomer(id);
|
||||
|
||||
const name = customer.kind === "some"
|
||||
? customer.value.name
|
||||
: "occupant";
|
||||
|
||||
// Or with helper
|
||||
function fold<T, R>(m: Maybe<T>, onSome: (v: T) => R, onNone: () => R): R {
|
||||
return m.kind === "some" ? onSome(m.value) : onNone();
|
||||
}
|
||||
```
|
||||
|
||||
### 5. Sealed class (Kotlin / TS discriminated union)
|
||||
```typescript
|
||||
type CustomerState =
|
||||
| { tag: "real"; data: RealCustomer }
|
||||
| { tag: "null"; reason: "missing" | "deceased" };
|
||||
|
||||
function displayName(s: CustomerState): string {
|
||||
switch (s.tag) {
|
||||
case "real": return s.data.name;
|
||||
case "null": return s.reason === "deceased" ? "[deceased]" : "occupant";
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 6. Logger Null Object (classic example)
|
||||
```typescript
|
||||
interface Logger {
|
||||
log(msg: string): void;
|
||||
}
|
||||
|
||||
class ConsoleLogger implements Logger {
|
||||
log(msg: string) { console.log(msg); }
|
||||
}
|
||||
|
||||
class NullLogger implements Logger {
|
||||
log(_msg: string) { /* no-op */ }
|
||||
}
|
||||
|
||||
class Service {
|
||||
constructor(private logger: Logger = new NullLogger()) {}
|
||||
// 매 logger null check 없이 항상 호출 가능
|
||||
}
|
||||
```
|
||||
|
||||
### 7. React/UI default component
|
||||
```tsx
|
||||
function UserBadge({ user }: { user: User | null }) {
|
||||
// 매 null branch 없이 — NullUser component 로 dispatch
|
||||
const u = user ?? NULL_USER;
|
||||
return <span>{u.displayName}</span>;
|
||||
}
|
||||
|
||||
const NULL_USER: User = {
|
||||
id: "anonymous",
|
||||
displayName: "Anonymous",
|
||||
avatar: "/default.png",
|
||||
};
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| OO codebase, 매 null check 의 3+ 위치 반복 | Null Object class. |
|
||||
| Functional / TS strict, 매 type-level safety 필요 | Maybe / Optional / discriminated union. |
|
||||
| Side-effect 의 default no-op (logger, audit) | NullLogger 의 dependency injection. |
|
||||
| 매 distinct missing-state semantics (unknown vs deceased) | Special Case (multiple null subtypes). |
|
||||
| 매 single-use null check | 매 그냥 inline `?? default`. |
|
||||
|
||||
**기본값**: TypeScript / modern stack 에서는 `?? default` 또는 discriminated union. OO heavy refactor target 에서는 Null Object class.
|
||||
|
||||
## 🔗 Graph
|
||||
- 부모: [[Refactoring]] · [[Design Patterns]]
|
||||
- 변형: [[Special Case Pattern]] · [[Maybe Monad]] · [[Optional Type]]
|
||||
- 응용: [[Strategy Pattern]] · [[Dependency Injection]]
|
||||
- Adjacent: [[Replace Conditional with Polymorphism]] · [[Sealed Classes]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: legacy codebase 의 null-check noise 제거 refactor, library API 의 default behavior design.
|
||||
**언제 X**: 매 single null check, performance-critical hot path (allocation overhead), exception 이 의도된 signal 인 경우.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **Hidden bugs**: NullCustomer 의 silent default 가 매 real bug 를 mask. Logging 또는 `isNull()` flag 로 trace 가능하게 유지.
|
||||
- **God Null Object**: 매 모든 method 에 default 의 over-design. 매 진짜 polymorphic 사용처만 cover.
|
||||
- **Equality confusion**: `nullCustomer === null` false 의 매 caller 혼란. 매 명확한 documentation + `isNull()` helper.
|
||||
- **Mutation on Null Object**: 매 shared instance 의 mutation 이 cross-contamination 의 cause. 매 immutable 유지.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified (Fowler, *Refactoring* 2nd ed., "Introduce Special Case" — Null Object 의 modern rename).
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Null Object refactoring + modern Maybe/sealed union variants |
|
||||
|
||||
Reference in New Issue
Block a user