객체 지향 설계의 원칙 SOLID

목차
1. SOLID란?
2. 왜 만들어졌을까?
3. 꼭 사용해야할까?

1. SOLID란?

SOLID는 클린 코드로 유명한 로버트 C. 마틴이라는 사람이 2000년대 초반 객체지향 프로그래밍 및 설계에 대한 5가지 사항을 기본원칙으로 제시한 아래 5가지 원칙의 앞글자를 따 명명한 것이다.

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

 

2. 왜 만들어졌을까?

1990년도부터 객체지향 언어가 주류를 이루기 시작하였지만 정확히 어떻게 써야할지를 몰라 기존의 설계가 맞지 않거나 하나의 클래스에 모든 기능을 추가하는 GOD 클래스가 만들어지는 등 현상이 발생하면서 다음과 같은 문제가 발생하였다.

 

• 경직성 : 한 곳을 고치면 연결된 다른 곳까지 다 고쳐야 해서 수정을 꺼리게 된다.
• 취약성 : 전혀 상관없는 부분에서 버그가 터짐 (일명 '풍선 효과').
• 부동성 : 특정 기능을 다른 프로젝트에서 재사용하고 싶어도 덩어리가 너무 커서 떼어낼 수 없음.

이러한 문제를 해소하고자 객체지향의 특징을 제대로 활용해보자라는 목적으로 만들어졌다.

SOLID라는 원칙을 지키면 외부의 의존도를 높이는 결합도는 낮추고 내부의 연관성을 높이는 응집도는 높여 소프트웨어 품질을 향상 시킬 수 있기에 지키는 게 좋다.

 

3. 꼭 사용해야할까?

위에서 언급한 것처럼 SOLID는 객체지향 프로그래밍에서 소프트웨어 품질을 높이기 위한 원칙으로 지키려고 노력하는 것이 좋다. 하지만 무조건 따라야 하느냐? 그건 아니다. 법이 아닌 공학적 도구일뿐이다. 오히려 이 원칙을 지키려다 다른 문제가 발생할 수 있다.

• 복잡성 증가 : 클래스와 인터페이스가 많아지면서 코드의 복잡성과 비용이 증가할 수 있다.
• 생산성 저하 : 원칙에 따라 설계 중 고려해야할 것들로 인해 초기 개발 속도가 현저히 느려질 수 있다.

빠르게 개발을 해야하거나 1회성 스크립트를 만드는 등의 경우에는 해당 원칙을 적용하는 것은 비효율적일 수 있다. 변경이 잦거나 지속적인 서비스를 제공해야하는 경우에 원칙을 적용하도록 하는 것이 좋다. 

 

SOLID의 목적은 유지보수를 하기 좋은 코드를 만드는 것이지 무조건 원칙을 따르는 코드를 만드는 것이 아니다.