SOLID Principles

OOP 설계의 5원칙. 변경에 강하고 테스트 가능한 코드를 만드는 지침. SOLID는 목적이 아닌 수단. 과도한 추상화도 위반이다. 인터페이스 1개에 구현체 1개라면 추상화 비용이 이득을 초과.

sys.entry

M

Me

hyunyoun's Blog

software-engineering-devops2026-04-202 min read

SOLID Principles

OOP 설계의 5원칙. 변경에 강하고 테스트 가능한 코드를 만드는 지침.

5원칙

원칙	핵심	위반 신호
S ingle Responsibility	클래스는 변경 이유가 하나	한 클래스가 DB 접근 + 비즈니스 로직 + UI 모두 처리
O pen/Closed	확장에는 열려 있고 수정에는 닫혀 있음	새 기능 추가 시 기존 코드 수정 필요
L iskov Substitution	서브타입은 부모 타입을 대체 가능	오버라이드 메서드가 부모 계약 위반
I nterface Segregation	클라이언트가 사용하지 않는 인터페이스에 의존 X	빈 메서드 구현 강제
D ependency Inversion	고수준 모듈이 저수준 구현이 아닌 추상에 의존	서비스가 특정 DB 클래스를 직접 생성

가장 자주 위반되는 원칙

SRP: God Class — 수천 줄짜리 서비스 클래스가 모든 것을 처리.

OCP: if/switch로 타입 분기 — 새 타입 추가 시 기존 코드 수정 필요. 해결: Strategy/Visitor 패턴.

DIP: new ConcreteClass() 직접 생성 → 의존성 주입(DI)으로 해결.

실용적 관점

SOLID는 목적이 아닌 수단. 과도한 추상화도 위반이다. 인터페이스 1개에 구현체 1개라면 추상화 비용이 이득을 초과.

연결 노트

ZK-DDD-Bounded-Context — SRP/DIP는 Bounded Context 설계 기반
ZK-Technical-Debt — SOLID 위반이 쌓이면 기술 부채가 됨
ZK-Clean-Architecture — SOLID를 아키텍처 레벨로 확장

Concepts & Tags

#oop #design-principles #clean-code #architecture #refactoring