Solid

지난 포스트에서 다루었 듯이 책임이란 "변경의 이유"이다. 하지만 단일 책임 원칙을 고려하면서 어떠한 애플리케이션을 구현하다 보면 책임에 대해 고민에 빠지게 된다. 변경의 이유는 절대적으로 정해져 있는 것이 아니기 때문이다. 책임 == 기능 ?단일 책임 원칙, 혹은 SRP에 대해서 리서치를 하면 다양한 예시들을 접할 수 있다. 하지만 많은 예시들의 클래스에선 하나의 메서드만을 가지고 단일 책임 원칙을 설명하는 경우가 많다. 객체가 한 가지의 기능 만을 가졌을 때 단일 책임 원칙을 논하기는 매우 쉽기 때문이다. 그래서 그러한 예시들과 단일 책임 원칙에 대한 설명을 보다 보면 이해가 되는 듯 싶다. 하지만 실제로 단일 책임 원칙을 고려하며 설계를 하거나 구현을 하게 되면 무언가 헷갈리게 된다. 홀로 공부하며..

소프트웨어를 처음 공부하기 시작하고 나서 가장 어려웠고 지금도 어려운 부분이 SOLID이다. SOLID를 공부해야겠다 생각하고 처음 접하게 되는 것이 SOLID의 S인 Single Responsibility Principle, 단일 책임 원칙이다. 이리 저리 구글링을 해보며 단일 책임 원칙에 대해 공부하고 이해했다 싶더라도, 막상 적용해보려니 어려움을 많이 느꼈다. 그렇게 시행착오를 겪으며 나만의 결론에 어느정도 도달하게 되었다. 물론 아직 부족하지만, 내 생각들을 정리하며 복습해보려 한다!🚀 책임이란 무엇일까?SOLID라는 다섯가지 원칙은 객체지향의 절대적인 원칙이 아니다. Clean Code의 저자인 로버트 마틴이 객체지향의 원칙으로서 권장하고 이제는 주류로 자리잡은 원칙이 SOLID이다. 로버트 ..