SOLID 원칙의 이면
SOLID 원칙 많이들 공부하시죠. 다섯 가지 원칙들의 정의, 그리고 원칙들이 적용된 코드를 습득하는데에서 그치지 말고 각 원칙들의 단점까지 파악해서 상황에 맞게 tradeoff를 제대로 할 줄 아는게 중요합니다.
S: 단일 책임 원칙을 지킬 때의 이점은 코드의 기능을 이해하기 쉽고 유지보수가 편리해지는 반면 단점으로는 지나치게 분리를 하면 전체 시스템을 파악하기가 어려울 수도 있고, 구현 난이도가 올라갈 수도 있습니다.
O: 개방폐쇄 원칙을 지켰을 때의 이점은 기능 변경 시 코드 수정 범위가 작고 확장성이 좋다는 것입니다. 반면에 단점은 코드의 복잡성이 증가하게 되죠. 코드를 읽기 더 어려워질수도 있고 타입이 많아지는 오버헤드도 발생하고요.
L: 리스코프 치환 원칙을 잘 지켰을 때의 이점은 코드의 예측 가능성, 신뢰성이 높아진다는 점입니다. 어떤 타입을 받았을때 내가 알고 있는 대로 동작할거라고 예상할 수 있으니까요. 반면에 단점은 유연함을 잃게 됩니다. 자식 클래스에서 약간의 창의성도 발휘할 수 없게 되죠.
저는 시간 관계상 여기까지만 쓰도록 하겠습니다. 인터페이스 분리 원칙과 의존성 역전 원칙은 어떤 장점과 단점들이 있을까요?
프로그래밍에서 보통 얻는 것이 있으면 잃는 것도 있다는걸 언제나 기억해야 합니다. 새로운걸 공부할 때는 동전의 양면을 모두 파악하는 습관을 들이는 것이 좋습니다.
다음 내용이 궁금하다면?
이미 회원이신가요?
2024년 5월 9일 오후 7:59
댓글 3
DI를 한다는 건... 런타임에 의존성을 결합하겠다는 것이고 이러한 의존성을 얻는 대신 빌드 타임에서 연산했을 때 얻을 수 있는 것들을 포기하겠다는 말이기도 하겠네요
@오종택 DI는 의존성 주입을 말씀하신거겠죠? SOLID의 의존성 역전(Dependency Inversion)과 의존성 주입(Dependency Injection)은 다른 얘기입니다만, 의존성 주입을 한다고해서 빌드 타임에서 무언가를 잃지는 않습니다.
@노수진 오 답변 감사합니다. 말씀해주신대로 의존성 주입을 말씀드린거긴 합니다. 의존성 역전을 구현하는 한 사례로서 의존성 주입을.. 비슷한 결로 생각했던거 같아요. 제가 잘 알지 못하는 부분이라 괜찮으시다면 조금 더 질문 드려보고 싶습니다만.. 어쨌든 의존성 주입을 했을 때 뭔가가 잘못되었다면 빌드타임이 아닌 런타임에 문제가 생길 것이기 때문에 유연성을 얻는 대신 문제를 발견할 수 있는 시점 같은 것들 또한 런타임으로 미뤄지는 것이 아닌가 생각을 했어요(빌드타임으로 당긴다고 그런 문제들이 없어지는 건 아니겠지만요). --- 혼자 곰곰 생각해봤는데 제가 언급한 부분은 DI, DIP와 직접적으로는 연관이 없는 부분 같네요 ㅎㅎ 지인과 전략 패턴 관련해서 얘기하던 부분을 잘못 끌어와서 엉뚱한 소리를 했지만 혹시 다른 분이 좋은 가르침을 주실 수도 있으니 지우지 않고 남겨두겠습니다 :)
