스터디 면접을 보면서 SOLID에 대한 질문이 있었다. 찾아본 기억은 있는데 기억이 가물가물 했다. 분명, “대충 객체지향과 관련된 내용이구나.” 하고 별 대수롭지 않게 넘겼을 것이다. 그래서 그런지 간신히 ‘단일책임원칙’ 이름만 하나 기억하고 있었다. 과거의 나 자신을 반성하면서 이번엔 제대로 알아볼 예정이다.
간단하게 말하자면, 객체지향 언어에서 프로그래밍을 위한 일련의 원칙이다. SOLID 원칙은 코드를 더 견고하고 유지보수에 용이하도록 촉진하기 위해 고안된 원칙이다. 각각의 원칙은 다음과 같다.
5가지 원칙에 대해서 하나씩 다뤄보겠다.
단일 책임 원칙이라는 말만 들었을 때는 대체 무슨 11 의미인지 도통 이해가 안되었다. 간단히 적어보자면, 각 소프트웨어 모듈은 변경될 이유를 하나만 가져야 한다는 원칙이다. 사실 이렇게 설명해도 이해가 안되기는 마찬가지다. 단일 책임 원칙이란 용어는 어쩌다 생겨났는가?
1972년 David L. Parnas 의 "시스템을 모듈로 분해하는 데 사용해야 할 기준에 대한 연구” 의 결론에 기반하여 Robert C. Martin에 의해 정의되었다. Parnas의 결론 중 일부는 다음과 같다. “시스템을 모듈로 분해할 때 흐름도(Flowchart)를 기준으로 시작하는 것은 거의 항상 잘못된 것임을 보여준다. 대신, 복잡한 설계 또는 변경될 가능성이 있는 설계 결정 목록에서 시작하는 것을 제안한다.” 즉, 모듈을 변경될 가능성에 기반하여 분리하여야 한다는 것이다.
변경될 가능성은 코드에 의해 발생하는 것이 아닌 외부(프로그래머)에서 기인한다. 변경 사항이 생기게 되면 반드시 모듈의 변경이 발생하게 된다. 여기서 “변경될 이유를 하나만 가져야 한다.”의 의미를 생각해보자. 각 모듈은 반드시 하나(one-and-only)의 변경의 이유(책임, reason to change)를 가지며 해당 모듈의 변경은 부여된 변경의 이유에 의해서만 일어나야함을 의미한다.
다음의 예시를 통해 자세히 알아보자.
기업의 구조는 CEO 아래에 COO(운영), CFO(재무), CTO(기술) 등의 C-레벨의 임원들이 있다. 각 임원들은 할당된 부서에 대한 책임을 가지고 있다.