SOLID와 Spring - 1

객체지향 프로그래밍의 5대 원칙이라 불리는 SOLID는 2000년대 초반 로버트 C. 마틴에 의해 정립되었습니다. 로버트 C. 마틴이 각각의 원칙을 세운 것은 아니지만 여러 가지 소프트웨어 설계 원칙들을 종합하고 정리한 것입니다.. 현재 SOLID 객체지향 적인 프로그래밍을 하는 거의 모든 개발자들에게 지켜야만 하는 최우선의 원칙들 중 하나가 되어 있는 것 같습니다. Spring이 어떻게 개발자로 하여금 SOLID 한 코드를 작성하도록 돕는지에 대해 이야기해보고자 하는데 먼저는 SOLID가 무엇인지부터 알아보겠습니다.

 

SOLID는 서로 다른 5개의 원칙들의 알파벳 첫 글자를 따서 이름 붙여졌습니다. 이 다섯 가지 원칙은 다음과 같습니다.

• Single Responsibility Principle - 단일 책임 원칙
• Open-Closed Principle - 개방-폐쇄 원칙
• Liskov Substitution Principle - 리스코프 치환 원칙
• Interface Segregation Principle - 인터페이스 분리 원칙
• Dependency Inversion Principle - 의존성 역전 원칙

 

 

Single Responsibility Principle - 단일 책임 원칙

대부분의 사람들은 단일 책임 원칙이라고 한다면 '하나의 클래스 혹은 모듈은 하나의 책임만 가지도록 하는 것'이 단일 책임 원칙이라고 이야기합니다. 하지만 로버트 C. 마틴은 그의 저서 Clean Architecture에서 이는 오해이며 '하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 하며, 책임지고 있는 액터가 아닌 다른 요소에 의해서는 변경이 이루어지지 않도록 하는 것'이라고 이야기합니다.

개인적으론 둘 모두 맞는 이야기이고 표현의 차이이지 않나 생각합니다. 결국 단일 책임 원칙은 하나의 액터 혹은 하나의 책임을 수행하는 코드들을 한 곳에 응집시키는 응집성과, 책임을 적절하게 나누는 것에 대한 이야기인 것 같습니다.

 

 

Open-Closed Principle - 개방-폐쇄 원칙

개방-폐쇄 원칙은 '소프트웨어 개체는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다' 는 원칙입니다. 새로운 기능 개발에(확장) 있어서는 열려 있어서 얼마든지 추가 혹은 수정이 가능하되 그것이 기존 코드의  변경을 필요로 해서는 안된다는 것입니다. 

이는 얼핏 보면 말이 되지 않아보입니다. 아무리 추상화가 잘 되어 있어 구현 클래스만을 바꿔서 주입해준다 하더라도, 주입해주는 과정에서 수정이 필요하기 때문입니다. 이는 추후에 살펴볼 IoC 컨테이너가 도움을 받아 해결 가능합니다.

개방 폐쇄 원칙은 개인적으로 객체지향에 있어서 가장 중요한 원칙이자 꽃이 아닌가 생각합니다. 서비스를 개발하다 보면 로직은 나날이 복잡해져 가고, 유지보수는 계속해서 어려워지기 쉽습니다. 하지만 개방 폐쇄 원칙을 잘 지키도록 프로그램을 설계한다면 피쳐에만 집중한 개발이 가능해질 것입니다.

 

 

Liskov Substitution Principle - 리스코프 치환 원칙

정의는 다음과 같습니다.

S타입의 객체 o1 각각에 대응하는 T 타입 객체 o2 가 있고, T 타입을 이용해서 정의한 모든 프로그램 P에서 o2 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면 S는 T의 하위 타입이다.

이해하기 어렵게 정의를 내려 놓았지만 간단히 이야기하면 '객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 치환이 가능해야 한다'는 것입니다.

단순히 추상화된 인터페이스를 구현하는 것 만이 아니라 그 기능 또한 기대했던 대로 동작해야 합니다. 만약 리스코프 치환 원칙이 보장되지 않는 다면 어떤 추상화나 상속도 신뢰하기 어려울 것입니다.

 

 

Interface Segregation Principle - 인터페이스 분리 원칙

인터페이스를 각각의 관심사에 맞게 분리해야 한다는 원칙으로서 단일 책임 원칙과 비슷한 부분이 많습니다.

 

 

Dependency Inversion Principle - 의존성 역전 원칙

'추상화에 의존해야지, 구체화에 의존해선 안된다'는 원칙이다. 특정 클래스 혹은 모듈이 구현체에 의존하게 되면, 많은 문제점들이 발생합니다.

1. 구현체에 대해 알게 되면서 커플링이 발생하고 분리된 테스트가 어려워진다.

2. 기능 변경에 따른 수정이 불가피 해지면서 OCP를 위반하게 된다. 등등...

 

 

SOLID에 대해 간단하게 알아보았습니다. 다음 시간엔 스프링이 어떻게 SOLID 한 코드를 작성하도록 돕는지에 대해 알아보겠습니다.

 

ref.

Robert C. Martin - Clean Arichitecture

docs.spring.io

김영한 - 스프링 핵심 원리 (기본편)