SOLID 원칙 (SOLID Principles)

SOLID는 로버트 마틴(Robert C. Martin)이 정리한 객체지향 설계의 다섯 가지 원칙, 즉 단일 책임 원칙(SRP), 개방 폐쇄 원칙(OCP), 리스코프 치환 원칙(LSP), 인터페이스 분리 원칙(ISP), 의존관계 역전 원칙(DIP)의 머리글자를 딴 것이다. SOLID 원칙을 따르면 변경에 강하고 이해하기 쉬우며 재사용 가능한 코드를 만들 수 있어, 대부분의 디자인 패턴이 이 원칙들 위에 서 있다.

단일 책임 원칙(Single Responsibility Principle)

하나의 클래스는 하나의 책임만 가져야 하며, 클래스를 변경할 이유는 단 하나여야 한다는 원칙이다. 여기서 책임은 "변경을 요구하는 액터(actor)"를 기준으로 판단한다. 예를 들어 주문 처리, 영수증 출력, 데이터베이스 저장을 한 클래스가 모두 맡으면, 회계팀의 요구와 인프라팀의 요구가 같은 클래스를 서로 다른 이유로 수정하게 되어 충돌한다.

// 위반: 세 가지 변경 이유가 한 클래스에 있다
public class OrderManager {
    public void processOrder() { /* 주문 로직 */ }
    public void printReceipt() { /* 출력 형식 */ }
    public void saveToDb() { /* 저장 기술 */ }
}

// 준수: 책임별로 분리
public class OrderProcessor { public void process() { } }
public class ReceiptPrinter { public void print() { } }
public class OrderRepository { public void save() { } }

개방 폐쇄 원칙(Open-Closed Principle)

소프트웨어 요소는 확장에는 열려 있고 수정에는 닫혀 있어야 한다는 원칙이다. 새 기능이 추가될 때 기존 코드를 고치는 것이 아니라 새 코드를 추가하는 것으로 대응할 수 있어야 한다는 뜻이며, 추상화와 다형성이 그 수단이다.

// 위반: 결제 수단이 늘 때마다 이 메서드를 수정해야 한다
public int fee(String method) {
    if (method.equals("CARD")) return 300;
    else if (method.equals("BANK")) return 100;
    return 0;
}

// 준수: 인터페이스를 확장 지점으로 삼는다
public interface PaymentMethod {
    int fee();
}
public class CardPayment implements PaymentMethod {
    public int fee() { return 300; }
}
// 새 결제 수단은 클래스 추가만으로 지원된다

전략 패턴, 팩토리 메서드 패턴, 옵저버 패턴은 모두 OCP를 실현하는 대표적인 구조다.

리스코프 치환 원칙(Liskov Substitution Principle)

하위 타입의 객체는 상위 타입의 객체를 대체해도 프로그램의 정확성이 깨지지 않아야 한다는 원칙이다. 상속은 문법적으로 가능하다고 옳은 것이 아니라, 하위 클래스가 상위 클래스의 계약(사전 조건, 사후 조건, 불변식)을 지킬 때만 옳다. 고전적 반례가 직사각형과 정사각형이다.

public class Rectangle {
    protected int width, height;
    public void setWidth(int w) { this.width = w; }
    public void setHeight(int h) { this.height = h; }
    public int area() { return width * height; }
}

// 위반: 정사각형은 너비와 높이를 독립적으로 바꿀 수 없다
public class Square extends Rectangle {
    @Override
    public void setWidth(int w) { this.width = w; this.height = w; }
    @Override
    public void setHeight(int h) { this.width = h; this.height = h; }
}

// 클라이언트의 기대가 깨진다
Rectangle r = new Square();
r.setWidth(5);
r.setHeight(4);
// r.area()가 20이길 기대하지만 16이 나온다

하위 클래스에서 예외를 던지며 기능을 막거나, 오버라이드로 동작 의미를 바꾸는 것이 전형적인 위반 신호다. 이런 경우 상속 대신 합성이나 인터페이스 재설계를 검토해야 한다.

// 위반: 단순 프린터도 fax를 구현해야 한다
public interface AllInOneMachine {
    void print();
    void scan();
    void fax();
}

// 준수: 역할별로 분리하고 필요한 것만 구현한다
public interface Printer { void print(); }
public interface Scanner { void scan(); }

public class SimplePrinter implements Printer {
    public void print() { }
}
public class MultiFunctionMachine implements Printer, Scanner {
    public void print() { }
    public void scan() { }
}

// 위반: 고수준 서비스가 구체 클래스에 직접 의존
public class ReportService {
    private final MySqlReportDao dao = new MySqlReportDao();
}

// 준수: 추상에 의존하고 구현은 외부에서 주입받는다
public interface ReportDao {
    List<Report> findAll();
}

public class ReportService {
    private final ReportDao dao;

    public ReportService(ReportDao dao) {  // 의존성 주입
        this.dao = dao;
    }
}