객체지향의 5가지 원칙

객체지향의 5가지 원칙(SOLID)

면접용 답변

객체 지향 설계에서는 유지보수성과 확장성을 높이기 위해 SOLID 원칙을 따릅니다. SOLID 원칙은 다섯 가지 개별 원칙으로 구성되며, 각각의 원칙은 코드의 응집도를 높이고 결합도를 낮추어 유연하고 견고한 소프트웨어를 만드는 데 기여합니다.

단일 책임 원칙은 하나의 클래스는 단 하나의 책임만 가져야 한다는 원칙입니다. 즉, 클래스는 변경 이유가 하나만 있어야 합니다.

개방-폐쇄 원칙은 소프트웨어 구성 요소는 확장에는 열려 있고, 수정에는 닫혀 있어야 한다는 원칙입니다. 기존 코드를 변경하지 않고도 기능을 추가할 수 있도록 설계해야 합니다.

리스코프 치환 원칙은 하위 클래스는 상위 클래스를 대체할 수 있어야 한다는 원칙입니다. 즉, 부모 클래스를 사용하는 곳에서 자식 클래스를 넣어도 정상적으로 동작해야 합니다.

인터페이스 분리 원칙은 클라이언트가 사용하지 않는 인터페이스에 의존하지 않도록 해야 한다는 것입니다. 즉, 인터페이스를 기능별로 쪼개어 불필요한 메서드 의존성을 줄여야 합니다.

의존 역전 원칙은 상위 모듈이 하위 모듈에 의존하는 것이 아니라, 추상화된 인터페이스에 의존해야 한다는 것입니다. 즉, 구현 클래스가 아닌 인터페이스를 사용하여 결합도를 낮춰야 합니다.

개념 설명

SOLID 원칙

객체지향 설계에서 지켜줘야 할 5개의 소프트웨어 개발 원칙( SRP, OCP, LSP, ISP, DIP )

• SRP(Single Responsibility Principle): 단일 책임 원칙

• OCP(Open Closed Priciple): 개방 폐쇄 원칙

• LSP(Listov Substitution Priciple): 리스코프 치환 원칙

• ISP(Interface Segregation Principle): 인터페이스 분리 원칙

• DIP(Dependency Inversion Principle): 의존 역전 원칙

-> SOLID 객체 지향 원칙을 적용하면 코드를 확장하고 유지 보수 관리하기가 더 쉬워지며, 불필요한 복잡성을 제거해 리팩토링에 소요되는 시간을 줄임으로써 프로젝트 개발의 생산성을 높일 수 있음

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

• 하나의 클래스는 하나의 역할만 담당해야 함

• 변경이 필요할 때는, 오직 하나의 이유로만 변경되어야 힘

-> 유지보수성을 높이고, 코드의 가독성을 향상시킴

🚨 위반 예제

class ReportGenerator { // 하나의 클래스가 두가지 역할
    void generateReport() {
        // 보고서 생성 로직
    }

    void printReport() {
        // 보고서 출력 로직
    }
}
// ❌ 하나의 클래스가 두가지 역할

✅ 올바른 예제

class ReportGenerator { 
    void generateReport() {
        // 보고서 생성 로직
    }
}

class ReportPrinter {
    void printReport() {
        // 보고서 출력 로직
    }
}
// ⭕️ 두개의 클래스가 각각의 역할 수행

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

• 확장에는 열려 있고, 수정에는 닫혀 있어야 함

• 기존 클래스를 변경하지 않고 새로운 기능을 추가할 수 있도록 설계해야 함

🚨 위반 예제

class PaymentService {
    void pay(String paymentType) {
        if (paymentType.equals("CreditCard")) {
            // 신용카드 결제 로직
        } else if (paymentType.equals("PayPal")) {
            // PayPal 결제 로직
        }
    }
}
// ❌ 새로운 결제 수단 추가 시 기존 코드 수정 필요 → OCP 위반.

✅ 올바른 예제

interface Payment {
    void pay();
}

class CreditCardPayment implements Payment {
    public void pay() {
        System.out.println("Credit Card Payment");
    }
}

class PayPalPayment implements Payment {
    public void pay() {
        System.out.println("PayPal Payment");
    }
}

class PaymentService {
    void processPayment(Payment payment) {
        payment.pay();
    }
}
// ⭕️  새로운 결제 수단이 추가되어도 기존 PaymentService 코드를 수정할 필요 없음

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

• 자식 클래스는 언제나 부모 클래스를 대체할 수 있어야 함

• 부모 클래스를 사용하는 코드가 자식 클래스로 바뀌어도 정상 동작해야 함.

🚨 위반 예제

class Bird {
    void fly() {
        System.out.println("Bird is flying");
    }
}

class Penguin extends Bird {
    void fly() {
        throw new UnsupportedOperationException("Penguins can't fly");
    }
}
// ❌ 펭귄은 날 수 없으므로, Bird 클래스를 상속받으면 문제가 발생 → LSP 위반.

✅ 올바른 예제

interface Bird {
    void move();
}

class FlyingBird implements Bird {
    public void move() {
        System.out.println("Bird is flying");
    }
}

class Penguin implements Bird {
    public void move() {
        System.out.println("Penguin is swimming");
    }
}
// ⭕️ Bird를 FlyingBird와 Penguin으로 분리

4.인터페이스 분리 원칙 (ISP, Interface Segregation Principle)

• 클라이언트가 필요하지 않는 메서드에 의존하지 않아야 함

• 하나의 큰 인터페이스보다는 여러 개의 작은 인터페이스를 분리해야 함

🚨 위반 예제

interface Worker {
    void work();
    void eat();
}

class Robot implements Worker {
    public void work() {
        System.out.println("Robot working");
    }

    public void eat() {
        throw new UnsupportedOperationException("Robot can't eat");
    }
}
// ❌ Robot은 eat() 메서드가 필요 없음 → ISP 위반.

✅ 올바른 예제

interface Workable {
    void work();
}

interface Eatable {
    void eat();
}

class Robot implements Workable {
    public void work() {
        System.out.println("Robot working");
    }
}

class Human implements Workable, Eatable {
    public void work() {
        System.out.println("Human working");
    }

    public void eat() {
        System.out.println("Human eating");
    }
}
// ⭕️ 필요한 인터페이스만 구현

5. 의존 역전 원칙 (DIP, Dependency Inversion Principle)

• 구체적인 구현이 아닌, 추상화(인터페이스)에 의존해야 함

• 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는, 변화하기 어려운 것 거의 변화가 없는 것에 의존하라는 것

• DIP의 지향점은 각 클래스간의 결합도(coupling)을 낮추는 것!

✅ 올바른 예제

interface Notification {
    void send();
}

class EmailNotification implements Notification {
    public void send() {
        System.out.println("Email Sent");
    }
}

class NotificationService {
    private Notification notification;

    public NotificationService(Notification notification) {
        this.notification = notification;
    }

    void notifyUser() {
        notification.send();
    }
}
// ⭕️ 인터페이스를 통해 구현 

---

Reference

https://inpa.tistory.com/entry/OOP-💠-객체-지향-설계의-5가지-원칙-SOLID#