SOLID 개요 - codehumane

SOLID의 구체적인 이야기에 앞서 나쁜 디자인은 무엇이고, SOLID는 어떤 문제를 해결하려 하는지 살펴보도록 한다.

나쁜 디자인

로버트 마틴의 The Dependency Inversion Principle 문서에서는 나쁜 디자인^{Bad Design}을 다음과 같이 정의하고 있다.

A piece of software that fulfills its requirements and yet exhibits any or all of the following three traits has a bad design.

여기서 가리키는 3가지 특성은 다음과 같다.

It is hard to change because every change affects too many other parts of the system. (Rigidity)

When you make a change, unexpected parts of the system break. (Fragility)

It is hard to reuse in another application because it cannot be disentangled from the current application. (Immobility)

변경 사항이 발생했을 때 다른 곳에 너무 많은 변경을 가져오거나(경직성^rigidity), 예측하지 못한 곳에서 문제가 생길 때(깨지기 쉬움^fragility), 혹은 현재 어플리케이션에서 분리해내기 어려워 다른 곳에서 재사용하기 어려운 것(부동성^immobility)을 가리킨다.

여기서 주목할 만한 부분은 “요구사항을 충족하는^{fulfills its requirements}”이다. 아무리 좋은 설계를 가지고 있다고 하더라도 요구사항을 만족시키지 못한다면 가치를 전달할 수 없다. 언제나 잊지 말아야 할 부분이다.

객체 지향 설계의 5가지 원칙

단지 객체 지향 언어를 쓰는 것만으로는 경직성, 깨지기 쉬움, 부동성을 해결할 수 없다. 객체 지향 언어의 근간이 되는 가치들을 얻기 위해서는 여러 가지 노력이 필요한데, 그 중의 하나가 SOLID이다. 이는 로버트 마틴^{Robert Martin}이 2000년대 초에 명명한 다섯 가지 객체 지향 프로그래밍 및 설계 원칙을 줄여서 부르는 말이다(출처: https://en.wikipedia.org/wiki/SOLID_(object-oriented_design)).

로버트 마틴의 OOD 원칙^{The Principle of OOD}에 따르면 이 다섯 가지 원칙이 특히 OOD의 의존성 관리 측면에 관한 것이라고 한다. 의존성 관리가 약할 경우 코드는 변경하기 어렵고, 깨지기 쉽고, 재사용하기 어렵다. 반대로, 의존성 관리가 잘 되면 코드는 유연^flexible하고 강건^robust하며, 재사용 하기 쉽다^reusable.

SOLID의 각 요소는 다음과 같다.

단일 책임 원칙^{Single Responsibility Principle}
개방-폐쇄 원칙^{Open/closed principle}
리스코프 치환 원칙^{Liskov substitution principle}
인터페이스 분리 원칙^{Interface segregation principle}
의존관계 역전 원칙^{Dependency inversion principle}

이어지는 글에서 하나씩 자세히 살펴보도록 하자.

나쁜 디자인

객체 지향 설계의 5가지 원칙

관련 문서