[객체지향프로그래밍] 쉬운 예시와 함께 보는 SOLID 원칙

🔎 주제

객체 지향 프로그래밍에는 'SOLID' 원칙이 있다. Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, Dependency Inversion 이 5가지 원칙을 말하는데 자세한 예시와 함께 5개의 개념을 모두 보고자 한다.

✅ S: 단일 책임 원칙(SRP)

단일 책임 원칙(Single Responsibility, SRP)는 "클래스는 하나의 책임만 가져야 한다"는 원칙이다.

• 책임: 클래스가 처리해야 하는 하나의 변경 이유

쉽게는 클래스가 담당해서 처리해야 하는 하나의 "일"이라고 볼 수 있다. 클래스는 자신이 맡은 특정한 "일"만 처리해야 한다. 하나의 클래스는 단 한가지의 이유로만 변경되어야 한다.

하나의 클래스가 맡는 책임이 많아질수록, 클래스는 복잡해지고 수정과 유지보수가 어려워진다. 한 일을 변경했다가 다른 일에 영향을 끼칠 수 있기 때문이다.

☕ 예시

일상생활을 예시로 생각해보자.

카페에서 직원이 한 명만 있다. 이 직원은 커피를 제조하고, 계산도 하고, 청소도 한다.

한 명의 직원이 여러 업무를 맡고 있다. 만약 커피 제조 레시피가 바뀌고, 포스기 시스템도 바뀌고, 청소 구역도 바뀐다면 적응하기 쉽지 않을 것이다.

• 직원=클래스, 업무=책임, 레시피, 시스템, 구역 바뀜=변경 이유, 적응=클래스 수정/변경이라고 생각해보자.

카페에 직원이 늘었다. 바리스타는 커피를 만들고, 캐셔는 계산을 하고, 청소부는 청소를 한다.

커피 메뉴가 바뀌어도 캐셔와 청소부는 신경쓰지 않는다. 포스기 시스템이 바뀌어도 바리스타와 청소부는 신경쓰지 않는다. 자신의 책임이 아니기 때문이다.

업무 분장(=책임을 나누는 것)이 효율적이고 안정적인 운영을 위한 해답이다.

🖥️ 예시 코드

• 단일 책임 원칙을 지키지 않은 경우

커피 제조와 주문 받기, 두 가지 일을 하고 있다. 이 클래스는 음료 레시피가 바뀌거나, 또는 현금만 받는 등 결제 시스템이 바뀌는 등 두 가지의 이유로 변경될 수 있다.

public class Cafe {

    // 커피 제조
    public Coffee makeCoffee(String menu) {
        if(메뉴=="아메리카노") {
            원두 추출;
            물 따르기;
        } else if(메뉴=="카페라떼") {
            원두 추출;
            우유 스팀하기;
        }
        ...
    }

    // 주문 받기
    public void createOrder(String menu) {
        포스기에서 메뉴 선택;
         ...
    }

}

• 단일 책임 원칙을 지킨 경우

바리스타는 커피 제조를, 캐셔는 결제를 처리한다.

public class Barista {
    // 커피 제조
    public Coffee makeCoffee(String menu) {
        if(메뉴=="아메리카노") {
            원두 추출;
            물 따르기;
        } else if(메뉴=="카페라떼") {
            원두 추출;
            우유 스팀하기;
        }
        ...
    }
}

public class Casher {
    // 주문 받기
    public void createOrder(String menu) {
        포스기에서 메뉴 선택;
         ...
    }
}

각각의 클래스가 명확하게 자신만의 책임을 가지므로 테스트, 수정, 유지보수가 쉬우며 독립적이므로 재사용도 쉽다.

✅ O: 개방-폐쇄 원칙(OCP)

개방-폐쇄 원칙(Open-Closed)은 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다는 원칙이다.

아니.. 단일 책임 원칙에서는 수정하기 쉬워진다면서요? 변경에는 닫혀 있다니, 수정하지 말라는 건가요?

이 원칙은 모든 변경에 대해 말하는 게 아니다. 확장될 때의 변경을 말한다.

기존의 코드를 변경하지 않으면서도 시스템의 기능을 확장할 수 있어야 한다. 개방-폐쇄 원칙에 따르면, 새로운 기능을 추가할 때 기존의 코드에 영향을 주지 않고도 추가할 수 있어야 한다.

요지는, 이미 잘 돌아가던 기존 코드를 확장한다고 건들이지 말고 새로운 요구사항만 구현하라는 뜻이다.

이때 이용하기 좋은 것이 추상화와 인터페이스다. 예시 코드로 보자.

🪙 예시 코드

• 개방 폐쇄 원칙을 지키지 않은 경우

결제 시 고객이 지불해야 하는 가격을 알려야 한다.

public class Casher {
    // 가격 찾기
    public int getPrice(String menu) {
        if(메뉴==아메리카노)
            return 2000;
        else if(메뉴==카페라떼)
            return 3000;
         else if ...
    }
}

만약 여기에서 신메뉴 버블티가 추가된다면? else if()을 추가해야 할 것이다. 신메뉴로 확장되지만 기존 코드가 변경되는 것이다.

• 개방 폐쇄 원칙을 지킨 경우

메뉴가 몇 개가 추가되든 기존의 코드들은 변하지 않는다.

interface Drink {
    int getPrice();
}

class Americano {
    public int getPrice() { return 2000; }
}

class CafeLatte {
    public int getPrice() { return 3000; }
}

class BubbleTea {
    public int getPrice() { return 5000; }
}

개방-폐쇄 원칙은 유연하게 확장이 가능하면서도 기존 코드를 건드리지 않으므로 안정적이다.

✅ L: 리스코프 치환 원칙(LSP)

리스코프 치환 원칙(Liskov Substitution)은 서브 타입은 언제나 그것의 베이스 타입으로 치환될 수 있어야 한다는 원칙이다.

• 서브 타입 = 자식 클래스
• 베이스 타입 = 부모 클래스

부모 클래스의 인스턴스를 사용하는 코드가 자식 클래스로 대체되더라도 프로그램 동작에 문제가 없어야 한다는 의미로 다형성의 안정성을 보장하는 원칙이다. 부모 클래스와 동작 결과가 같아야 한다기 보다는, "부모 클래스의 규칙을 깨지 마라"가 핵심이다.

🕊️ 예시 코드

• 리스코프 치환 원칙을 지키지 않은 경우

부모 클래스 Bird는 새의 비행 동작을 정의한다. 이 클래스에서의 지켜져야 하는 규칙은 "새는 날 수 있다"이다. 새에 포함되는 Penguin은 자식 클래스로 비행 동작을 구현해야 한다.

그런데 펭귄은 날 수 없는 새다! Penguin에서는 비행 동작을 제대로 구현할 수 없다. Bird 인스턴스를 Penguin 인스턴스로 바꾸면 "새는 날 수 있다"는 규칙을 지킬 수 없다.

public abstact class Bird {
    public void fly() {
        System.out.println("날아갑니다.");
    }
}

public class Penguin extends Bird {
    @Override
    public void fly() {
        throw new UnsupportedOperationException("펭귄은 날 수 없습니다.");
    }
}

public class Main {
    public static void main(String[] args) {
        Bird bird = new Bird();
        bird.fly(); // "날아갑니다."

        Bird penguin = new Penguin();
        penguin.fly(); // UnsupportedOperationException 예외 발생
    }
}

• 리스코프 원칙을 지킨 경우

펭귄이라는 반례를 발견했으니 부모 클래스의 "새는 날 수 있다"는 규칙을 깨보자. 다행히 새들 모두 어떻게든 움직일 수는 있다. "새는 움직인다"는 것을 전제로 "날 수 있는 새"와 "움직이는 새(날 수 없는 새)"로 분리해보자.

아래 예시에서는 FlyingBird와 Penguin 클래스가 부모의 클래스 Bird의 규칙 "새는 움직인다"를 잘 지키고, 메인 클래스에서 Bird 인스턴스를 FlyingBird, Penguin 인스턴스로 바꿔도 문제 없이 동작한다.

// 새의 공통 동작을 정의하는 상위 클래스
abstract class Bird {
    public abstract void move(); // 모든 새가 이동할 수 있음
}

// 날 수 있는 새
class FlyingBird extends Bird {
    public void fly() {
        System.out.println("날아갑니다!");
    }

    @Override
    public void move() {
        fly(); // 날아 이동
    }
}

// 펭귄은 날지 못하는 새
class Penguin extends Bird {
    @Override
    public void move() {
        System.out.println("헤엄칩니다!");
    }
}

public class Main {
    public static void main(String[] args) {
        Bird sparrow = new FlyingBird(); // 참새는 날 수 있음
        sparrow.move(); // "날아갑니다!"

        Bird penguin = new Penguin(); // 펭귄은 헤엄침
        penguin.move(); // "헤엄칩니다!"
    }
}

리스코프 치환 원칙을 지키면 다형성을 활용한 코드에서 문제 발생을 방지할 수 있다. 부모 클래스의 규칙을 위반한 자식 클래스의 예상하지 못한 오류를 막자.

✅ I: 인터페이스 분리 원칙(ISP)

인터페이스 분리 원칙(Interface Segregation)은 인터페이스는 클라이언트가 사용하지 않는 메서드에 의존하지 않도록 설계해야 한다는 원칙이다.

• 의존이란? 한 클래스나 모듈이 다른 클래스나 모듈에 필요한 자원을 사용하거나 기능을 수행하기 위해 해당 클래스나 모듈에 직접적인 영향을 받는 관계이다.

하나의 큰 인터페이스를 여러 개의 작은 인터페이스로 나눠서, 특정 클라이언트가 자신에게 필요 없는 기능은 구현하지 않고, 자신이 필요한 기능만 사용할 수 있도록 하자.

바로 예시를 보는 게 낫다.

🖨️ 예시 코드

• 인터페이스 분리 원칙을 지키지 않은 경우

프린트, 스캔, 팩스 기능이 있는 복합기가 있다. 이 복합기로부터 유래한 프린터를 하나 만들고 싶다. 프린터에는 오직 프린트 기능만 있다.

SimplePrinter 클래스는 오직 프린터로서만 동작하면 되는데 Device 인터페이스 때문에 자기에게 필요도 없는 스캔과 팩스까지 구현해야 한다. 결과는 당연히 예외 발생이다.

public interface Device {
    void print(String content);
    void scan(String content);
    void fax(String content);
}

//프린터는 프린트 밖에 못하는데 스캔과 팩스도 반드시 구현해야 함
public class SimplePrinter implements Device {
    @Override
    public void print(String content) {
        System.out.println("Printing: " + content);
    }

    @Override
    public void scan(String content) {
        throw new UnsupportedOperationException("Scan not supported by this device.");
    }

    @Override
    public void fax(String content) {
        throw new UnsupportedOperationException("Fax not supported by this device.");
    }
}

• 인터페이스 분리 원칙을 지킨 경우

Device라는 하나의 큰 인터페이스를 쪼개자. 다양한 클라이언트가 각자 필요한 인터페이스만 구현할 수 있다.

// 인터페이스 분리
public interface Fax {
    void fax(String content);
}

public interface Printer {
    void print(String content);
}

public interface Scanner {
    void scan(String content);
}

//단순 프린터
public class SimplePrinter implements Printer{
    @Override
    public void print(String content) {
        System.out.println("Printing : " + content);
    }
}

// 복합기
public class MultifunctionDevice implements Printer, Scanner, Fax{

    @Override
    public void print(String content) {
        System.out.println("MultiDevice printing: " + content);
    }

    @Override
    public void scan(String content) {
        System.out.println("MultiDevice scanning: " + content);
    }

    @Override
    public void fax(String content) {
        System.out.println("MultiDevice faxing: " + content);
    }
}

클라이언트가 불필요한 메서드 구현을 강제받지 않고, 큰 인터페이스를 수정할 때, 사용하지 않는 클라이언트에도 영향을 미칠 가능성이 줄어들기 때문에 클래스 간 의존성도 감소한다.

✅ D: 의존 역전 원칙(DIP)

의존 역전 원칙(Dependency Inversion)은 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화 인터페이스에 의존해야 한다는 원칙이다.

• 고수준과 저수준? 고수준 모듈은 시스템의 비즈니스 로직과 전반적인 동작을 설계하는 추상적인 부분이다. 저수준 모듈은 데이터 저장, 하드웨어와의 상호작용 등 상위 모듈이 원하는 실질적인 작업을 수행하는 구체적으로 구현하는 모듈이다.

📚 예시 코드 1

주문을 처리하고 데이터베이스에 주문 데이터를 저장하자.

• 의존 역전 원칙을 지키지 않은 경우

OrderService 클래스는 '주문'이라는 비즈니스 로직을 처리하는 고수준 모듈이다. MySQLOrderRepository 클래스는 주문 데이터를 실질적으로 저장하기 위한 저수준 모듈이다.

만약 데이터베이스를 바꾸고 싶다면, MySQL 데이터베이스에 의존하던 고수준 모듈OrderService 클래스를 수정해야 한다.

// 저수준 모듈 -> 데이터베이스(MySQL)를 사용하여 데이터를 저장
// 구체적인 저장 방식(데이터베이스 기술)을 구현한 클래스
public class MySQLOrderRepository {
    public void save(String orderData) {
        System.out.println("[MySQL] Order saved: " + orderData);
    }
}

// 주문이라는 비즈니스 로직을 구현한 고수준 모듈
public class OrderService {
    // 고수준 모듈인데, 저수준에 의존
    // : MySQL이라는 특정 DB에 대해서만 영향을 받음. 만약 DB 종류가 바뀌면 OrderService 코드를 수정해야 함.
    private MySQLOrderRepository repository = new MySQLOrderRepository();

    public void createOrder(String orderData) {
        System.out.println("Creating order...");
        repository.save(orderData); // 구체 클래스에 의존
    }
}

public class Main {
    public static void main(String[] args) {
        OrderService orderService = new OrderService();
        orderService.createOrder("Order #1234");
    }
}

• 의존 역전 원칙을 지킨 경우

데이터베이스에 주문 데이터를 저장하는 것을 인터페이스로 바꾸자. 인터페이스 OrderRepository를 구현하는 클래스들이 각 데이터베이스 모듈이다. OrderService는 이 인터페이스만 이용하면 되고, 메인 클래스에서 의존성을 주입하면 된다. 새로운 데이터베이스를 추가해도, 데이터베이스를 바꾸고 싶어도 OrderService는 수정하지 않아도 된다.

//추상화 계층
public interface OrderRepository {
    void save(String orderData);
}

// MySQL 저수준 모듈
public class MySQLOrderRepository implements OrderRepository{
    @Override
    public void save(String orderData) {
        System.out.println("[MYSQL] order saved: " + orderData);
    }
}

//OracleDB 저수준 모듈
public class OracleOrderRepository implements OrderRepository{
    @Override
    public void save(String orderData) {
        System.out.println("[ORACLE] order saved: " + orderData);
    }
}

public class OrderService {
    // 고수준 모듈

    // 추상 인터페이스에 의존
    private OrderRepository repository;

    // 생성자 주입
    public OrderService(OrderRepository repository) {
        this.repository = repository;
    }

    public void createOrder(String orderData) {
        System.out.println("Creating order >>>");
        repository.save(orderData);
    }

}

public class Main {
    public static void main(String[] args) {
        // MySQL 사용
        OrderRepository mySql = new MySQLOrderRepository();
        OrderService mySqlOrder = new OrderService(mySql);
        mySqlOrder.createOrder("Order from MYSQL DB");

        // Oracle 로 교체
        OrderRepository oracle = new OracleOrderRepository();
        OrderService oracleOrder = new OrderService(oracle);
        oracleOrder.createOrder("Order from ORACLE DB");
    }
}

📩 예시 코드 2

고객에게 신상품 알림을 보내자. 알림은 이메일과 문자(SMS)로 보낼 수 있다.

• 의존 역전 원칙을 지키지 않은 경우

NotificationService 클래스는 고객에게 두 가지 방식으로 알림을 보내는 '알림 전송' 기능을 구현해야 한다. EmailSender와 SmsSender 클래스는 각각 실제로 고객에게 이메일 또는 문자를 보낸다.

만약 모바일 어플로도 보내려면, 해당 클래스를 만들고 NotificationService에서 인스턴스를 만들고, sendNotification() 메소드를 수정해야 한다.

class EmailSender {
    public void sendEmail(String message) {
        System.out.println("이메일 전송: " + message);
    }
}

class SmsSender {
    public void sendSms(String message) {
        System.out.println("SMS 전송: " + message);
    }
}

class NotificationService {
    private EmailSender emailSender = new EmailSender();
    private SmsSender smsSender = new SmsSender();

    public void sendNotification(String message) {
        emailSender.sendEmail(message);
        smsSender.sendSms(message);
    }
}

public class Main {
    public static void main(String[] args) {
        NotificationService notificationService = new NotificationService();
        notificationService.sendNotification("의존 역전 원칙 테스트");
    }
}

• 의존 역전 원칙을 지킨 경우

모든 실질적인 알림 전송 저수준 모듈이 인터페이스 MessageSender를 구현한다. 고수준 모듈 NotificationService 클래스는 모바일 어플 알림까지 추가 되어도 코드를 수정할 필요가 없다.

// 추상화: 알림 발송 인터페이스
interface MessageSender {
    void send(String message);
}

// 구체적 구현: 이메일 발송
class EmailSender implements MessageSender {
    @Override
    public void send(String message) {
        System.out.println("이메일 전송: " + message);
    }
}

// 구체적 구현: SMS 발송
class SmsSender implements MessageSender {
    @Override
    public void send(String message) {
        System.out.println("SMS 전송: " + message);
    }
}

// 구체적 구현: 모바일 어플 알림
class AppSender implements MessageSender {
    @Override
    public void send(String message) {
        System.out.println("앱 알림: " + message);
    }
}

// 상위 모듈: 알림 서비스
class NotificationService {
    private final List<MessageSender> senders;

    public NotificationService(List<MessageSender> senders) {
        this.senders = senders;
    }

    public void sendNotification(String message) {
        senders.forEach(sender -> sender.send(message));
    }
}

public class Main {
    public static void main(String[] args) {
        // 필요한 발송 방식을 추가
        List<MessageSender> senders = Arrays.asList(new EmailSender(), new SmsSender(), new AppSender());

        NotificationService notificationService = new NotificationService(senders);
        notificationService.sendNotification("의존 역전 원칙 테스트");
    }
}

이처럼 구체적인 구현이 변경되어도 더 이상 고수준 모듈의 코드는 변하지 않는다. 고수준 모듈이 인터페이스에 의존하고, 저수준 모듈에 의존하지 않는다.

🔑 요약

• 단일 책임 원칙
  • "클래스는 하나의 책임만 가져야 한다."
  • 하나의 클래스는 단 한가지의 이유로만 변경되어야 한다.
  • ✅ 유지보수: 코드 변경이 필요한 이유가 분리되고 명확하여 수정이 쉽다.
  • ✅ 재사용성: 각 클래스가 독립적이므로 나중에 해당 기능이 필요한 상황에서 쉽게 재사용이 가능하다.
  • ✅ 테스트: 한 가지 일을 잘하는지 테스트하면 되니 쉽다.
• 개방-폐쇄 원칙
  • "확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다."
  • ✅ 안정성: 기존 코드를 건드리지 않으니, 이미 잘 돌아가던 기능은 에러가 나지 않는다.
  • ✅ 유연성, 확장성: 새로운 기능을 쉽게 추가하기 편하다.
  • 추상화와 인터페이스를 잘 활용하자!
• 리스코프 치환 원칙
  • "서브타입은 언제나 그것의 베이스타입으로 교체할 수 있어야 한다."
  • 자식 클래스는 부모 클래스의 기능을 대체하더라도 동작해야 한다.
  • ✅ 다형성의 안정성: 부모 클래스의 규칙을 자식 클래스도 지켜서 다형성을 지키자. 다형성은 확장과 유지보수를 위한 유용한 개념이다.
• 인터페이스 분리 원칙
  • "클라이언트는 자신이 사용하지 않는 메서드에 의존하지 않아야 한다."
  • 하나의 큰 인터페이스를 여러 개의 작은 인터페이스로 나눠서, 특정 클라이언트가 자신이 필요한 기능만 사용할 수 있도록 설계하자.
  • ✅ 유지보수: 큰 인터페이스를 수정할 때, 사용하지 않는 클라이언트에 영향이 가지 않는다.
  • ✅ 유연성: 클라이언트가 각자 필요한 인터페이스만 구현할 수 있다.
• 의존 역전 원칙
  • "고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화된 인터페이스에 의존해야 한다."
  • 고수준 모듈: 비즈니스 로직과 전반적인 동작을 설계하는 모듈
  • 저수준 모듈: 상위 모듈이 원하는 실질적인 작업을 수행하는 구체적으로 구현하는 모듈
  • ✅ 유지보수성: 저수준 모듈의 구체적인 구현이 변경되도 고수준 모듈은 영향받지 않는다.
  • ✅ 확장성: 고수준 모듈을 구현하기 위해 새로운 저수준 모듈이 필요해도 인터페이스를 이용하면 고수준 모듈은 수정할 필요가 없다.

이처럼 SOLID 원칙은 객체 지향 프로그래밍을 더욱 효과적으로 수행하기 위한 원칙으로 이루어져 있다. 하지만 엄격히 지켜야 하는 원칙보다는 적절히 상황에 맞게 활용하는 "도구"라는 것을 잊지 않아야 한다. 무조건적인 원칙 적용보다는 왜 이 원칙을 적용해야 할까?를 고민해보기를.