객체지향의 핵심 원리와 원칙들
SRP, 단일 책임 원칙
SRP : Single Responsibility Principle
하나의 클래스는 하나의 책임만을 가져야 한다.
"책임은 변경하려는 이유" 라고 로버튼 C.마틴이 말했습니다.
책임은 변경의 이유
스프링의 기본적인 패턴입니다. 각 3개의 컴포넌트들은 각각의 역할이 있습니다.
여기 각각의 역할에 변경의 이유들이 숨어 있습니다.
컨트롤러는 HTTP 요청을 받지 않게 된다면 ? -> 컨트롤러 수정
서비스의 기능이 변경 된다면 ? -> 서비스 수정
레포지토리가 파일에 저장하는 것으로 변경된다면 ? -> 레포지토리 수정
각각의 변경사항은 서로에게 영향을 끼치지 않습니다. 객체지향적으로 코드가 작성되었다면 단일 책임 원칙이 지켜지게 됩니다. 각각의 컴포넌트들은 하나씩의 변경의 이유를 가지고 있는 것 입니다. 이 코드에 단일책임원칙을 깨는 극단적인 예시를 보여드리겠습니다.
단일 책임 원칙이 깨진 상황들
세개의 컴포넌트를 하나의 컴포넌트로 만들었습니다. 이제 세개의 책임을 가지고 있고 세개의 변경의 이유를 가지고 있습니다. 이제 하나의 변경에도 해당 클래스를 변경해야하는 문제가 발생하게 됩니다.
또 다른 상황입니다. 서비스에서 예외 발생 시 HTTP 상태코드를 담은 예외를 던진다는 가정을 하겠습니다. 이게 왜? 라고 생각할 수 있지만 추후 컨트롤러에서 메시지큐를 통해서 요청을 받는다고 변경을 하게 될 시 서비스코드도 변경되어야 합니다.
이런 문제는 캡슐화가 깨져있기 때문에 발생하는 문제입니다. 컨트롤러만 알고 있어야할 정보를 서비스가 알고 있기 때문입니다.
단일 책임 원칙이 지켜진 코드가 가지는 장점
단일 책임 원칙을 지키는 코드는 각각의 클래스가 응집력이 높기 때문에
코드의 재사용성이 높아지고, 캡슐화를 통해 한 클래스의 변경이 다른 클래스에 영향을 미치지 않도록 만듭니다.
결론
하나의 클래스는 하나의 책임만을 가져야 한다.
해당 게시글은 프로그래머스 스쿨 강의
"실무 자바 개발을 위한 OOP와 핵심 디자인 패턴(푸)"
를 정리한 내용입니다. 쉽게 잘 설명해주시니 여러분도 강의를 듣는 것을 추천드립니다.
