⚙️ Chapter 8. 단일 책임 원칙(SRP)
단일 책임 원칙(SRP) - Single-Responsibility Principle
단일 책임 원칙(SRP)
한 클래스는 단 한가지의 변경 이유만을 가져야 한다. (= 한 클래스는 한 가지의 책임만을 가져야 한다)
한 클래스가 하나 이상의 책임을 맡게 되었을 때, 한 책임에 대한 변경은 다른 책임을 충족시키는 클래스의 능력을 떨어트리거나 저하시킬 수 있다.
SRP를 지키지 않으면?
- 책임이 섞이게되므로 불필요한 컴파일 시간, 메모리 영역을 소비할 수 있다.
- 한 애플리케이션의 변경이 다른 애플리케이션의 재빌드, 재테스트를 유발하며, 잘못 동작할 수 있다.
책임이란 무엇인가?
책임(responsibility):
변경을 위한 이유
변경의 축은 변경이 실제로 일어날 때만 변경의 축이다. 아무 증상도 없는데 이 문제에 SRP나 다른 원칙을 적용하는 것은 현명하지 못하다.
결론
두가지 이상의 책임을 맡고 있다고 해서 무조건 SRP를 적용하는 것은 현명하지 못하다. 어플리케이션의 현 상황에 따라서 두 책임이 분리될 수 있도록 해야한다.
중요한 것은 요구사항의 변경에 맞게 적절하게 책임을 분배 하는 것인 것 같다.
⚙️ Chapter 9. 개방 폐쇄 원칙(OCP)
개방 폐쇄 원칙(OCP) - Open-Closed Principle
모든 시스템은 생명주기 동안에 변화한다. 이것은 개발 중인 시스템이 첫 번째 버전보다 오래 남길 원한다면 반드시 염두에 두어야 할 사실이다.
개방 폐쇄 원칙(OCP)
소프트웨어 개체(클래스, 모듈, 함수 등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.
- 확장에 대해 열려 있다. (= 요구 사항이 변경될 때 새로운 행위를 추가해 모듈을 확장할 수 있다)
- 수정에 대해 닫혀 있다. (= 모듈의 행위를 확장하는 것이 소스 코드의 변경을 초래하는 것은 아니다)
- 경직성(한군데의 변경이 의존적인 모듈의 단계적인 변경을 불러일으킴) 문제를 해결할 수 있다.
- OCP가 잘 적용된다면, 이미 제대로 동작하고 있던 기존 코드를 변경하는 것이 아니라 새로운 코드를 추가함으로써 변경할 수 있게 된다.
→ 모듈의 소스코드를 변경하지 않고 모듈의 행위를 확장해야 한다
해결책은 추상화다
모듈은 고정된 추상화에 의존하기 때문에 수정에 대해 닫혀있고, 추상화의 새 파생 클래스들을 만듦으로써 확장이 가능하다
일반화(Generalization) 을 통한 추상화: 인터페이스 or 추상클래스
왜 AbstractServer이 아니라 ClientInterface일까?
- 추상 클래스(인터페이스)는 자신을 구현하는 클래스보다 클라이언트에 더 밀접하게 관련되어 있기 때문이다.
예상과 자연스러운 구조
모든 상황에서 자연스러운 모델은 없다. 닫혀 있지 않은 것에 대한 변경은 항상 존재한다
- 폐쇄는 완벽할 수 없기 때문에, 전략적 이어야 한다. 설계자는 자신의 설계에서 닫혀 있는 변경의 종류를 선택해야 한다.
- 경험에서 얻은 통찰력이 필요하다.
- 가장 중요한 것은 미리 설계하지 말고, 변경이 일어날 때까지 기다리는 것 이다.
올가미 놓기
불필요한 복잡성이 발생할 수 있다. 그렇기 때문에 처음에는 코드가 변경되지 않을 것이라고 생각하고 작성한 다음, 변경이 일어나면 나중에 해당 종류의 변경으로부터 보호되는 추상화를 구현 한다.
결론
- 애플리케이션의 모든 부분에 추상화를 적용하지 말고, 프로그램에서 자주 변경되는 부분에만 추상화를 적용해야 한다.
- 어설픈 추상화를 피하는 일은 추상화 자체만큼이나 중요하다. → 어설프게 추상화 할 바에는 그냥 하지 말자!
