[Refactoring] 패키지가 무엇을 제공하는지 전달하자!

 

❐ Description

---

주로 Common, Util, Global과 같은 패키지 명을 많이 쓰는데, 이번에 과제하면서

Util도 여러 곳에서 사용하니깐 Common 하위에 들어가야 하지 않을까? 라는 생각을 했다.

 

그래서 아래의 키워드로 구글링을 했는데

util package goes under common?

구글링 과정에서 알게 Common, Util, Global, Base 같은 패키지명 사용을 지양하라는 글을 봤고,

이를 과제에 적용해보았다.

 

 

 

 

 

❐ Tag_v1.0

---

tag v1.0에서 사용한 패키지명을 다음과 같다.

 

#️⃣ Common

여기서 common의 역할은 프로젝트 전반에 사용되는 정보들을 제공한다. 하지만 네이밍만 봐서는 해당 패키지가

무엇을 제공하는지 명확하게 알기가 어렵다. 하물며 common은 쓰레기통 마냥 애매한 것들이 전부 모여있다. 

 

이렇게 common을 만들게 되면 개발 과정에서 애매한 것들은, "단순히 전역으로 사용되니깐 넌 common."이라는

생각을 하며 common이라는 곳에 몰아 넣고싶은 강한 충동이 생기는 것 같다. 

 

 

#️⃣ Util

Util을 보면 Random 번호를 생성하는 util성 클래스가 포함되어 있다. 사실 Util까지는 사용해도 된다고 생각했는데,

이는 프로젝트가 커졌을 때 그 장점을 얻을 수 있을 것 같다. 처음에는 해당 Util을 사용하는 쪽에 함께 정의해 두는

것이 가독성과 역할의 명활성을 최대한 노출할 수 있는 것 같다.

 

 

#️⃣ View

view에는 현재 IO를 처리하는 대부분의 것들과 결과를 담는 DashBoardView가 위치한다.

과연 view라는 네 글자만 보고 이를 짐작할 수 있을까? (코드 작성자인 나도 가리고 보면 모르겠네ㅋㅋㅋ)

그리고 현재 view 패키지는 두 가지 역할을 하고 있다. 

1. IO 작업에 필요한 것들
2. 결과 응답을 위한 DashBoardView

이는 패키지를 만드는데 옳지 못하다. 패키지는 비슷한 성질을 가지는 클래스의 모음인데 v1.0에서 view는

서로 다른 성질을 가지는 2개의 정보들이 모여있다. 결과적으로 응집성을 깨뜨린다.  

 

 

#️⃣ Exception

3개의 Exception 패키지가 보인다. 제일 상단에 Exception을 두고 그 하위에서 도메인 별로 예외를 나눈다면?

더 깔끔하고 해당 패키지가 어떤 도메인에 해당하는 예외를 모아뒀는지 한 눈에 보기 쉬울 것 같다.

 

 

#️⃣ Message

사실 Message는 event 처리를 담당하는 클래스들이 들어가는게 맞는 것 같다.

이 부분도 변경이 필요하다.

 

 

 

 

 

❐ Tag_v1.3

---

v1.1, v1.2를 거쳐서 최종적으로 다음과 같은 구조를 가지게 됐다

 

#️⃣ Common

쓰레기 통이 였던 common 패키지를 없애버렸다. 기존에 있던 패키지들은 아래와 같이 변경 및 삭제 되었다.

Before	After
config	racingcar 하위로 위치 재조정
constant	정의된 상수를 연결된 도메인에 할당하여 해당 패키지 제거
exception	IO에 사용되는 Exception과 Business에서 사용하는 Exception으로 분리
message	패키지가 제공하는 클래스를 표현하기 위해 error로 패키지명 분리

 

 

#️⃣ Util

.
├── car
│   ├── Car.java
│   ├── Cars.java
│   ├── MovementCondition.java
│   ├── MyProgress.java
│   ├── Speed.java
│   └── SpeedGenerator.java   // (현재는) Speed 도메인에 종속

이렇게 종속되는 도메인 클래스로 위치를 이동시켜 주었다. 결과적으로 Util 패키지는 제거할 수 있게 됐다.

물론 추후에 프로젝트가 커지고 Util 클래스가 많아지게 된다면 "그 때" Util 패키지를 만들면 될 것 같다.

 

 

#️⃣ View (여기가 제일 재밌었다.)

과제를 하면서 IO가 진짜 너무 거슬렸는데, 패키지 구조를 리팩토링 하는 과정에서 굉장히 좋은 아이디어가

떠올랐다. App or Web 서비스라고 가정했을 때 입출력을 담당하는 곳은 Front 쪽이다.

즉, 사용자로 부터 데이터를 받고, 그 데이터를 적절히 가공해서 서버에 요청 보내고, 마지막으로 서버로 부터

전달 받은 json object를 사용자에게 제공해주는 건 Front의 역할이다.

v1.0~1.2에서는 IO의 역할과 Business 역할이 얽혀있다. 그래서 서로 뜯어내기 위해 구조를 변경하기로 했다.

 

 

 

 

 

❐ 최종 프로젝트 Structure

---

애플리케이션의 전체적인 구조와 각 구성 요소의 역할을 도식화 해봤다.

• Application.java가 애플리케이션의 진입점으로서 전체적인 흐름을 관리하고
• AppConfig가 의존성 설정을 담당하며
• FrontController와 ServerController가 Middleware를 사이에 두고 데이터를 주고 받는다.

 

이 구조의 장점은 IO를 처리하는 로직과 Business를 처리하는 로직을 각각 front와 server로 분리하였기

때문에 front와 sever 패키지는 loose coupling 하게 된다. 이로써 프로젝트 확장성도 좋아졌고, 책임을

적절히 떼어낼 수 있게 된다.

 

물론 문제도 있을 것 같다. 예를 들어 비슷한 성격의 예외 클래스가 중복으로 생성된다거나, 요구사항이 추가

됨에 따라 Middleware가 데이터 전달 이외에 더 많은 일을 하게 될지도 모른다. 이럴 때는 Middleware의

세분화를 통해 문제를 풀어나갈 수 있다고 생각한다.

 

 

 

 

 

---