들어가며
회사에 입사한지 어느덧 1달이 조금 넘었다. 이제 슬슬 회사의 비즈니스 코드가 어느정도 눈에 잡히기 시작한 요즈음이다.
요즘들어 느끼고 있는 부분은 아침에 출근하고 부터 하루의 대부분의 시간을 상대방이 짜 놓은 코드를 읽는 것 이라는 것이다.
SOLID 원칙?
-
SRP(Single Responsibility Principle) : 단일 책임 원칙
-
OCP(Open Closed Principle) : 개방 폐쇄 원칙
-
LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
-
ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
-
DIP(Dependency Inversion Principle) : 의존 역전 원칙
SRP ?
- 클래스(객체)는 단 한 개의 책임을 가져야 한다 (클래스를 변경하는 이유는 단 한 개여야 한다)
책임..? 책임이란 무엇일까?
객체 지향에 있어서 책임은 다음과 같이 2가지가 있다.
할 수 있는것.
해야 하는것.
❗️즉 하나의 객체는 자신이 할 수 있는 것과 해야 하는 것만 수행 할 수 있도록 설계되어야 한다는 법칙이다.
예를 들어서 보고서를 편집하고 출력하는 모듈을 생각해 보자. 이 모듈은 두 가지 이유로 변경될 수 있다.
-
보고서의 내용 때문에 변경. (실질적 요인)
-
보고서의 형식 때문에 변경. (외부적 요인)
이 두 가지 변경은 하나는 실질적이고 다른 하나는 꾸미기 위한 매우 다른 원인에 기인한다. 단일 책임 원칙에 의하면 이 문제의 두 측면이 실제로 분리된 두 책임 때문이며, 따라서 분리된 클래스나 모듈로 나누어야 한다. 다른 시기에 다른 이유로 변경되어야 하는 두 가지를 묶는 것은 나쁜 설계일 수 있다.
만약 이를 지키지 않을 경우 새로운 요구 사항이나 변경 사항이 있을 때 모든 부분을 변경해야 할 수 있고 결국 유지보수 하기 어려운 대상이 된다.
따라서 하나의 클래스를 여러 클래스로 쪼개어 관리하는 것이 변경에 유연하게 대처할 수 있는 설계라고 할 수 있다.