2024 08 06 TIL SRP...?

SRP(Single Responsiblity Principle) : 단일 책임 원칙

객체 지향 설계의 5대 원칙 중 하나인 SOLID 원칙 중 첫번째 원칙. 소프트웨어 개발에서 각 클래스나 모듈이 하나의 책임만 가지도록 하는 것을 의미한다.

 

우리 조는 팀 프로젝트를 과제 발제 시간에 공유된 템플릿을 이용해서 과제를 하고 있었는데, 이건 메인 자바 파일에 모든 필드, 모든 메서드들을 다 여기서 관리하는 방식이라 튜터님께서 중간 점검차 오셔서 '객체 지향적 설계에는 SOLID라는 게 있다. 거기에 단일 책임 원칙이라는 게 있는데, 지금 메인 자바 파일이 너무 많은 기능을 하고있다. 이거를 객체 지향적으로 바꿔보는 게 좋다.'는 이야기를 해주셨다. 

 

그래서 단일 책임 원칙을 내 나름대로 공부하면서 하다가 뭔가 점점 이상한 점을 발견했다. 

...

 

진짜 이렇게 하는 게 맞나? findStudent() 메서드를 끌어쓰려면 util 패키지를 임포트하고 FindStudent.findstudent(); 이런 식으로 써야하는데 이게 진짜 코드 가독성이 좋나?? 그렇다고 저렇게 길게 늘여쓰는데 유지보수성이 좋다고 말할 수 있는 건가??? 

 

 

이렇게 하는게 불편하긴 하지만 SRP를 준수한다고 하니 일단 진행했다. 그러다가 나중에 팀원들이랑 회의를 하는데 개발을 어느정도 공부하시고 내일배움캠프에 들어오신 팀원분이 뭔가 잘못 알고계신 거 같다고 말씀해주셔서 튜터님께도 설명드리고 이렇게 하는 건 아니라고 답변을 받았다. SOLID 원칙이라길래 무조건 지켜야 하는 줄 알았는데 알고보니 현실적으로 적당히 선을 지키면서 써야 한다는 것이다. 

너무 세분화하면 파일 수가 많아지고 끌어다 쓰기도 힘들어져 관리가 어려워질 수 있고, 반대로 너무 통합하면 변경의 이유가 많아져서 유지보수성이 떨어질 수 있다고 한다. 

 

그래도 아직 어느정도로 적용해야 하는지 감이 안 잡혀서 찾아보니 

 

1) 관련된 기능은 하나로 묶는다. 

    서로 강하게 연관된 기능들은 하나의 클래스로 묶어버리는 게 좋다. 예를 들어, 데이터베이스 접근 로직은 'Repository' 클래스로 묶을 수 있다.

2) 코드의 응집도와 결합도 고려

    응집도: 클래스 내 메서드와 필드가 얼마나 밀접하게 연관되어 있는지 

    결합도: 클래스 간의 의존성을 나타낸다. 

    SRP를 적용할 때는 응집도를 높이고 결합도를 낮추는 것이 좋다. 

3) 실제 프로젝트 사례를 참조한다. 

    깃허브 같은 곳에서 실제 프로젝트 한 것들을 많이 보면서 다른 사람들은 어떻게 SRP를 적용했는지를 보면서 배우는 게 아무래도 제일 빠른 방법이다.

 

결국 제일 좋은 건 남들은 어떻게 했는지 보고 배우는 것인데, 이것도 아직 내가 이 프로젝트가 좋은 방식으로 설계된 프로젝트인지, 아니면 별로 안 좋은 방식으로 설계된 프로젝트인지 판단할 실력은 아니라서, 항상 그런 점을 생각하면서 프로젝트를 보고 배워야겠다는 생각이 들었다. 이것도 사실 SOLID의 S가지고 지금 쩔쩔 매고있는 건데, 5원칙을 전부 적절히 활용하면서 프로젝트를 하는 건 아직 너무 어려운 길인 것같다. 그래도 주말에 SOLID의 나머지 원칙도 따로 공부해보고 블로그에 정리해보려고한다.