"프리코스 17일차" 설계 방식에 대해 고민해보기, 3주 차 미션 MVC 구조 설계 완료

우아한테크코스

"프리코스 17일차" 설계 방식에 대해 고민해보기, 3주 차 미션 MVC 구조 설계 완료

kanado 2024. 10. 31. 23:13

📝 오늘의 Todo 리스트 체크

MVC 디자인 패턴
- 메서드 네이밍에 대해 고민해보기 ✅
- 메서드가 한가지 일을 하는지 확인하는 나만의 기준 업그레이드 ✅
- 객체로 분리하는 기준에 대해 생각해보기 ✅
- 3주 차 미션 MVC 구조 설계 ✅
(학습) 의존성 주입 공부 🔺
-> 설계 과정이 오래 걸려서, 오늘은 의존성 주입에 대한 큰 그림만 이해하고, 내일 구체적인 내용까지 학습래서 블로그로 작성할 예정

메서드가 한가지 일을 하는지 확인하는 나만의 기준

2주 동안 2미션 애플리케이션을 꼼꼼하게 설계하고 구현을 해왔다. 설계 과정에서 다음과 같은 규칙을 준하도록 노력했다.

1. TDA(Tell, Don’t Ask) 원칙을 준수하기

2. 단일 책임 원칙(Single Responsibility Principle, SRP) 준수하기

3. 클래스, 메소드, 변수 이름을 축약하지 않기

4. 각 메소드가 "뭐뭐 하기"로 설명 가능하게 설계하기 (예를들어, 자동차 위치 확인하기)

마지막 4번째 규칙은 내가 만든 나만의 규칙으로 메소드의 설명이 "뭐뭐 하기"와 같은 형태로 설명될 수 있어야 한다는 것이였다. 이렇게 하면 코드의 목적이 명확해져, 메소드가 하는 일을 직관적으로 파악할 수 있다. 또한, 이 원칙을 따르면 설계 단계에서 한 메소드가 두 가지 이상의 일을 수행하지 않도록 방지할 수 있었다. 즉, 단일 책임 원칙을 이 규칙으로 나만의 기준점을 세웠다.

하지만 이 [각 메소드가 "뭐뭐 하기"로 설명된다]라는 규칙을 고려하면서 MVC 구조를 설계한 후 실제 코드 구현을 시작할 때마다 단일 책임 원칙을 위반하는 클래스나 메서드들이 등장했다. 이를 통해 나의 객체를 바라보는 시각이 잘못되었나? 아니면 내가 준수하는 메서드가 한가지 일을 하는지 확인하는 나만의 규칙이 잘못 되었나? 생각이 들었다.

객체를 바라보는 시각을 객체의 행동으로 돌리기

객체를 바라보는 시각이 명확하지 않아 객체를 나누는 기준이 불분명했고, 그 결과 한 클래스에 여러 역할이 집중되었던 것 같다. 그래서 나의 잘 못된 시각을 바로 잡기 위해 "객체지향의 사실과 오해"책을 다시 펼치게 되었다.

그 책에서는 객체에 필요한 상태가 무엇인지 먼저 결정하고, 그 다음에 그 상태에 필요한 행동을 결정하는 방식이 잘못되었다고 지적했다. 그 순간 바로 나는 애플리케이션의 시스템을 객체로 분리할 때 어떻게 객체를 나누었는지 다시 한번 생각해보았다. 예상대로 나 역시 객체의 상태를 우선 결정하고, 그 상태에 맞는 행동을 추가하는 방식으로 객체를 설계했었다. 😅

객체를 그렇게 설계하게 되면 캡슐화 문제, 다른 객체들과 협력에 불적절함, 객체의 재사용성 저하 등과 같은 여러 문제점들이 발생할 수 있다.

그래서 이제는 명심하기로 했다. 객체는 다른 객체와 협력하기 위해 존재하며 객체의 행동은 객체가 협력에 참여할 수 있는 유일한 방법이고, 객체가 적합한지를 결정하는 것은 그 객체의 상태가 아니라 행동이다.

메서드 네이밍의 중요성

그렇다면 객체를 적합하게 나눌 수만 있다면 그 객체의 각 행동(메서드)가 한가지 일을 반드시 할 것인가? 2주차 미션 코드 리뷰를 받으면서 가장 많이 받았던 피드백은 메서드 이름에 대한 것이였다. 어떤 사람은 startRacing -> initializeRacing -> Racing.startRacing으로 흐름이 이어지면서 메서드 이름이 다 비슷해서 메서드의 역할 예측이 어렵다는 피드백을 남겨 주셨고, 어떤 사람은 updateWinnerLocation 메서드를 외부에서 본다면 car.updateWinnerLocation 이라고 되어 있어 car 이라는 모델 내부에 winnerLocation 이라는 필드가 있다는 착각을 했다고 하셨다.

이런 피드백을 받으며 메서드 네이밍에 더 신경 써야겠다고 느꼈다. 각 메서드나 연결된 메서드들의 이름만으로도 해당 메서드가 수행하는 역할과 해당 로직이 의도하는 기능을 쉽게 이해할 수 있도록 해야겠다는 생각이 들었다. 또한, 명확한 네이밍은 메서드가 과도하게 많은 역할을 하거나 여러 책임을 가지지 않도록 자연스럽게 제한하는 역할도 할 수 있다는 점을 깨달았다.

메서드가 한가지 일을 하는지 확인하는 나의 새로운 기준

이번 3주 차부터는 메서드가 한 가지 일을 하는지 확인하기 위해 나의 새로운 기준을 다음과 같이 업그레이드했다. 객체를 상태가 아닌 행동 기준으로 나누고, 각 행동(메서드)의 이름이 의도와 역할을 명확하게 전달하는지 확인하며, 완성된 메서드가 "뭐뭐 하기"로 설명될 수 있는지를 점검하는 것이다.