우아한 테크코스 3주차를 진행했다.
3주차는 로또문제로, 도메인 로직, 서비스로직을 분리하고, 단위테스트를 수행하는 것이 주요 목표였다. 과정에서 클래스를 분리하기 위해 노력했다.
도메인로직? 서비스로직?
뭔소린지 처음에 전혀 이해를 못했다.
해당 블로그를 보고 좀 이해할 수 있었다.
https://velog.io/@eddy_song/domain-logic
비즈니스 로직, 도메인 로직이 도대체 뭐지?
🙄 내 앱은 아직 비즈니스가 아닌데요...?
velog.io
친구가 말하길 비즈니스로직은 DB에 담기는 데이터들을 처리하는 로직들이라고 생각하면 좀 편하다고 한다.
나는 여전히 좀 어려운듯...
입출력
역시 FE는 입출력이 전부다.
이번에는 무려 입출력이 세개...!
이걸 과연 어떻게 깔끔하게 비즈니스로직과 분리할까 한참 고민했다.
입력하는 함수의 콜백을 벗어나는 순간, 더이상 입력을 받을 수 없게된다.
예를들어 이런 코드의 두번째 저쩌구 함수는 실행 안된다.
MissionUtils.Console.readLine("어쩌꾸...",(input)=>{
MissionUtils.Console.print(input);
});
MissionUtils.Console.readLine("저쩌꾸...",(input)=>{
MissionUtils.Console.print(input);
});모든 함수가 입력 함수 내부에서 실행되어야하므로 전부 콜백으로 처리해주었다.
처음에 이렇게 처리하니, 콜백으로 들어온 함수의 메서드에서 해당 클래스를 찾지 못했다.
여기서 this.generateLottosMoney의 this를 찾지 못해서 오류가 발생하게 된다.
그래서 찾아본 방식이 call과 bind이다.
this 바인딩
그렇다. 내가 쓰는 this는 대부분 내가 생각하는 그것이 아니었다. js의 this는 함수 호출방식에 따라 결정된다. js의 함수는 호출될 때, 매개변수로 전달되는 인자값 외에 arguments 객체와 this를 암묵
0422.tistory.com
이렇게 했더니 피어리뷰에서 좋은 평가를 받을 수 있었다.
MVC모델
이번 미션을 통해 왜 MVC모델을 사용하는지 알 수 있었다.
Model을 통해 주요 비즈니스 로직을 처리하고, Controller가 View로 결과를 보여준다.
각 객체는 MVC의 특정 부분에 대한하나의 역할을 가질 수 있었고, 더불어 Model에 대한 단위테스트가 용이했다.
OOP SOLID
OOP형태로 짜다보니 아무래도 OOP의 기준에 적합하게 짜려고 많이 노력했다.
이번 활동을 통해 배운 OOP개념을 적극적으로 활용할 수 있었다.
SOLID
SOLID Single Responsibility Principle(SRP) 가장 핵심이며, 가장 지키기 어렵다. ⇒ 클래스는 단 한가지의 변화만 가진다. 즉, 단 하나의 책임만 가진다. 행동(책임) 하나에 연관된 속성들을 엮어 클래스로
0422.tistory.com
아래는 최종 UML이다.
이번 미션을 통해 UML작성에 대해서도 공부할 수 있었다.
LottoGame 모델을 통해 Lottos, Lotto, Result, BonusNumber, Money모델에 바로 접근하고,GameController가 이들을 생성하여 LottoGame에 할당한다. 컨트롤러는 입출력을 호출하여 사용자에게 보여주는 구조이다.
구조자체는 아주 만족스럽다고 생각한다.
아쉬운점
실수가 몇가지 있었다.
1. Lotto클래스를 옮기면 안되지만 옮겼음
2. 디렉토리 구조... 설명하는 것에 실수가 있었음
3. airbnb 컨벤션에 어긋나는 부분이 존재함
셋다 문제와 조건을 좀 더 꼼꼼히 읽고, 주의를 기울이면 되는 부분들이라 다음주 미션에는 조금 더 주의하도록 해야겠다.
