서비스 운영 및 유지보수를 하면서 리팩토링과 좋은 설계에 대해 관심이 많아졌습니다.
기초부터 다시 공부하는 마음으로 객체지향에 관해 공부하고 정리하려고 합니다.
피드백은 언제나 감사합니다. (🙆♀️)
객체지향의 주요 5가지 원칙(SOLID)을 공부하고 정리한다.
- SRP (Single Responsibility Principle) 단일 책임 원칙
- OCP (Open Closed Principle) 개방 폐쇄 원칙
- LSP (Liskov Substitution Principle) 리스코프 치환 원칙
- ISP (Interface Segregation Principle) 인터페이스 분리 원칙
- DIP (Dependency Inversion Principle) 의존 역전 원칙
객체지향 5원칙은 왜 필요한가?
올바른 객체지향 설계를 위해 수립한 원칙들이며 통틀어 객체지향 5원칙(SOLID)이라고 불립니다.
이는 필수로 적용하지는 않지만 적어도 이 원칙을 준수할수록 올바르게 설계된 객체지향이라 할 수 있습니다.
프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 소프트웨어를 만드는 데 도움을 주려고 고완되었습니다.
SOLID 원칙은 Robert C. Martin이 2000년도에 처음 소개한 원칙으로, 사실상 객체 지향 프로그래밍의 표준 규칙처럼 알려져 있습니다. 다섯가지 지침과 원칙을 통해 개발자는 읽기 쉽고 유지 보수가 쉬운 프로그램을 쉽게 만들 수 있습니다.
SOLID가 빛을 발휘하는 순간은 객체 지향 프로그래밍으로 만드는 프로그램의 크기가 클 때입니다. 이는 SOLID가 코드의 복잡성을 최소화하고 유지보수하기 쉬운 상태로 유지시키기 때문이죠.
단일 책임 원칙 (Single Responsibility Principle)
SOLID 원칙의 S를 담당하는 '단일 책임 원칙'은 다음과 같이 정의됩니다
"하나의 클래스(객체)는 하나의 책임만 가지며, 그 책임을 완전히 캡슐화해야 함을 일컫는다."
쉽게 말해서, 하나의 클래스로 많은 일을 하지 말고 딱 한가지 일만 수행하라는 뜻입니다.
만약 하나의 클래스가 하나 이상의 책임이 있다면, 이것은 결합(Coupled)를 불러오게 되며 추후 하나의 책임에 대한 변경이 생겼을 때 결합으로 인해 다른 책임까지 수정을 발생시키게 됩니다.
책임의 기준은 무엇인가?
그렇다면 한 가지 책임의 기준은 무엇일까요?
여기서 말하는 단일 책임은 절대적으로 측정할 수 있는 개념이 아니라 상대적이기 때문에 기준이 모호합니다.
어느 정도의 수준으로 추상화를 하느냐에 따라서 ‘단일’로 볼 수도 있고 아닐 수도 있습니다.
하지만, SOLID 원칙의 창시자인 Robert C. Martin은 단일 책임 원칙에 대해 같이 수정해야될 것들은 묶고 따로 수정해야될 것들은 분리하는 것으로 기준을 정해주었습니다.
이를 기반으로 '단일 책임 원칙'을 다음와 같이 재정의한다면 기준을 세우고 설계하는데 용이할 수 있습니다.
"클래스(모듈)를 변경하는 이유는 단 한가지여야 한다."
✔️ 단일 책임 원칙의 오해
메서드의 개수 != 책임의 개수
하나의 클래스에 메서드가 3개라고 책임이 3개인 것은 아니랍니다.
단일 책임 원칙은 '하나의 모듈은 하나의 일만 해야 한다'는 의미로 자주 오해되곤 하는데요.
이는 흔히 알려진 '하나의 함수는 하나의 일만 해야 한다'는 원칙과의 혼용되어 발생한 오해인 것 같습니다.
위의 원칙은 함수를 설계할 때 사용되는 원칙으로 단일 책임 원칙보다 저수준에서 사용됩니다.
'단일 책임 원칙'은 위에 언급한 정의처럼 '클래스(모듈)을 변경하는 이유는 단 한가지여야 한다'라는 의미로 하나의 '일'만 하는 것이 아니라 '수정 이유가 같은 것들을 묶는다'로 이해하는 것이 가까울 것 같습니다.
단일 책임 원칙은 왜 사용해야 할까?
단일 책임 원칙이 잘 적용되어 있다는 것은 각 클래스의 수정 이유가 단 한가지라는 뜻입니다.
즉, 특정 기능을 수정할 때 하나의 클래스만 수정하면 되기 때문에 유지보수가 편리해집니다.
(만약 단일 책임 원칙이 잘 지켜지지 않았다면 여러개의 클래스를 수정해야 할 것이다.)
또한 단일 책임 원칙에 따라 하나의 클래스가 하나의 책임만을 맡는다면 이후에 기능을 수정할 때 발생할 수 있는 사이드 이펙트를 막을 수 있습니다.
💡 단일 책임 원칙을 적용하면서 기존 코드보다 길이가 더 길어질 수도 있습니다.
하지만 전체 코드의 길이가 길어졌다 하더라도 하나의 클래스를 사용하는 것보다 여러 개의 클래스를 사용하는 것이 더 효율적입니다.
그래야 각 클래스의 의미를 파악하기도 쉽고 유지보수에 용이하기 때문입니다.
결론
단일 책임 원칙을 잘 지켰는지 판단하는 것은 쉽지 않은 일인것 같습니다.
개발자의 생각이 제각기 다르고 프로그램의 특성도 다르기 때문에 정해진 답은 없는 것 같습니다.
다만 중요한 것은 코드를 작성할 때, 단일 책임 원칙을 잘 지켰는지 생각해보는 것입니다.
하나의 클래스에 너무 많은 책임이 있는건 아닌지, 분리할 수 있는 변수와 함수가 많지 않은지 항상 고민할 수 있는 개발자가 되어야겠습니다.
Reference
