넘블의 - 가장 실무에 가까운 쿠팡 클론 코딩 챌린지 1회차 회고


  • 넘블의 “가장 실무에 가까운 쿠팡 클론 코딩 챌린지”에 참여하였고 1회차 과제를 하면서 생각한 점과 느낀점을 요약하였습니다.

1. 인증 관련 비즈니스 로직을 다루는 모듈 리팩토링하기

  • UserService와 AuthService 클래스에서 cookie와 관련된 get, set 부분이 반복되기 때문에 반복되는 부분을 함수로 정의한 공통의 클래스 Service를 정의했다
  • 그리고 그 클래스를 상속해서 AuthService와 UserService에서 사용할 수 있도록 했다
  • 이 때, Service 클래스는 토큰을 get 하는 로직과 set 하는 로직이 정의된 각각의 인터페이스를 구현하는 형태로 클래스를 정의해주었다
  • 이는 이후 OrderService, ItemService와 같은 클래스들이 이후에 추가되었을 때 해당 클래스가 앞서 정의한 인터페이스를 새롭게 구현한 클래스를 만든 후 이를 상속해서 사용할 수 있고
  • 뿐만 아니라 constructor에서 정의된 인터페이스 타입으로 클래스를 Dependency Injection 형태로 전달 받는 방식으로 인터페이스의 재사용성을 높일 수 있을 것이라 생각했기 때문이다

2. API request를 보내주는 useRequest 모듈 정의

  • 의존성 역전 원칙과에 대한 개념은 이해했지만 이것을 어떻게 react-query에 적용해야 하는지, 그리고 useRequest라는 Custom hook과는 어떠한 상관관계까 있는지 정확하게 파악하지 못했다
  • 이전에는 의존성 역전 원칙과 관련해서 인터페이스를 정의한 다음, 해당 인터페이스를 생성자에서 타입으로 받는 Dependency Injection 방식으로 문제를 해결했지만, 이번에 정의된 custom hook과는 어떻게 연결지어서 문제를 해결해야하는지 문제의 정확한 의도를 이해하기 힘들었다
  • 따라서 해당 문제는 우선 useQuery를 사용해서 추상화된 함수를 리턴하는 방식으로 문제를 처리했다.
  • 정확하게 의도를 파악하지 못한채로 문제를 해결했기에 추가적으로 어떤 방식으로 이를 확장할 수 있을지는 고민해보아야 할 것 같다

느낀점

  • 과제를 통해 클래스의 재사용성과 확장성이라는 관점에서 고민을 할 수 있었고 이 과정에서 객체지향의 개념인, 캡슐화, 추상화, 상속과 같은 개념들에 대해 다시 한번 학습할 수 있었다.
  • 또한 학습 과정에서 클래스 간의 Decoupling을 위해서는 상속보다는 Composition 방식으로 설계를 하는 것이 더 좋다는 것을 알 수 있었다.
  • 다만 useRequest 모듈을 정의하는 과제는 해당 문제의 의도를 정확하게 파악하지 못했기에 많은 시간을 들였지만 결국 정확한 문제의 의도를 파악하지는 못했다.








© 2020. by dkmqflx

Powered by dkmqflx