SOLID

💡 해당 글은 『스프링 입문을 위한 자바 객체지향의 원리와 이해』 도서를 학습하며 도서의 내용을 참고하여 본인의 언어로 표현한 글입니다.

이번 장은 SOILD법칙에 대해 설명한다. SOILD도 이미 귀에 딱지가 생기도록 듣고 읽었으니, 이해에 있어 조금 아쉬운 부분과 개념에 대해 정리하려 한다.

 

☁️ SOLID

객체 지향의 4대 특성, ‘캡!상추다’를 학습했다면 객체 지향적인 프로그래밍을 할 준비가 된 것이다. 하지만 객체 지향 프로그래밍을 제대로 하기 위해서는 규칙이 존재한다. 아래의 규칙을 지키며 객체 지향 프로그램을 설계하면 응집도는 높이고, 결합도는 낮춰 변경에 유연하고 확장에 용이한 프로그램을 설계할 수 있을 것이다.

• SRP(Single Responsibility Principle): 단일 책임의 원칙
• OCP(Open Closed Principle): 개방 폐쇄 원칙
• LSP(Liskov Substitution Principle): 리스코프 치환 원칙
• ISP(Interface Segregation Principle): 인터페이스 분리 원칙
• DIP(Dependency Inversion Principle): 의존 역전 원칙

 

 

☁️ SRP - 단일 책임의 원칙

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

“객체는 하나의 책임만을 가져야 한다.” 라고 자주 설명되는 단일 책임 원칙은 객체가 여러 책임이 아닌 하나의 책임을 가지고 있음으로써, 단일하고 명확한 이유에 의해 변경되어야 한다는 것을 의미한다.

 

이 책임이라는 게 참 애매하고 모호하고 어렵다고 생각한다. 클래스 이름에 맞는 행동을 하는가로 판단한다. 만약 아래와 같은 코드가 있다면 SRP를 위반하는 코드이다.

// SRP를 위반하는 예시
public class Rport {

    private String title;
    private String content;

    public void generateReport() {
        // 보고서 생성 로직
        try (BufferedReader bf = new BufferedReader(new Inputstream // ... ) {
            this.title = // ...
            this.content = // ...
                } catch(IOException ignored) { }
    }

    public void saveToFile() {
        // 파일에 저장하는 로직
        try (PrintWriter writer = new PrintWriter(title + ".txt")) {
            writer.write(content);
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }
    }
}

보고서를 생성한다. 보고서를 파일에 저장한다. 두 행위는 분리되어야 한다고 생각한다. 보고서가 보고서를 생성한다는 말로 표현했을 땐 자연스러울지 모르지만, 코드로 본다면 자신을 생성하기 위해 외부의 입력에 의존하고 있는 꼴이다. 파일에 저장하는 행위도 하나의 저장방식에 의존하고 있는 꼴이다.

 

내 생각에 Report는 report 자신의 상태를 관리하는 책임만 가지고 있으면 될 것 같고 변하기 쉬운 외부 입력 방식에 의존하는 ReportGenerator, 파일 저장 방식에 의존하는 ReportSaver를 클래스로 분리할 것 같다.

 

단일 책임의 원칙을 지키기 위해 추상화(모델링)을 잘 해야 한다. 공통의 관심사에 맞게 기능을 잘 묶어 최소한의 단위로 하나의 책임만을 가지는 클래스로 추상화하자.

 

❓왜 하나의 책임만을 가져야 할까

객체가 여러 책임을 가지는 경우 재사용성이 떨어지고, 의존성이 높아질 것이라고 생각한다. 여러 책임을 가진다는 것은 객체의 크기가 커진다는 것이다. 이는 즉, 다른 객체에서 필요한 기능 외의 불필요한 기능들을 포함하고 있을 가능성이 있고, 재사용하기 힘들어진다. 나는 방 청소만 해줄 청소부를 부르고 싶은데 방청소, 인테리어, 건축까지하는 값비싼 인부를 부르기 편할까?

또한, 의존성이 높아진다고 생각한다. 한 객체가 여러 책임을 가지고 있다면, 해당 객체의 책임, 행위가 필요한 모든 객체에서 해당 객체를 의존할 것이다. 이는 의존성이 높아질 수 있는 가능성이 있고, 객체의 변경으로 인한 사이드 이펙트를 가늠하기 힘들어진다.

 

 

OCP - 개방 폐쇄 원칙

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

도서에서는 아래와 같이 말한다.

“자신의 확장에는 열려 있고, 주변의 변경에는 닫혀 있어야 한다.” - 자바 객체 지향의 원리와 이해

나는 더 쉽게 풀어서 말해야 이해가 되기에 이렇게 정의해 보았다.

“자신의 기능을 확장하는 것은 편리해야 하고, 주변의 변경에 의한 영향은 최소화 한다.” - 정현수

자신의 기능을 확장하는 것에 문제가 없어야 한다는 건 무슨 의미일까? 구체 클래스와의 의존을 피하고 확장에 용이한 추상적인 개념과 의존하고 있다는 것을 의미한다고 생각한다.

 

만약 내가 차를 운전하는 기능이 구체적인 마티즈와 의존한다고 생각해보자. 이를 확장하려면 마티즈와 동일한 안전벨트, 액셀, 브레이크, 수동기어 … 를 가진 마티즈의 서브클래스만 확장할 수 있을 것이다. 근데 만약 오토기어로된 쏘나타를 몰고 싶다면? 쏘나타와 의존하는 운전 기능을 또 만들어야 할까?

public class 정현수 {

    public void drive마티즈(마티즈 마티즈1) {
        마티즈1.시동걸기();
        마티즈1.수동기어조작();
    }

    public void drive쏘나타(쏘나타 쏘나타1) {
        // 이렇게??
    }
}

추상적인 개념에 의존하면 확장에 용이하다. 마티즈, 쏘나타가 아닌 자동차라는 개념에 의존하는 것이다.

public interface Driveable {
    public void 운전하기();
}

public class 정현수 {
    public void drive(Driveable 운전가능한것) {
        운전가능한것.운전하기();
    }
}

이렇게 추상화 시키다 보면 운전가능한 모든것을 drive라는 행위 하나로 퉁칠 수 있다.

또한 외부 변경에 의한 영향을 최소화 한다. 마티즈의 수동기어조작이 오토기어로 변경된다면? 정현수 또한 오토기어조작을 배우고 운전하는 행위를 수정해야 한다. 하지만 추상화된 개념과 의존한다면 그런거 몰라도 상관없다.

 

도서에서는 자바와 데이터베이스로 예시를 들었으며 이렇게 말한다.

“자바 애플리케이션은 데이터베이스라고 하는 주변의 변화에 닫혀 있는 것이다. 데이터베이스를 교체한다는 것은 데이터베이스가 자신의 확장에는 열려 있다는 것이다.” - 자바 객체 지향의 원리와 이해

 

 

☁️ LSP - 리스코프 치환 원칙

“서브타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다” - 로버트 C. 마틴

당연한 말이다. 이게 불가능하면 추상화와 상속에서 다형성을 지킬 수 없다. 그럼 추상화와 상속이 무슨 의미가 있겠는가. 하위타입은 언제나 상위타입으로 대입할 수 있어야하고, 상위타입의 역할을 수행하는 데 아무런 문제가 없어야 한다.

 

 

☁️ ISP - 인터페이스 분리 원칙

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

내가 사용하지 않는 메서드를 포함한 클래스와 의존관계를 맺으면 안된다는 것이다. 즉, 관심사에 맞게 인터페이스로 분리하여 꼭 필요한 메서드만을 포함한 인터페이스와 의존하라는 것이다.

 

위에서 했던 방청소 얘기를 다시 가져오면 아래와 같다.

public class 정현수 {

    public void 방청소(방청소가능한 인부) {
        인부.방청소();
    }

    public void 인테리어변경(인테리어변경가능한 인부) {
        인부.인테리어변경();
    }
}

두 메서드와 런타임 시 의존하는 실체는 동일한 인부일 수 있다. 한 인부가 방청소도 가능하고 인테리어 변경도 가능할 수 있기 때문이다. 하지만 방청소 메서드에서는 동작에 필요한 방청소 메서드만을 가진 인터페이스와 의존하며 메서드를 확장에 열려있고, 변경에는 닫혀있는 구조를 만들 수 있다.

 

도서에서는 이렇게 말한다.

결론적으로 SRP와 ISP는 같은 문제에 대한 두 가직 다른 해결책이라고 볼 수 있다. 프로젝트 요구사항과 설계자의 취향에 따라 단일 책임 원칙이나 인터페이스 분리 원칙 중 하나를 선택해서 설계할 수 있다.

즉, 하나의 클래스를 단일 책임을 가지는 여러 클래스로 분리하던가, 하나의 클래스를 각 기능을 가지는 인터페이스를 구현하는 형태로 변경하던가의 차이인 것 같다.

 

❓상위 클래스는 풍성할 수록 좋고, 인터페이스는 작을수록 좋다?

상위 클래스가 풍성하다면 하위 클래스가 상위 클래스 타입으로 선언되었을 때, 수행할 수 있는 행위가 많아질 것이다. 따라서 SRP를 고려하며, 중복되는 행위, 상태를 최대한 추상화 시켜야 한다.

인터페이스가 작다면, 의존성은 낮아지고, 재사용성은 높아진다. 특정 기능을 수행하는 데 있어 꼭 필요한 메서드만을 가진 인터페이스와 의존하며 의존성을 낮출 수 있다.

 

 

☁️ DIP - 의존 역전 원칙

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

구체 클래스끼리 의존하지 말고, 추상화된 클래스, 인터페이스와 의존하는 것이 변경에 안전하다 라는 것이다.

이 개념을 지킨다면 결국 OCP를 지키게 된다.

 

 

☁️ 복습한 뒤 SOLID에 대한 나의 생각

결국 모든 원칙은 하나의 개념으로 통념되는 것 같다.

객체를 분리하여 추상화시키고 추상화된 것과 의존 관계를 맺어 변경에 유연하고, 확장에 용이한 프로그램을 설계하자. 여기서 SRP를 적용하여 클래스로 분리할지 ISP를 적용하여 인터페이스로 분리할지는 상황에 맞게 선택한다.

 

즉 역할과 구현을 분리하는 것이 객체지향 설계의 핵심이다. 클라이언트는 역할과 의존하며 여러 구현을 유연하게 사용할 수 있게된다. 이런 구조의 한계는 역할 자체가 변경된다면 코드의 대대적인 변경이 필요하다는 것이다. 따라서 설계 초기에 인터페이스를 잘 설계하는 것이 중요하다고 생각한다.