여섯번째 기업 과제 회고록 (Deer)

이번 과제는 폴리곤 데이터 타입을 다뤄볼수 있는 과제였다.

처음 보는 데이터타입, 17개 가량의 테이블을 만드는 등, 나름 많은 일이 있었다.

 

이 폴리곤 아니다.

 

하지만 이 글에서는..

 

NestJS로 프로젝트 진행중

메소드로 둘것이냐 클래스로 분리할 것이냐 논의를 했었는데

그것에 대해 간단하게나마 나의 생각을 정리를 해보려고 한다.

 

사실 제대로 된 판단을 내리기에는 경험과 생각할 시간이 부족했다.

 

 

첫번째 방식은 각 클래스에서 계산 로직을 가지고있다.

할인클래스 {
  첫이용할인클래스()
  파킹존할인클래스()
  ...
}

 

두번째 방식은 할인 판별과 계산(적용)로직을 분리한다. 계산 모듈이 따로 있다.

할인여부확인클래스 {
  첫이용할인여부확인메소드()
  파킹존할인여부확인메소드()
  ...
}

계산클래스 {
	...적용된 할인 목록을 받아서 계산
}

편의상 할인 여부를 판단하는 클래스는 확인 클래스

계산하여 할인을 적용하는 클래스는 계산클래스 라고 칭하겠다.

 

내 생각에는 결국 확인과 계산을 각각의 클래스로 나눌것인지의 차이인 것 같다.

 

애초에 각 할인 클래스가 계산로직을 가지고 있지 않다면

할인 여부 판단 로직의 패턴이 단순하고 짧기 때문에

굳이 클래스의 메소드를 다시 클래스로 나눌 필요가 없다.

 

단순히 데이터베이스에 인자를 넘기고 (true, flase) 여부에 따라

해당하는 항목을 가져오는 것이 판별할때 서비스에서 로직의 전부이기 때문이다.

실질적인 로직은 repository에 있다.

할인 적용 여부 확인 메소드

 

 

따라서 나는 할인을 적용하는 과정에서

할인 여부 판별과, 계산하여 적용하는 행위를 따로 나누느냐 마느냐에 대한 고민을 하고있다.

 

계산로직을 따로 두어서 얻는 이점은,

적용된 할인(벌금) 목록을 받아서 연산만 하면 된다.

 

퍼센트(10% 할인)와 금액 (100원 할인)을 구분할수있는 데이터가 들어있기 때문에

할인 방식을 구분하여 계산한다.

 

각각의 클래스가 계산 로직을 가지고 있다면, 코드 중복이 일어나게 된다.

 

만약 거리비례 할인(벌금), 등의 새로운 방식의 로직이 필요해진다면

그리고 그 계산 로직이 복잡하고 여러곳에서 쓰이게 된다면

계산(적용) 클래스를 만들어 한곳에서 관리하는 것이 유지보수에 유리하지 않을까?

 

.....

 

 

사실 잘 모르겠다.

확인 클래스와 계산 클래스를 따로 관리하고

확인 클래스에는 확인에 대한 메소드들만을 가지고 있다고 해도

 

할인 적용 여부 확인 클래스에 매번 새롭고 복잡한 로직이 추가되는 일이 잦아진다면

결국 메소드를 클래스로 만들어 따로 관리 해야할지도 모른다.

아래의 단순한 할인 확인 메소드와는 다른 방식이다.

 

하지만

할인 여부 확인 클래스 안의 메소드들을 각각의 클래스로 만들어 관리한다면

확인 클래스의 생성자안에 들어가는 의존 객체의 개수가 매번 늘어나게 되는데

이것이 뭔가 자연스러워보이지 않는다..

할인 모듈에 각각의 할인 서비스가 추가된 모습

 

지금 당장은 NestJS에서 클래스별로 나누어 관리할수있는 좋은 방법이 떠오르지 않는다.

 

이번 과제의 핵심은 사실 이 부분이었는데..

이것에 대해서 깊게 생각하고 논의 할 시간을 충분히 가지지 못해서 아쉬웠다.

 

그리고 이제 마지막 과제를 준비해야한다..

마침 다음 과제에서 디자인패턴이라는 키워드가 나왔다.

 

아직 깊게 공부해보지 못했었는데 과제를 통해 공부해볼 기회다. 🙂

 

결과물

https://github.com/preOnboarding-Team13/Assignment-6-deer

GitHub - preOnboarding-Team13/Assignment-6-deer: deer!!