[2단계 - 자동차 경주 리팩토링] 우르(김현우) 미션 제출합니다. #644
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
안녕하세요 또링 !!
1단계 미션 리뷰에서 너무 중요한 것들을 배운 것 같아 기분이 좋습니다. 그리고 답이 없는 것을 생각하려니 재밌기도 하고, 한편으로는 머리가 터질 것 같기도 해요,,하하 그래서 이번 리뷰도 잘 부탁드려요 !
이번 2단계 미션을 진행하면서 최대한 객체지향적으로 코드를 작성해보려고 노력했어요. 그리고 1단계 피드백에 관해서도 많은 생각을 해서 그에 대한 제 의견을 작성해보겠습니다 !!
제가 생각한 부분에 대해서 또링에 대한 생각을 듣고 싶어요.
자동차 이름과 위치에 대한 검증은 어떤 객체의 책임일까?
이전에 말씀드렸던 "생성자가 객체를 생성하는 아주 막중하면서 무거운 책임을 가지고 있다고 생각해서 생성하는 로직만을 가지고 있는게 좋지 않을까"에 대해서 고민해봤습니다. 생성자에 책임을 많이 부과하는 것보다 객체를 생성할 때의 검증 로직이 더욱 중요한 것 같아요,, 그리고 만약에 도메인 객체 생성 부분에서 예외가 발생한다면 도메인 클래스에서 발생한 것이기 때문에 예외 진입점(?)을 빨리 찾을 수 있어서 유지보수성도 좋을 것 같구요. 특히 또링이 말씀하신 "도메인에 도메인 규칙이 적용되어 있지 않네요"가 적절해보여요. Input 의 규칙이 아닌 도메인 규칙이기 때문에 도메인에 존재하는 것이 좋아보입니다.
여기서 다시 드는 의문점은 현업에서는 객체지향으로 작성하도록 노력해도 실제로 많은 인스턴스 변수들이 존재할텐데(제 예상입니다,, 만약 아니라면 해당 클래스에 인스턴스 변수가 10개일 때 가정하겠습니다.) 이러한 경우에도 각 값들을 포장하여 많은 클래스들을 만들고, 규칙을 정의할까요,,?
이 의문점이 든 이유는 저는 spring에서 validation 라이브러리를 통해서 대부분 값을 받아올 때(컨트롤러 단에서) 처리를 해왔고, 도메인에서 해보질 않았던지라 궁금해서 그렇습니다,,!!
CarEngine의 역할은 무엇일까?
저는 이제 Cars가 아닌 다른 외부에서 자동차의 움직일 수 있는 조건을 판단하고 움직이게 하는 객체가 또 필요하다고 생각이 들었어요.
왜냐하면 "Car는 도메인, 즉 행동하는 주체",
Cars는 "Car 도메인에 대한 행위를 모아놓은 곳",
CarsEngine는 "Car 움직임을 제어하는 곳"이라고 생각했기 때문이에요.
즉, CarEngine을 이제 외부 값(random 값)을 통해 Car를 제어하는 곳이라 생각했어요.
Car는 이제 random number를 모르고 "그냥 움직여라"라는 메시지를 통해 움직이고, 이를 구현하기 위해서 move 메서드에 distance++ 만 실행합니다.
굳이 Car에서 random number에 대해서 알 필요가 없다고 생각이 들기도 하고, Car는 move라는 메시지를 통해서만 움직인다고 생각이 들어서 CarEngine에서 일정 값이 넘으면 자동차에게 움직여라는 메시지를 보내는 것이지요.
그래서 CarEngine에서 외부에서 값을 받아와서 Car.move를 통해 Car 도메인에 그냥 "움직여라" 라고 메시지를 전달하여, 객체가 스스로 행동하게끔 Car에 move 메서드를 만들어놓았어요.
그런데 글을 작성하면서 제가 알고 있는 객체지향이란 객체가 주체적으로 판단하고 행동하는 것으로 알고 있는데,, 제가 작성한 논리가 조금 객체지향적이지 않다는 생각이 들기도 하네요,,
첫번째가 저의 의견이고 두번째가 또링의 의견인데,, 뭔가 두번째가 더 객체지향 같아 보이면서도,, random number에 대해서 알아야할까 라는 저의 생각이에요!! 그래서 또링의 생각이 궁금합니다.
우리가 제어할 수 없는 부분에 대한 테스트는 어떻게 하면 좋을까?
같은 방식으로 로직이 처리되는 상황을 만들기 위해서 랜덤 숫자를 반환할 때와 같은 시그니처의 메서드를 생성하고, 해당 메서드를 호출하여 테스트 할 수 있습니다. 대표적으로 다형성을 사용하여 숫자 생성 인터페이스를 생성하여 해당 인터페이스를 구현하는 "고정적인 경계값"들을 반환하여 테스트 한 뒤, 합리적 의심(?)을 통해 랜덤 숫자 테스트가 이뤄질 수 있다고 생각합니다.
고정적인 경계값이란 3, 4를 반환하여 3일 때는 움직이지 않게, 4일 때는 움직이는지를 의미합니다.