[우테코 프리코스 1주차] java-calculator 코드설명 [🛠️설계] (MVC 패턴 적용, OCP, SRP)

✏️ 코드

[문자열 덧셈 계산기] 김준형 미션 제출합니다. by JHZLO · Pull Request #183 · woowacourse-precourse/java-calcu

 

[우테코 프리코스 1주차] java-calculator 코드설명 [💻문제 해결] (정규 표현식, 이스케이프 문자)

 

 

 

---

✅ OCP / SRP의 원칙을 준수하다.

 

☑️ Open for Extension, Closed for Modification

제가 이번 미션에서 가장 집중하였던 부분입니다.

 

Calculator라는 과제를 받자마자 바로 확장성에 대해서 생각을 해보았는데요.

 

미션 과제에는 덧셈만 구현하라고 주어졌지만,

Calculator라는 특성상 확장성을 고려했을 때 덧셈 이외에도 곱셈, 뺼셈, 나눗셈 등등..

수많은 기능들이 확장 가능해야한다고 생각하였고, 이는 이번 과제 문제해결에 있어 생각의 시작점이 되었습니다.

Terms 객체 연산자 메서드

이렇게 고민을 하다보니 결국 Terms라는 객체가 Expression으로 부터 탄생하게 되었고,

해당 연산과 관련된 로직들은 Terms에서 진행함으로써

확장에는 열려있고 수정에는 닫혀있는 구조가 가능해졌습니다!

---

☑️ The Single Responsibility

모델을 과연 어디까지 분리해야할까에 대한 고민을 1주일동안 계속 하였던 것 같습니다.

 

SRP의 핵심은

"A class should have only one reason to change"

즉, "객체를 바꿔야될 이유가 하나" 입니다.

 

따라서 모델을 분리하는 데에는 명확한 이유가 있어야 하고 계속해서 이러한 이유를 찾고 분리하고자 하였습니다.

그렇게 일급 컬렉션과 원시값 포장을 진행하면서 Terms객체와 Term 객체가 나오게 되었고,

구분자만을 따로 관리하는 Separator 객체가 나오게 되었습니다.

---

✅ 비즈니스 로직과 validate 로직의 위치

☑️ 비즈니스 로직의 처리? Model? Service?

지난 한 달간 MVC 패턴에 대한 공부를 진행하면서 Service의 역할에 대해

과연 어디까지를 Service의 책임으로 넘겨줘야 하는가?

에 대해 많은 고민과 혼돈이 반복되었던 것 같습니다.

 

Service의 역할은 controller의 부담을 줄여주는 것 이라고 이해하였는데,

이는 너무 모호하고 model을 충분히 만들어서 해결이 가능한 부분이라고 생각하였습니다.

 

그래서

Service를 구상함으로써 코드의 복잡성을 줄이고 가독성을 높이느냐,
아니면 조금은 복잡해지더라도 모든 비즈니스 로직은 Model에서 처리하게 만드는 게 나을까?

에 대한 고민은 여전히 있는 것 같습니다.

 

이번 주차에서는 한번 Service 없이 구현하면서 "Model간의 메시지 전달에 집중하자"라는 마인드로
문제해결에 접근하게 되었고 위와 같은 구조가 만들어지게 되었습니다!

---

☑️ validate 로직의 위치

이번 미션의 핵심은 사실 validate를 처리하는 부분이라고 생각합니다.

이스케이프 문자를 비롯하여 많은 문자들이 사용자의 입력이 들어가게 되고,

이를 어떻게 validate를 진행하냐가 전체 코드의 로직에 있어서 핵심이라고 생각합니다.

 

그러면 이제 다음으로 자연스럽게 중요한 부분은 다음과 같습니다.

validate를 어디에 위치시킬 것인가?

이에 대해서도 지난 한달간 mvc 패턴을 공부하면서 validate 로직의 위치에 대해서 고민을 반복하였고,

 

validate 로직은 model의 생성자에서 진행하자!

이에 대한 결론으로는 위와 같이 생각하였습니다.

 

validate로직을 model에서 진행하게 되면,

• 객체의 무결성 보장
• 객체 생성 후 추가 유효성 검사 필요없음
• SRP 준수

와 같은 이점들을 챙길 수 있다고 생각했기 때문입니다!

Expression 객체 생성자

Term 객체 생성자

 

그래서 위와 같이 생성자 내부에서 validate 로직을 처리하였고,

Expression이라는 Model이 탄생하게 된 계기이기도 합니다.

---

👀 고민되는 부분

저의 구조를 살펴보시면
Expression 모델의 필드에서 Separator와 Terms를 정의하고 이를 기본 생성자에서 정의하는 방식입니다.

Expression 생성자 내부 로직

여기서 고민이 되는 것이,
Expression의 기본 생성자에서 정의할 때

validate로직을 맨 위에 배치하고 싶은데, 그러지 못한다는 점입니다.

 

Separator 객체에서는 커스텀 구분자가 있는 경우를 판단하고 해당되는 구분자들을 전부 반환하는 역할을 담당하고 있습니다.

 

따라서 Expression에서 구분자를 제외한 나머지 문자들에 대해서 validate를 진행하기 위해서는
결국 Separator의 반환값을 받고나서야 validate를 진행할 수 있다는 점입니다.

 

그래서 저렇게 중간에 validate 로직이 포함되게 되었고,

이는 구조의 통일성을 해치고 복잡도가 올라갔다고 생각합니다..

 

그래서 이를 어떻게 해결하면 좋을지에 대한 고민을 가지고 있습니다.