SOLID 원칙 정리
SOLID 원칙이란?
SOLID 원칙은 시간이 지나도 유지보수와 확장이 쉬운, 그리고 이해하기 편하고 유연한 소프트웨어를 만들기 위한 다섯 가지 객체 지향 설계 원칙의 모음이다.
객체 지향 프로그래밍을 하다 보면 코드는 점점 커지고, 기능은 계속 추가된다.
이때 SOLID 원칙을 지키지 않으면 코드가 쉽게 망가진다.
SOLID는 이런 상황을 방지하기 위한 설계 기준이다.
1. SRP — 단일 책임 원칙 (Single Responsibility Principle)
클래스는 단 하나의 책임만 가져야 한다.
핵심 의미
- 하나의 클래스는 하나의 이유로만 변경되어야 한다
- 여러 책임을 가지면 변경 시 연쇄 수정이 발생한다
문제점
- 한 클래스가
- 데이터 관리
- 계산
- 저장
- 출력
같은 역할을 모두 맡으면 - 코드가 커지고 수정이 어려워진다
해결 방법
- 책임을 기준으로 클래스를 분리한다
- “이 클래스는 무엇 때문에 바뀌는가?”를 기준으로 나눈다
2. OCP — 개방/폐쇄 원칙 (Open/Closed Principle)
확장에는 열려 있고, 수정에는 닫혀 있어야 한다.
핵심 의미
- 기존 코드를 고치지 않고
- 새로운 기능을 추가할 수 있어야 한다
문제점
- 조건문(if/else, switch)이 계속 늘어나는 구조
- 새로운 타입이 추가될 때마다 기존 코드 수정 필요
해결 방법
- 인터페이스(추상화)를 사용한다
- 구현체를 교체하거나 추가하는 방식으로 확장한다
-> 새로운 기능이 생겨도 기존 코드에는 손대지 않는 것이 목표다.
3. LSP — 리스코프 치환 원칙 (Liskov Substitution Principle)
자식 클래스는 부모 클래스를 완전히 대체할 수 있어야 한다.
핵심 의미
- 부모 타입으로 사용하는 코드가
- 자식 객체로 바뀌어도 동작이 깨지면 안 된다
문제점
- 상속을 잘못 사용하면
- 부모의 계약(의도)을 자식이 깨뜨릴 수 있다
대표적인 실수
- “정사각형은 직사각형이다”라는 상속
- 행동 규칙이 달라져 예상 결과가 달라짐
해결 방법
- 상속보다 인터페이스 기반 설계
- 공통된 행동만 추상화한다
4. ISP — 인터페이스 분리 원칙 (Interface Segregation Principle)
클라이언트는 자신이 사용하지 않는 메서드에 의존하면 안 된다.
여기서 클라이언트란?
- 이미 구현된 코드를 사용하는 쪽 코드
문제점
- 하나의 인터페이스에 너무 많은 기능이 들어 있음
- 구현 클래스가 필요 없는 메서드까지 억지로 구현해야 함
해결 방법
- 인터페이스를 작은 단위로 분리
- 필요한 기능만 선택해서 구현하도록 설계
-> “뚱뚱한 인터페이스”를 만들지 말자.
5. DIP — 의존 역전 원칙 (Dependency Inversion Principle)
고수준 모듈과 저수준 모듈은 둘 다 추상화에 의존해야 한다.
핵심 의미
- 구현 클래스에 직접 의존하지 않는다
- 인터페이스에 의존하도록 만든다
문제점
- 고수준 로직이 특정 구현에 묶여 있으면
- 구현 변경 시 코드 수정이 불가피하다
해결 방법
- 인터페이스를 통해 의존성을 역전시킨다
- 생성자 주입(Dependency Injection)을 사용한다
-> “무엇을 하는지”에 의존하고
-> “어떻게 하는지”에는 의존하지 않는다.
SOLID 원칙을 지키면 얻는 것
- 유지보수성 향상
→ 수정 범위가 줄어든다 - 확장성 증가
→ 새로운 기능 추가가 쉽다 - 테스트 용이성
→ 각 컴포넌트를 독립적으로 테스트 가능 - 코드 재사용성
→ 다른 프로젝트에서도 활용 가능 - 팀 협업에 유리
→ 구조가 명확해 이해하기 쉽다
오늘의 정리
SOLID 원칙은 “지금 당장 코드를 잘 짜기 위한 규칙”이 아니라 미래의 변경을 대비하기 위한 설계 철학이다.
- 클래스는 하나의 책임만 가진다
- 기존 코드는 건드리지 않고 확장한다
- 상속은 조심해서 사용한다
- 인터페이스는 작게 나눈다
- 구현이 아니라 추상화에 의존한다
