📚 SOLID

객체 지향 프로그래밍(OOP)에서 소프트웨어 설계를 더 이해하기 쉽고, 유연하며, 유지보수가 용이하도록 만드는 다섯 가지 원칙

1) SRP(Single Responsibility Principle )

• 단일 책임 원칙
• 한 클래스는 하나의 책임만 가져야 한다.

SRP를 따르지 않는 예시

public class Product {
    public void addProduct() {
        // 물건 추가 로직
    }
    
    public void displayProduct() {
        // 물건 정보 출력 로직
    }
}

• Product 클래스가 물건 추가와 정보 출력 두 가지 책임을 모두 담당

SRP를 따르는 예시

public class Product {
    public void addProduct() {
        // 물건 추가 로직
    }
}

public class ProductDisplay {
    public void displayProduct(Product product) {
        // 물건 정보 출력 로직
    }
}

• Product 클래스는 물건 추가만, ProductDisplay 클래스는 물건 정보 출력만 담당

SRP를 준수하면 한 기능에 대한 변경이 다른 기능에 영향을 미치는 일이 줄어들고, 코드의 가독성과 유지 보수성이 향상되며, 테스트하기도 더 쉬워진다.

2) OCP(Open Closed Principle)

확장에 대해서는 개방적(Open)이고, 수정에 대해서는 폐쇄적(closed)이어야 한다.

• 개방-폐쇄 원칙
• 기존의 코드를 변경하지 않으면서, 기능을 추가할 수 있도록 설계해야한다.

OCP를 따르지 않는 예시

class Shape {

    private String type;
  
    public Shape(String type) {
        this.type = type;
    }
  
    public void draw() {
        if (type.equals("circle")) {
            drawCircle();
        } else if (type.equals("rectangle")) {
            drawRectangle();
        } 
    }
  
    private void drawCircle() {
        System.out.println("원을 그립니다.");
    }
  
    private void drawRectangle() {
        System.out.println("사각형을 그립니다.");
    }
}

• 기능(type)을 추가를 하러면 draw 메서드()를 수정 -> 기존 코드를 수정해야하므로 OCP 위반

OCP를 따르는 예시

interface Shape {
    void draw();
}

class Circle implements Shape {
    public void draw() {
        System.out.println("원을 그립니다.");
    }
}

class Rectangle implements Shape {
    public void draw() {
        System.out.println("사각형을 그립니다.");
    }
}

// 새로운 도형을 추가해도 기존 코드 수정 없이 확장 가능!
class Triangle implements Shape {
    public void draw() {
        System.out.println("삼각형을 그립니다.");
    }
}

• 새로운 도형을 추가하더라도 기존 Shape 클래스를 수정할 필요가 없음
• Shape 클래스는 확장(Extension)에는 열려 있고, 변경(Modification)에는 닫혀 있음

---

3) LSP(Liskov Substitution Principle)

부모 객체와 자식 객체가 있을 때 부모 객체를 호출하는 동작에서 자식 객체가 부모 객체를 완전히 대체할 수 있다는 원칙

• 리스코프 치환 원칙

LSP를 위반한 예시

// 부모 클래스: Rectangle(직사각형)
class Rectangle {
    protected int width;
    protected int height;
  
    public void setWidth(int width) {
        this.width = width;
    }
  
    public void setHeight(int height) {
        this.height = height;
    }
  
    public int getWidth() {
        return width;
    }
  
    public int getHeight() {
        return height;
    }
  
    public int getArea() {
        return width * height;
    }
}

// 자식 클래스: Square (정사각형)
// Rectangle을 상속하면서, 정사각형의 특성(너비와 높이가 항상 동일)을 강제하기 위해 오버라이딩 함
class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        super.setWidth(width);
        super.setHeight(width); // 너비가 바뀌면 높이도 변경
    }
  
    @Override
    public void setHeight(int height) {
        super.setWidth(height); // 높이가 바뀌면 너비도 변경
        super.setHeight(height);
    }
}

public class Main {
    public static void main(String[] args) {

        Rectangle rectangle = new Rectangle();
        rectangle.setHeight(5);
        rectangle.setWidth(10);

        System.out.println(rectangle.getArea());
        
        // --------------------------------------
        
        Rectangle square = new Square();
        
        square.setHeight(5);
        square.setWidth(10);



        System.out.println(square.getArea());
        

    }
    
} 

50
25

• 리스코프 치환 원칙은 부모 객체를 호출하는 동작에서 자식 객체가 부모 객체를 완전히 대체 할 수 있다는 원칙 -> 같은 값이 나와야함
• 클라이언트는 부모 객체인 Rectangle처럼 동작할 것으로 기대했지만, Square는 내부적으로 정사각형의 제약 조건을 적용해 의도와 다른 결과가 나오는 것
• 쉽게 말해서 자식클래스(Square)가 부모 클래스(Rectangle)로 완전히 대체 불가능

😥 이는 바로 정사각형이 직사각형을 상속 받는 것이 올바른 상속 관계가 아니라는 것을 의미! 자식 객체가 부모 객체의 역할을 완전히 대체하지 못한다는 의미한다.

LSP를 적용 예시

public class Shape {

    public int width;
    public int height;


    public int getWidth() {
        return width;
    }

    public void setWidth(int width) {
        this.width = width;
    }


    public int getHeight() {
        return height;
    }

    public void setHeight(int height) {
        this.height = height;
    }


    public int getArea() {
        return width * height;
    }
}

//직사각형 클래스
public class Rectangle extends Shape {

    public Rectangle(int width, int height) {
        setWidth(width);
        setHeight(height);
    }

}

//정사각형 클래스
public class Square extends Shape{
    
    public Square(int length) {
        setWidth(length);
        setHeight(length);
    }
    
}

public class Main {
    public static void main(String[] args) {
    
        Shape rectangle = new Rectangle(10, 5);
        Shape square = new Square(5);
        
        System.out.println(rectangle.getArea());
        System.out.println(square.getArea());
    }
}

50
25

• 클라이언트는 부모 클래스인 Shape 타입으로 객체를 다루므로, 구체적인 도형이 Rectangle인지 Square인지 몰라도 동일한 방식으로 사용
• 자식클래스(Rectangle, Square)가 부모 클래스(Shape)로 완전히 대체될 수 있음을 보여준다.

첫번째의 직사각형 클래스를 상속받은 정사각형 객체 예제처럼, 올바르지 못한 상속관계는 제거하고 부모 객체의 동작을 완벽히 대체할 수 있는 관계만 상속하도록 코드를 설계

4) ISP(Interface Segregation Principle)

• 객체는 자신이 사용하는 메서드에만 의존해야 한다는 법칙
• 객체가 사용하지 않는 메서드를 의존해서는 안 된다는 뜻

• 인터페이스 분리 원칙

ISP를 위반한 예시

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

class HumanEmployee implements Employee {
    @Override
    public void work() {
        // 작업하는 코드
    }

    @Override
    public void eat() {
        // 식사하는 코드
    }
}

class AIEmployee implements Employee {
    @Override
    public void work() {
        // 작업하는 코드
    }

    @Override
    public void eat() {
        // AI은 먹지 않지만 인터페이스를 구현해야 함
        throw new UnsupportedOperationException("로봇은 먹지 않습니다.");
    }
}

• AIEmployee 클래스는 eat 메서드를 구현할 필요가 없지만, 인터페이스를 구현 -> ISP 위반

ISP 적용 예시

// 작업하는 기능을 정의한 인터페이스
interface Workable {
    void work();
}

// 식사하는 기능을 정의한 인터페이스
interface Eatable {
    void eat();
}

class HumanEmployee implements Workable, Eatable {
    @Override
    public void work() {
        // 작업하는 코드
    }

    @Override
    public void eat() {
        // 식사하는 코드
    }
}

class AIEmployee implements Workable {
    @Override
    public void work() {
        // 작업하는 코드
    }
}

• 이렇게 하면 AIEmployee 클래스가 불필요한 메서드를 구현할 필요가 없으며, ISP를 준수하게 된다.

5) DIP(Dependency Inversion Principle)

• 고수준 모듈은 저수준 모듈의 구현에 의존해서는 안 된다.
• 구체화에 의존하지 말고, 추상화에 의존해라.
  -> 자신보다 변하기 쉬운 것에 의존하지 마라

• 의존성 역전 원칙

DIP 위반 예시

public class Driver {
    private Lamborghini car;

    public void setLamborghini(Lamborghini car) {
        this.lamborghini = car;
    }

    public void drive() {
        System.out.println(car.toString());
    }
}

public class Main {
    public static void main(String[] args) {
        Lamborghini myLamborghini = new Lamborghini();
        Driver driver = new Driver();
        driver.setLamborghini(myLamborghini);
        driver.drive();
    }
}

• 위 상황에서 Driver는 람보르기니라는 구체적인 객체에 의존하고 있다. 이 경우 운전자가 운전하는 자동차의 종류가 변경될 때, 다음과 같이 Driver 클래스를 수정해야한다.

public class Driver {
    private Lamborghini car;
    private Ferrari car
    
    // 운전자가 운전하는 자동차 브랜드 종류만큼 Driver 클래스 내에 메서드가 존재해야함.
    public void setLamborghini(Lamborghini car) {
        this.lamborghini = car;
    }
    
     public void setLamborghini(Ferrari car) {
        this.Ferrari = car;
    }

    public void drive() {
        System.out.println(car.toString());
    }
}

• 이렇게 운전자라는 고수준 모듈이, 변하기 쉬운 자동차라는 저수준 모듈에게 의존하면 영향에 직접적으로 노출, 자동차를 하나 더 추가하기 위해 Driver 클래스에 수정까지 일어나기 때문

DIP 적용 예시

// Car 인터페이스: 추상화 계층을 정의
public interface Car {
    String toString();
}

// Driver 클래스는 구체적인 자동차 대신 추상화된 Car에 의존함
public class Driver {
    private Car car;

    public void setCar(Car car) {
        this.car = car;
    }

    public void drive() {
        System.out.println(car.toString());
    }
    
}

// Lamborghini 클래스는 Car 인터페이스를 구현
public class Lamborghini implements Car {
    @Override
    public String toString() {
        return "Lamborghini car";
    }
}

// Ferrari 클래스는 Car 인터페이스를 구현
public class Ferrari implements Car {
    @Override
    public String toString() {
        return "Ferrari car";
    }
}


public class Main {
    public static void main(String[] args) {
        // Ferrari 자동차를 사용한 예시
        Car myFerrari = new Ferrari();
        Driver driver = new Driver();
        driver.setCar(myFerrari);
        driver.drive();
        
        // Lamborghini 자동차를 사용한 예시
        Car myLamborghini = new Lamborghini();
        driver.setCar(myLamborghini);
        driver.drive();
    }
}

• 새로운 자동차를 추가했지만 Driver클래스는 코드에 어떠한 변화도 일어나지 않고, 어떠한 영향도 미치지 않는다.

OCP와 DIP의 차이점

특징	OCP (Open-Closed Principle)	DIP (Dependency Inversion Principle)
목적	기능 확장은 허용하되 기존 코드는 수정하지 않음	상위 모듈이 하위 모듈에 직접 의존하지 않고 추상화에 의존
초점	코드 변경 없이 확장 가능한 구조 설계	모듈 간 결합도를 낮추고 유연성과 테스트 용이성을 확보
방법	다형성과 인터페이스를 활용하여 확장 가능하도록 설계	인터페이스나 추상 클래스를 통해 의존성 역전 구현
적용 범위	개별 클래스/모듈 수준	여러 모듈 간 관계 및 의존성 관리
예시	새로운 기능 추가 시 기존 클래스 대신 새로운 클래스를 작성	인터페이스를 통해 상위/하위 모듈 간 결합도를 낮춤

참고 :

• 완벽하게 이해하는 OCP (개방 폐쇄 원칙)

• OCP란?(Open-Closed Principle, 계방 폐쇄 원칙이란?, 계방 폐쇄 원칙 예제) 간단하고 쉽게 이해하기

• [OOP] 객체지향 5대 원칙(SOLID) - 리스코프 치환 원칙 (LSP)

• [OOP] 객체지향 5대 원칙(SOLID) - 의존성 역전 원칙 (DIP)