Java - SOLID 5원칙이란?

 

Java에서의 SOLID 원칙은 객체 지향 프로그래밍의 다섯 가지 설계 원칙을 의미합니다. 

이 원칙은 소프트웨어 설계의 유연성, 유지보수성, 확장성을 높이기 위해 사용됩니다.

---

1. 단일 책임 원칙 (Single Responsibility Principle - SRP):
   - 한 클래스는 단 하나의 책임만 가져야 합니다.
   - 상황 예시: 예를 들어, 게시글 관리 클래스가 게시글 작성, 읽기, 수정, 삭제 등의 여러 기능을 수행하는 대신, 각각의 책임을 분리하여 게시글 작성, 게시글 읽기, 게시글 수정, 게시글 삭제를 각각의 클래스로 나눌 수 있습니다.

각 SOLID 원칙에 대한 상황 예시와 코드를 함께 설명해드리겠습니다.

아래는 게시글 관리 클래스가 단일 책임 원칙을 지키지 않는 경우를 보여줍니다.

// 게시글 관리 클래스
public class PostManager {
    public void createPost(String content) {
        // 게시글 생성 로직
    }

    public void readPost(int postId) {
        // 게시글 조회 로직
    }

    public void updatePost(int postId, String newContent) {
        // 게시글 수정 로직
    }

    public void deletePost(int postId) {
        // 게시글 삭제 로직
    }
}

이 클래스는 게시글의 생성, 조회, 수정, 삭제와 같은 여러 기능을 모두 포함하고 있어 단일 책임 원칙을 위배합니다. 

아래는 단일 책임 원칙을 준수하는 예시입니다.

// 게시글 생성 클래스
public class PostCreator {
    public void createPost(String content) {
        // 게시글 생성 로직
    }
}

// 게시글 조회 클래스
public class PostReader {
    public void readPost(int postId) {
        // 게시글 조회 로직
    }
}

// 게시글 수정 클래스
public class PostUpdater {
    public void updatePost(int postId, String newContent) {
        // 게시글 수정 로직
    }
}

// 게시글 삭제 클래스
public class PostDeleter {
    public void deletePost(int postId) {
        // 게시글 삭제 로직
    }
}

위 코드에서 각 클래스는 하나의 책임만을 가지고 있으며, 게시글 생성, 조회, 수정, 삭제 기능이 분리되어 있습니다.

---

2. 개방-폐쇄 원칙 (Open-Closed Principle - OCP):
   - 소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에는 열려 있어야 하지만, 수정에는 닫혀 있어야 합니다.
   - 상황 예시: 새로운 기능을 추가할 때 기존의 코드를 수정하지 않고 확장만으로 새로운 기능을 구현할 수 있도록 설계합니다. 예를 들어, 도형 클래스에 새로운 도형을 추가할 때, 도형 클래스를 수정하지 않고 새로운 도형 클래스를 추가하여 기존 도형 클래스에 영향을 주지 않고 기능을 확장할 수 있습니다.

도형 클래스에 새로운 도형을 추가할 때 OCP를 준수하지 않는 경우입니다.

// 도형 클래스
public class Shape {
    public void draw() {
        // 도형을 그리는 기본 로직
    }
}

위 클래스는 새로운 도형을 추가하기 위해 기존 코드를 수정해야 하는 문제가 있습니다. 

아래는 OCP를 준수하는 방법입니다.

// 도형 인터페이스
public interface Shape {
    void draw();
}

// 원 클래스
public class Circle implements Shape {
    @Override
    public void draw() {
        // 원을 그리는 로직
    }
}

// 사각형 클래스
public class Rectangle implements Shape {
    @Override
    public void draw() {
        // 사각형을 그리는 로직
    }
}

새로운 도형을 추가할 때 기존 코드를 수정하지 않고도 인터페이스를 구현하여 확장할 수 있습니다.

---

3. 리스코프 치환 원칙 (Liskov Substitution Principle - LSP):
   - 하위 클래스는 상위 클래스를 대체할 수 있어야 합니다.
   - 상황 예시: 상속 관계에서 서브 클래스는 슈퍼 클래스의 기능을 포함하고 있어야 하며, 상속 관계에서 부모 클래스 타입으로 사용되는 곳에서도 문제 없이 자식 클래스를 사용할 수 있어야 합니다.
아래는 리스코프 치환 원칙을 어긴 경우입니다.

// 직사각형 클래스
public 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 calculateArea() {
        return this.width * this.height;
    }
}

// 정사각형 클래스
public class Square extends Rectangle {
    @Override
    public void setWidth(int width) {
        this.width = width;
        this.height = width;
    }

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

위 코드에서 정사각형(Square)은 직사각형(Rectangle)의 특수한 형태로 구현되었지만, 이는 LSP를 위배합니다. 

이러한 문제를 해결하기 위해 아래와 같이 코드를 수정할 수 있습니다.

// 도형 인터페이스
public interface Shape {
    int calculateArea();
}

// 직사각형 클래스
public class Rectangle implements Shape {
    protected int width;
    protected int height;

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

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

    @Override
    public int calculateArea() {
        return this.width * this.height;
    }
}

// 정사각형 클래스
public class Square implements Shape {
    private int side;

    public void setSide(int side) {
        this.side = side;
    }

    @Override
    public int calculateArea() {
        return this.side * this.side;
    }
}

이제 정사각형과 직사각형은 각자의 특성에 맞게 독립적으로 구현되어 있으며, 상속 관계에서 발생하는 문제를 해결했습니다.

---

4. 인터페이스 분리 원칙 (Interface Segregation Principle - ISP):
   - 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않아야 합니다.
   - 상황 예시: 큰 인터페이스를 여러 개의 작은 인터페이스로 분리하여 클라이언트가 필요한 기능에만 의존하도록 설계합니다. 예를 들어, 인터페이스를 통해 음악 재생, 일시 정지, 정지 등의 기능을 각각 분리하여 필요한 기능만 사용할 수 있도록 합니다.

아래는 인터페이스 분리 원칙을 위반한 예시입니다.

// 작업 인터페이스
public interface Workable {
    void work();
    void eat();
}

// 로봇 클래스
public class Robot implements Workable {
    @Override
    public void work() {
        // 로봇의 작업 기능
    }

    @Override
    public void eat() {
        // 로봇의 식사 기능
    }
}

위 코드에서 인터페이스에 있는 eat() 메서드는 로봇에게는 적용되지 않는 기능입니다. 

이를 해결하기 위해 ISP를 준수하는 방식으로 수정할 수 있습니다.

// 작업 인터페이스
public interface Workable {
    void work();
}

// 식사 인터페이스
public interface Eatable {
    void eat();
}

// 로봇 클래스
public class Robot implements Workable {
    @Override
    public void work() {
        // 로봇의 작업 기능
    }
}

이제 각 클래스는 필요한 인터페이스만 구현하여, 각각의 책임에 따라 분리되었습니다.

---

5. 의존 역전 원칙 (Dependency Inversion Principle - DIP):
   - 추상화에 의존해야 하며, 구체화에는 의존하면 안 됩니다.
   - 상황 예시: 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 되며, 추상화에 의존해야 합니다. 즉, 클래스 간의 의존성을 인터페이스와 추상 클래스에 의존하도록 만들어야 합니다.

아래는 의존 역전 원칙을 위반한 예시입니다.

// 전구 클래스
public class LightBulb {
    public void turnOn() {
        // 전구를 켜는 로직
    }
}

// 스위치 클래스
public class Switch {
    private LightBulb bulb;

    public Switch() {
        this.bulb = new LightBulb();
    }

    public void toggle() {
        // 전구를 켜거나 끄는 로직
        bulb.turnOn();
    }
}

위 코드에서 Switch 클래스는 LightBulb 클래스에 직접 의존하고 있습니다.

이를 해결하기 위해 DIP를 준수하는 방식으로 수정할 수 있습니다.

// 전구 인터페이스
public interface Switchable {
    void turnOn();
}

// 전구 클래스
public class LightBulb implements Switchable {
    @Override
    public void turnOn() {
        // 전구를 켜는 로직
    }
}

// 스위치 클래스
public class Switch {
    private Switchable device;

    public Switch(Switchable device) {
        this.device = device;
    }

    public void toggle() {
        // 전구를 켜거나 끄는 로직
        device.turnOn();
    }
}

이제 Switch 클래스는 추상화된 Switchable 인터페이스에 의존하며, 실제 전구 구현은 이 인터페이스를 구현함으로써 연결됩니다. 

이로써 더 유연하고 확장 가능한 코드를 얻을 수 있습니다.