객체지향 설계의 5대 원칙 (SOLID)

객체지향설계원칙

'객체지향프로그래밍', '객체지향적' 이런 말 많이 들어봤을 것이다. 나도 많이 들어봤고, 객체지향적인 것이 지금도 명확하게 설명할 수 있다고 자부하진 않지만 그게 무엇인지 아예 모를 때에도 '객체지향적으로 설계해야 한다.'고 생각했을 정도로 귀에 박히도록 들어왔다.

어떻게 하면 객체지향적으로 설계할 수 있을까? 내가 지금 하고 있는 방법들이 객체지향적인 것일까? 하고 늘 생각해왔는데, 오늘 토비의 스프링3(이일민, 에이콘출판사)을 읽다가 SOLID라는 것을 알게 되었다.

아래에 있는 객체지향 설계의 5가지 원칙들의 앞머리를 따서 SOLID라고 칭한다.

이 5가지 원칙을 지킨다면 결합도를 낮추고, 응집도를 높여 소프트웨어를 더 깔끔하고 이해하기 쉬우며, 수정하기 쉽고, 재사용하기 쉽게 설계할 수 있다.

결합도(coupling)는 요소 간의 의존도, 응집도(cohesion)는 요소의 독립도(기능의 집중 정도)라고 보면 된다.
결합도가 높으면 수정 시 영향 범위가 넓어지며, 응집도가 낮으면 다른 클래스의 변화에 민감해져 재사용 및 유지보수가 어려워진다.

객체는 오직 하나의 책임(single responsibility)을 가져야 한다. (어떤 클래스를 변경해야 하는 이유는 오직 하나 뿐이어야 한다.)
하나의 클래스가 두 가지 이상의 책임을 지니게 되면 클래스의 목적이 모호해지며 수정 시 영향범위가 넓어지게 되어 유지보수를 어렵게 만든다.
클래스 하나에 모든 기능(책임)을 부여하지 않고, 기능을 분리해 각 객체의 목적을 분명히 함으로써 코드의 가독성을 향상시킬 수 있으며 유지보수하기가 쉬워진다.

객체는 확장에 대해서는 개방적이어야 하지만, 수정에 대해서는 폐쇄적이어야 한다. (기능의 확장을 허용하고 직접 수정은 피해야 한다.)
상위클래스나 인터페이스를 활용해 수정 및 변동사항이 생길 경우 기존 구성 요소의 수정은 막고(close), 확장을 통한 재정의 및 재사용은 허용(open)함으로써 객체 간의 결합도를 줄여줄 수 있다.

자식 클래스는 언제나 자신의 부모 클래스로 대체할 수 있어야 한다. 즉, 하위 클래스의 인스턴스를 upcasting해서 사용해도 논리적으로 문제가 없어야 한다는 것이다.
상속은 다형성과 확장성을 위한 것으로, 과용하여 응집도를 높이지 않도록 해야 한다.

클라이언트는 자신이 사용하지 않는 메서드와 의존관계를 맺으면 안된다.
여러 클라이언트가 하나의 인터페이스의 부분집합을 사용한다면, 이를 여러개로 나누어 각 클라이언트가 원하는 메서드만을 제공해야 한다. 필요없는 메서드를 포함하는 큰 인터페이스 하나를 모두 구현상속하는 것이 아니라, 작은 인터페이스 여러개로 나누어 필요한 기능만을 가진 인터페이스(들)만을 (다중)구현하는 것이다.

추상적이고 안정적인 고수준 클래스(상위 클래스)는 구체적이고 불안정한 저수준 클래스(하위 클래스)에 의존해서는 안된다.
구체적인 클래스는 추상적인 클래스보다 변화에 민감하다. 만약 상위 클래스가 하위 클래스에 의존하게 된다면 하위 클래스가 변화될 때마다 상위 클래스(또는 추상 클래스)가 계속 변경되어야 한다. 그렇게 된다면 계속되는 수정에 유지보수가 곤란해질 것이다.

차근차근 프로그래밍