[8] 소프트웨어 디자인 원칙들 - SOLID 원칙들 - (S)

출처 : 디자인 패턴에 뛰어들기 - 알렉산더 슈베츠 도서

---

SOLID 원칙들

기본 디자인 원칙을 배웠으므로 이제 일반적으로 SOLID 원칙들이라고 알려진 5가지 원칙을 살펴본다.

로버트 마틴은 자신의 책 『소프트웨어 개발의 지혜: 원칙, 디자인 패턴, 실천방법 6』에서 이 5가지 원칙들을 소개하였다.(참고용)

SOLID는 소프트웨어 디자인을 보다 이해하기 쉽고 유연하며 유지 관리할 수 있도록 만드는 5가지 설계 원칙들에 대한 연상 기호이다.

• 이러한 원칙들을 아무 생각없이 적용하면 득보다 실이 더 많을 수 있다.
• 프로그램이 필요 이상으로 복잡해질 수 있다.
• 이 모든 원칙이 동시에 적용되는 성공적인 소프트웨어 제품이 있는지도 의심스러울 수 있다.
• 이러한 원칙들을 적용하기 위해 노력하는 것도 좋지만 항상 실용적이려고 노력해야한다.
• 여기에 쓰인 모든 것을 교리로 받아들이지 말기를 권장하고 있다.

---

S (Single Responsibility Principle, 단일 책임 원칙)

클래스는 한 가지 이유로 변경되어야 한다.

각각의 클래스가 프로그램이 제공하는 기능의 한 부분을 책임지도록 해야하고, 그 후 이 책임을 완전히 캡슐화하여 클래스 내부에 숨겨야한다.

목적

이 원칙의 주목적은 복잡성을 줄이는 것이다.
코드가 약 200줄에 불과한 프로그램을 위해 정교한 디자인을 만들 필요는 없고, 십여 개의 메서드를 멋있게 만들면 그걸로 충분하다.

설명

진짜 문제들은 프로그램이 계속해서 성장하고 변경되면서 나타난다.

• 어느 시점에 이르면 클래스들은 너무 커져서 더 이상 그 세부 내용을 기억할 수 없게 되고, 코드 탐색은 매우 느려지고, 특정 코드를 찾기 위해 클래스나 프로그램 전체를 훑어봐야 할 것이다. 프로그램의 너무 많은 인터페이스, 클래스와 유닛의 수는 두통을 유발하며, 코드에 대한 통제력을 상실하고 있다고 느끼게 될 것이다.
  

또한, 클래스가 너무 많은 작업을 수행하는 경우, 그중 하나가 변경될 때마다 클래스를 변경해야 할 때 변경할 생각이 없는 클래스의 다른 부분이 손상될 위험이 있다.

프로그램의 특정한 측면에 집중하기 어려워지면 단일 책임 원칙을 떠올려 클래스를 나눠야 하는지 확인해봐야 한다.

예시

Employee(직원) 클래스는 여러 가지 이유로 변경될 수 있다.
예를 들어, 직원 데이터 관리와 관련된 변경 또는 작업표 보고서의 형식 변경 등이 있고, 이러한 변경 사항들을 처리하기 위해 클래스 내의 코드를 변경해야 할 필요가 있다.

수정 전: 클래스에는 여러 가지 행동들이 포함되어 있다.

작업표 보고서의 인쇄와 관련된 행동을 별도의 클래스로 옮기면 문제를 해결할 수 있다.
이 변경을 통해 다른 보고서 관련 항목들을 새로운 클래스로 이동할 수 있다.

수정 후: 추가 행동들은 각각의 자체 클래스에 있다.

결론

이 원칙은 클래스나 모듈은 단 하나의 변경 이유만을 가져야 한다는 것을 의미한다.
클래스나 모듈이 너무 많은 책임을 갖게 되면 변경 사항이 발생했을 때 다른 부분에도 영향을 미칠 수 있다.
따라서 각 클래스나 모듈은 하나의 명확한 책임을 가져야 하며, 변경될 이유도 단 하나여야 한다.
이를 통해 코드의 응집성을 높이고 유지보수성을 향상시킬 수 있다.