[OOP] 객체지향 설계 원칙 5가지

서론

다들 객체지향 설계의 5원칙이라고 불리는 SOLID에 대해서 한번쯤을 들어봤을 겁니다. 객체지향에서 꼭 지켜야할 5개의 원칙을 통틀어 5원칙이라고 칭하고, 이 5개의 원칙의 앞글자를 따서 SOLID라고도 부릅니다. 클린코드의 저자로 유명한 로버트 마틴이 2000년대 초반에 명명하였으며, 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있습니다.
각각의 원칙들은 아래와 같습니다.

1. 단일 책임 원칙(SRP, Single Responsibility Principle)
2. 개방 폐쇄 원칙(OCP, Open-Closed Principle)
3. 리스코프 치환 원칙(LSP, Liskov Subsituation Principle)
4. 인터페이스 분리 원칙(ISP, Interface Segragation Principle)
5. 의존관계 역전 원칙(DIP, Dependency Inversion Principle)

 

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

어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다. - 로버트 C.마틴

하나의 클래스는 하나의 책임만 가져야 합니다. 책임이란 기준이 모호하고 문맥과 상황에 따라 다르기 때문에 변경을 책임의 기준으로 삼으면 설계에 용이할 수 있습니다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 지킨 것으로 볼 수 있습니다.
간단한 예를 들어서 회원 가입 쪽의 API를 담당하는 Class가 있다고 가정했을 때, 그 안에는 회원가입에 해당하는 기능들만 있어야 합니다. 그래서 만약 회원가입 기능을 수정하고자 한다면 오직 이 회원가입 Class만 수정해야 할 것입니다.
만약 단일 책임 원칙을 지키지 않았을 경우(하나의 Class에 다양한 기능이 들어간 경우) 해당 Class를 수정했을 때 다른 모듈에 어떠한 영향을 미치는 지 그 범위를 추측하기 힘들 수 있습니다.

 

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

소프트웨어 요소(엔티티, 클래스, 모듈, 함수, 등)는 확장에 대해서는 열려있어야 하지만 변경에 대해서는 닫혀 있어야 한다. - 로버트 C.마틴

즉, 자신의 확장에는 열려 있고, 주변의 변화에 대해서는 닫혀 있어야 합니다. 이는 변경이 일어나더라도 기존의 구성요소에 대해서는 수정이 일어나지 않아야 하며, 쉽게 확장이 가능하여 재사용을 할 수 있도록 해야한다는 의미입니다.
여기에서 중요한 것은 추상화와 다형성입니다. 객체 지향에서 다형성이란 여러 가지 형태를 가질 수 있는 능력을 의미합니다. 따라서 결과적으로 개방 폐쇄 원칙은 추상화를 의미하는 것으로 해석됩니다. 객체를 추상화함으로써 확장엔 열려있고, 변경엔 닫혀있는 유연한 구조를 만들 수 있는 것입니다.
따라서 개방 폐쇄 원칙을 무시한다면 유연성, 재사용성, 유지보수성 등을 얻을 수 없다라고 할 정도로 중요한 원칙이라고 볼 수 있습니다.

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

서브 타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다. - 로버트 C.마틴
wiki백과에서는 "자료형 S가 자료형 T의 하위형이라면 필요한 프로그램의 속성의 변경없이 자료형 T의 객체를 자료형 S의 객체로 교체(치환) 할 수 있어야 한다."라고 설명하고 있습니다.
쉽게 말해서 부모 Class가 들어갈 자리에 자식 Class를 넣어도 잘 작동해야한다는 원칙입니다.
리스코프 치환 원칙을 설명하는 가장 대표적인 예가 '직사각형 - 정사각형 문제'입니다. 우리는 직사각형은 정사각형이 아니지만, 정사각형은 직사각형이라는 사실을 알고 있습니다.
먼저 직사각형의 특징은 아래와 같습니다.

1. 내각의 합은 360이며, 직사각형의 네 각은 동일하게 90도를 이룬다.
2. 직사각형의 대각선은 서로 다른 대각선을 이등분한다.
3. 두 쌍의 변이 각각 서로 평행한다.
4. 너비는 세로변 * 가로변이다.

정사각형의 특징의 직사각형의 특징에 추가로 5. 네 변의 길이가 모두 같다 라는 특징을 가집니다.

1. 내각의 합은 360이며, 직사각형의 네 각은 동일하게 90도를 이룬다.
2. 직사각형의 대각선은 서로 다른 대각선을 이등분한다.
3. 두 쌍의 변이 각각 서로 평행한다.
4. 너비는 세로변 * 가로변이다.
5. 네 변의 길이가 모두 같다.

직사각형이라는 큰 부모 안에서 정사각형이라는 자식이 포함된다고 볼 수 있습니다. 그래서 수학적으로 봤을 때는 정사각형은 직사각형이다 라는 조건을 충족합니다. 따라서 정사각형 역시 넓게 보면 직사각형의 한 종류이니, 직사각형을 상속하여 정사각형 객체를 빠르게 만들 수 있을 것이라 생각할 수 있습니다.
그럼 한번 위 개념을 기준으로 리스코프 원칙을 준수하는 코드와 위배하는 코드를 한번 살펴보겠습니다.

리스코프 치환 원칙을 위배하는 코드

public class Rectangle {
    private int width;
    private int height;

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

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

    public int getWidth() {
        return width;
    }

    public int getHeight() {
        return height;
    }
}

위와같은 직사각형(Rectangle)의 객체가 있다고 가정합시다.

public class Square extends Rectangle {

    @Override
    public void setWidth(final int width) {
        super.setWidth(width);
        super.setHeight(width);
    }

    @Override
    public void setHeight(final int height) {
        super.setWidth(height);
        super.setHeight(height);
    }
}

그리고 정사각형(Square)는 직사각형(Rectangle)을 상속받아서 위처럼 구현했다고 가정합시다.
정사각형(Square)의 경우 직사각형(Rectangle)과 달리 너비와 높이가 같으니, 너비나 높이를 지정하면 그에 맞게 너비와 높이를 모두 일치시켜 주도록 하기 위해서 오버라이딩을 통해 메서드를 재정의했습니다.
이제 직사각형(Rectangle)의 넓이를 구해봅시다.

public class Main{
    public static void main(String[] args){
        Rectangle rectangle = new Rectangle();
        rectangle.setWidth(10);
        rectangle.setHeight(5);
        
        System.out.println(rectangle.getArea()); // 출력: 50
    }
}

직사각형(Rectangle)의 넓이를 구하는 소스는 위와 같습니다. 너비가 10, 높이를 5로 할당했으므로 넓이 50이 정상적으로 출력됐습니다.
리스코프 치환 원칙에 의하면, 자식 객체는 부모를 완전히 대체할 수 있다고 했으므로, 직사각형(Rectangle)을 상속받은 정사각형(Square)로 대체하여 한번 넓이를 구해봅시다.

public class Main{
    public static void main(String[] args)    {
        Rectangle rectangle = new Square();
        rectangle.setWidth(10);
        rectangle.setHeight(5);

        System.out.println(rectangle.getArea()); // 출력: 25
    }
}

정사각형(Square)가 직사각형(Rectangle)을 완전히 대체했다면 동일한 결과인 50이 반환되어야 하지만 어째서인지 넓이는 50이 아닌 25로 반환되었습니다. 자세히 살펴보면, 마지막에 수행된 setHeight(5)가 객체의 너비/높이를 모두 5로 할당했습니다. 그래서 넓이도 25로 출력이 되었습니다.
즉, 이 객체는 리스코프 치환 원칙에 위배되는 코드입니다. 이렇게 잘못된 객체를 상속하거나, 올바르게 확장하지 못 할 경우 겉으로 보기엔 정상적으로 보이지만 올바른 객체가 아닙니다.
그렇다면 어떻게 위 코드를 리스코프 치환 원칙에 부합하게끔 구성할 수 있을까요?
정답은 올바른 상속과 구현에 있습니다. 앞서 설명했다시피, 직사각형과 정사각형은 상속의 관계가 성립되기 어렵습니다. 따라서 이보다 더 상위 개념인 사각형 객체를 구현하고 정사각형, 직사각형이 이를 상속받도록 구현할 수 있습니다.

리스코프 치환 원칙을 준수하는 코드

/**
* 사각형 클래스
*/

public class Shape{
    protected int width;
    protected int height;
    
    public int getWidth(){
        return width;
    }
    
    public int getHeight(){
        return height;
    }
    

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

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

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

위와 같이 Shape라는 사각형 객체를 구현할 수 있습니다.

/**
 * 직사각형 클래스
 */
class Rectangle extends Shape{
    public Rectangle(int width, int height){
        setWidth(width);
        setHeight(height);
    }
}

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

사각형(Shape)를 상속받는 직사각형(Rectangle)과 정사각형(Square) 객체는 위와 같습니다. 직사각형(Rectangle)은 인스턴스 생성 시 width와 height를 파라미터로 받으며, 정사각형(Square)는 각 벽의 길이가 모두 동일하므로 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()); // 출력: 50
        System.out.println(square.getArea()); // 출력: 25
    }
}

이제 더 이상 직사각형(Rectangle)과 정사각형(Square)이 상속관계가 아니므로, 리스코프 치환 원칙의 영향에서 벗어나게 되었습니다.

정리

리스코프 치환 원칙은 상속되는 객체는 부모 객체를 완전히 대처해도 아무런 문제가 없어야 한다고 권고합니다. 위의 직사각형과 정사각형의 케이스처럼 올바르지 못한 상속관계는 제거하고, 부모 객체의 동작을 완벽하게 대체할 수 있는 관계만 상속하도록 코드를 설계해야 합니다.

 

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

클라이언트는 자신이 사용하지 않는 메서드에 의존 관게를 맺으면 안된다. - 로버트 C.마틴

즉, 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙입니다. 다시 말하면, 하나의 큰 인터페이스를 상속 받기 보다는 인터페이스를 구체적이고 작은 단위들로 분리시켜 꼭 필요한 인터페이스만 상속하자 라는 의미입니다.
SRP(단일 책임 원칙)가 클래스의 단일 책임 원칙을 강조했다면 ISP(인터페이스의 분리 원칙)는 인터페이스의 단일책임을 강조합니다.

 

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

고차원 모듈은 저차원 모듈에 의존하면 안 된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다. 추상화된 것은 구체적인 것에 의존하면 안 된다. 구체적인 것이 추상화된 것에 의존해야 한다. 자주 변경되는 구체(Concrete) 클래스에 의존하지 마라 - 로버트 C.마틴

즉, 프로그래머는 구체화가 아니라 추상화에 의존해야 하며, 구현 클래스(구현체)가 아니라 인터페이스(역할)에 의존하라는 이야기입니다.

만약 자동차가 타이어에 의존하면 어떻게 될까요? 자동차 타이어는 자주 바뀌게 되는 것 중 하나입니다. 따라서 이렇게 바뀌는 것에 의존하면 자동차는 자주 영향을 받게 되게 됩니다. 즉, 자동차 자신보다 더 자주 변하는 타이어에 의존하는 것은 좋지 않음을 알 수 있습니다.

따라서 위처럼 자동차가 구체적인 타이어가 아닌 추상화된 타이어 인터페이스에만 의존하게 함으로써 타이어가 변경되더라도 자동차가 영향을 받지 않게 구현함으로써 의존관계 역전 원칙을 지킬 수 있습니다.