[Java] 객체지향 프로그래밍(OOP) - 4. SOLID란? 객체지향 설계의 다섯 가지 핵심 원칙

 

 

---

SOLID 원칙

• SRP (단일 책임 원칙)
• OCP (개방-폐쇄 원칙)
• LSP (리스코프 치환 원칙)
• DIP (의존 역전 원칙)
• ISP (인터페이스 분리 원칙)

---

📘 SOLID — 객체지향 설계의 다섯 가지 핵심 원칙

학습목표

• 소프트웨어 설계의 기본 원리인 SOLID 원칙을 이해한다.
• 각 원칙의 정의와 적용 방법을 학습하여 유지보수성과 확장성이 높은 프로그램을 설계할 수 있다.
• 실제 예시를 통해 잘못된 설계와 개선된 설계의 차이를 이해한다.

---

1. SRP (Single Responsibility Principle) — 단일 책임 원칙

“하나의 클래스는 오직 하나의 이유로만 변경되어야 한다.”

정의

• 클래스는 하나의 책임(변경 이유)만을 가져야 한다.
• 서로 다른 목적의 기능을 한 클래스에 담으면, 하나의 변경이 다른 기능에 영향을 줄 수 있다.

핵심 개념

• 책임(Responsibility)은 곧 변경 이유(Reason for Change)이다.
• 여러 책임을 가진 클래스는 여러 변경 원인에 노출되어 유지보수가 어렵다.
• 즉, 한 클래스가 담당해야 할 역할을 명확히 분리해야 한다.

예시

 

// ❌ 잘못된 예시: Student 클래스가 여러 역할을 수행
class Student {
    void saveToDatabase() {}
    void printReportCard() {}
    void findAdvisor() {}
}

// ✅ 개선된 예시: 책임 분리
class StudentRepository { void save(Student s) {} }
class ReportPrinter { void print(Student s) {} }
class AdvisorFinder { void find(Student s) {} }
// ❌ 잘못된 예시: Student 클래스가 여러 역할을 수행
class Student {
    void saveToDatabase() {}
    void printReportCard() {}
    void findAdvisor() {}
}

// ✅ 개선된 예시: 책임 분리
class StudentRepository { void save(Student s) {} }
class ReportPrinter { void print(Student s) {} }
class AdvisorFinder { void find(Student s) {} }

주요 문제점

• 여러 책임을 가진 클래스는 “산탄총 수술(Shotgun Surgery)” 현상을 유발한다.
  → 하나의 변경이 여러 클래스 또는 여러 메서드에 동시에 영향을 미침.

---

2. OCP (Open-Closed Principle) — 개방-폐쇄 원칙

“소프트웨어 엔티티는 확장에는 열려 있고, 수정에는 닫혀 있어야 한다.”

정의

• 새로운 기능을 기존 코드를 수정하지 않고 추가할 수 있도록 설계해야 한다.
• 즉, 확장은 열려(Open) 있으나, 수정은 닫혀(Closed) 있어야 한다.

적용 방법

• 인터페이스나 추상 클래스를 이용하여 변경되지 않는 부분(닫힌 부분)과 변경될 부분(열린 부분)을 분리한다.

예시

interface MusicPlayer {
    void play();
}

class MP3Player implements MusicPlayer {
    public void play() { System.out.println("Playing MP3"); }
}

class TimeTrigger {
    private MusicPlayer player;
    public TimeTrigger(MusicPlayer player) { this.player = player; }

    public void trigger() {
        player.play(); // 변경 없이 확장 가능
    }
}

위 설계에서는 새로운 재생 장치가 추가되어도 MusicPlayer 인터페이스만 구현하면 기존 코드를 수정할 필요가 없다.

---

3. LSP (Liskov Substitution Principle) — 리스코프 치환 원칙

“하위 클래스는 상위 클래스를 완벽히 대체할 수 있어야 한다.”

정의

• 프로그램에서 부모 클래스의 객체 대신 자식 클래스 객체를 사용해도 프로그램이 정상적으로 작동해야 한다.

예시

 

class Rectangle {
    int width, height;
    void setWidth(int w) { width = w; }
    void setHeight(int h) { height = h; }
    int getArea() { return width * height; }
}

class Square extends Rectangle {
    void setWidth(int w) {
        width = w;
        height = w; // 정사각형의 특성 유지
    }
}

하지만, Rectangle을 기대한 코드가 Square를 대입했을 때 예기치 못한 동작을 한다면 LSP 위반이다.
즉, “is-a 관계”가 있다고 해서 무조건 상속을 사용하는 것은 위험하다.

핵심 포인트

• 부모 클래스의 규약을 깨뜨리지 않아야 한다.
• 하위 클래스가 부모의 행위를 변경하거나 제약을 위반하지 않아야 한다.

---

4. DIP (Dependency Inversion Principle) — 의존 역전 원칙

“구체적인 클래스가 아니라 추상화에 의존하라.”

정의

• 상위 모듈이 하위 모듈의 세부 구현에 의존하지 않고, **추상화(인터페이스)**에 의존해야 한다.
• 변화에 취약한 구체적 요소보다, 상대적으로 안정적인 추상 계층을 중심으로 설계한다.

예시

 

interface Robot {
    void doWork();
}

class CleaningRobot implements Robot {
    public void doWork() { System.out.println("Cleaning!"); }
}

class Kid {
    private Robot robot;
    public Kid(Robot robot) { this.robot = robot; }
    public void start() { robot.doWork(); }
}

Kid 클래스는 Robot 인터페이스에 의존하므로, CleaningRobot 이외의 로봇으로 쉽게 교체 가능하다.

---

5 ISP (Interface Segregation Principle) — 인터페이스 분리 원칙

“하나의 범용 인터페이스보다는 여러 개의 구체적 인터페이스가 낫다.”

정의

• 클라이언트는 자신이 사용하지 않는 기능에 의존하지 않아야 한다.
• 즉, 인터페이스는 작고 명확하게 분리되어야 한다.

예시

 

interface Printer {
    void print();
}

interface Scanner {
    void scan();
}

// 멀티프린터는 두 인터페이스를 모두 구현할 수 있다.
class MultiDevice implements Printer, Scanner {
    public void print() {}
    public void scan() {}
}

불필요한 메서드 의존을 막고, 각 기능별로 인터페이스를 세분화함으로써 시스템의 결합도를 낮춘다.

---

📍핵심 요약

원칙이름핵심 개념

SRP	단일 책임 원칙	클래스는 하나의 변경 이유만 가져야 한다
OCP	개방-폐쇄 원칙	확장에는 열려 있고, 수정에는 닫혀 있어야 한다
LSP	리스코프 치환 원칙	하위 클래스는 상위 클래스를 완벽히 대체해야 한다
DIP	의존 역전 원칙	구체가 아닌 추상에 의존해야 한다
ISP	인터페이스 분리 원칙	클라이언트 전용 인터페이스를 분리하라

---