Software Design

글 36개

Active Record

Active Record · Design Pattern

Active Record

객체가 자기를 저장할 줄 안다. Repository와 정반대 선택이고, 틀린 선택이 아니라 다른 선택이다.

Aggregate

Aggregate · Design Pattern

Aggregate

어디까지가 한 덩어리인가. 함께 지켜야 할 것을 묶고, 그 경계를 트랜잭션과 저장소가 따라간다.

·도메인 모델링 3편
Entity와 Value Object

Value Object · Design Pattern

Entity와 Value Object

무엇으로 같음을 판단하나. 식별자로 같은 것과 값이 같으면 같은 것, 그 둘을 갈라 쓰는 이유.

·도메인 모델링 2편
로직을 어디에 둘 것인가

Domain Model · Design Pattern

로직을 어디에 둘 것인가

업무 규칙을 절차에 늘어놓을 것인가, 객체에 넣을 것인가. 트랜잭션 스크립트와 도메인 모델, 그리고 둘을 가르는 기준.

·도메인 모델링 1편
Unit of Work

Unit of Work · Design Pattern

Unit of Work

저장할 때마다 DB에 쓰면 업무의 반쪽만 남을 수 있다. 변경을 한 단위로 모았다가 한 번에 반영하는 패턴.

DTO

DTO · Design Pattern

DTO

엔티티를 그대로 내보내면 DB 구조가 곧 API 계약이 된다. 계층을 건너는 전용 그릇을 따로 두는 패턴.

Service Layer

Service Layer · Design Pattern

Service Layer

컨트롤러에 업무 절차가 쌓인다. 절차를 서비스 계층으로 옮겨, 입구가 여럿이어도 규칙은 한 곳에 있게 만드는 패턴.

Repository Pattern

Repository Pattern · Design Pattern

Repository Pattern

비즈니스 로직에서 DB 코드를 걷어낸다. 데이터 접근을 인터페이스 뒤로 숨겨, 구현을 갈아끼워도 로직은 그대로 두는 패턴.

Interpreter

GoF · Behavioral

Interpreter

작은 언어의 문법을 객체 트리로 표현하고 그 트리를 재귀로 평가하는, 드물지만 발상이 또렷한 행위 패턴.

·행동 패턴 11편
Visitor

GoF · Behavioral

Visitor

객체 구조는 그대로 두고, 그 위를 도는 새 연산을 바깥의 방문자로 추가하는 행위 패턴.

·행동 패턴 10편
Memento

GoF · Behavioral

Memento

객체의 내부 상태를 캡슐화를 깨지 않고 스냅샷으로 저장해뒀다가 되돌리는 행위 패턴.

·행동 패턴 9편
Mediator

GoF · Behavioral

Mediator

객체들이 서로 직접 참조하며 얽히지 않도록, 중재자를 하나 세워 소통을 그리로 몰아주는 행위 패턴.

·행동 패턴 8편
Iterator

GoF · Behavioral

Iterator

컬렉션의 속을 열어 보지 않고 원소를 순서대로 훑을 때. 순회를 캡슐화해 내부 구조와 순회 코드를 떼어 놓는 행위 패턴.

·행동 패턴 7편
Chain of Responsibility

GoF · Behavioral

Chain of Responsibility

누가 처리할지 미리 못 정할 때. 요청을 처리자들의 사슬에 흘려보내 처리 가능한 자가 맡게 하는 행위 패턴.

·행동 패턴 6편
State

GoF · Behavioral

State

상태에 따라 행동이 갈릴 때. 상태를 객체로 만들어 거대한 조건문을 다형성으로 바꾸는 행위 패턴.

·행동 패턴 5편
Template Method

GoF · Behavioral

Template Method

여러 흐름이 큰 틀은 같은데 한 단계만 다를 때. 뼈대를 상위가 고정하고 달라지는 구멍만 하위가 채우는 행위 패턴.

·행동 패턴 4편
Command

GoF · Behavioral

Command

요청을 나중에 실행하거나 되돌리거나 기록하고 싶을 때. 요청 자체를 객체로 캡슐화하는 행위 패턴.

·행동 패턴 3편
Observer

GoF · Behavioral

Observer

상태가 바뀔 때마다 관심 있는 것들을 일일이 불러야 할 때. 구독한 여럿에게 자동으로 통지하는 행위 패턴.

·행동 패턴 2편
Strategy

GoF · Behavioral

Strategy

기준이 늘 때마다 if/switch를 고쳐야 할 때. 알고리즘을 인터페이스로 빼 런타임에 갈아끼우는 행위 패턴.

·행동 패턴 1편
Flyweight

GoF · Structural

Flyweight

같은 객체를 수백만 개 만들어 메모리가 터질 때. 공유 가능한 부분을 뽑아 하나만 만들어 나눠 쓰는 구조 패턴.

·구조 패턴 7편
Bridge

GoF · Structural

Bridge

두 축이 곱해지며 클래스가 폭발할 때. '무엇'과 '어떻게'를 두 계층으로 갈라 다리로 잇고, 각자 독립해 자라게 하는 구조 패턴.

·구조 패턴 6편
Composite

GoF · Structural

Composite

파일과 폴더처럼 개별과 묶음이 섞인 트리를, 클라이언트가 구분 없이 똑같이 다루게 하는 구조 패턴.

·구조 패턴 5편
Facade

GoF · Structural

Facade

하나 하려고 여러 개를 순서대로 불러야 할 때. 복잡한 하위 시스템 앞에 단순한 창구 하나를 세우는 구조 패턴.

·구조 패턴 4편
Proxy

GoF · Structural

Proxy

진짜 객체 앞에 대리인을 세워 접근을 제어한다. 지연 로딩·권한 검사·캐싱을 진짜를 건드리지 않고 끼우는 구조 패턴.

·구조 패턴 3편
Decorator

GoF · Structural

Decorator

상속으로 조합을 만들면 클래스가 폭발한다. 같은 인터페이스로 감싸 기능을 덧입히고, 여러 겹으로 쌓는 구조 패턴.

·구조 패턴 2편
Adapter

GoF · Structural

Adapter

내 코드가 기대하는 인터페이스와 남의 코드가 주는 인터페이스가 안 맞을 때. 사이에 번역기를 끼워 붙게 만드는 구조 패턴.

·구조 패턴 1편
Prototype

GoF · Creational

Prototype

처음부터 만들지 않고, 이미 있는 객체를 복제해 새로 만든다. 얕은 복사의 함정과 clone()의 문제까지 다루는 마지막 생성 패턴.

·생성 패턴 5편
Builder

GoF · Creational

Builder

인자가 많고 대부분 선택인 객체를, 생성자 폭발 없이 단계별로 조립한다. 읽히고, 필수를 강제하고, 끝에서 불변으로 굳히는 생성 패턴.

·생성 패턴 4편
Abstract Factory

GoF · Creational

Abstract Factory

따로 만들면 짝이 어긋난다. 서로 맞아야 하는 관련 객체들을 한 세트로 만들어, 섞이지 않게 보장하는 생성 패턴.

·생성 패턴 3편
Factory Method

GoF · Creational

Factory Method

객체를 만드는 코드가 구체 타입에 박히지 않게. 무엇을 만들지 하위 클래스가 결정하도록 생성을 메서드로 빼는 생성 패턴.

·생성 패턴 2편
Singleton

GoF · Creational

Singleton

앱 전체에 인스턴스가 딱 하나만 있어야 할 때. 만드는 법은 간단하지만, 멀티스레드와 전역 상태라는 두 함정이 따라오는 생성 패턴.

·생성 패턴 1편
Dependency Inversion Principle

SOLID · DIP

Dependency Inversion Principle

고수준 정책이 저수준 구현에 매달리지 않게. 둘 사이에 추상화를 두어 의존의 방향을 뒤집는 마지막 SOLID 원칙.

·SOLID 원칙 5편
Interface Segregation Principle

SOLID · ISP

Interface Segregation Principle

쓰지도 않는 메서드에 의존하게 만들지 마라. 뚱뚱한 인터페이스를 역할별로 쪼개는 네 번째 SOLID 원칙.

·SOLID 원칙 4편
Liskov Substitution Principle

SOLID · LSP

Liskov Substitution Principle

자식은 부모 자리에 넣어도 약속을 깨면 안 된다. 상속은 구조가 아니라 계약을 물려받는 것 - 세 번째 SOLID 원칙.

·SOLID 원칙 3편
Open/Closed Principle

SOLID · OCP

Open/Closed Principle

새 동작은 추가하되 기존 코드는 고치지 않는다. 타입이 늘 때마다 if-else를 여는 대신, 다형성으로 확장점을 두는 두 번째 SOLID 원칙.

·SOLID 원칙 2편
Single Responsibility Principle

SOLID · SRP

Single Responsibility Principle

클래스가 바뀌는 이유는 하나여야 한다. '일'이 아니라 '이유'로 나누는 첫 번째 SOLID 원칙.

·SOLID 원칙 1편