Conversation
sangjun121
left a comment
sangjun121
left a comment
There was a problem hiding this comment.
안녕하세요 민욱님! 이번 주차 미션하시느라 고생하셨습니다! 😊
남겨주신 PR 내용과 코드 바탕으로 전체적인 피드백 남겨드렸습니다! 남겨드린 질문에 대해 학습해보시고 궁금한 점이나 이해하기 어려운 점 코멘트 남겨주시면 다시 꼼꼼히 남겨드릴게요! 부담갖지 마시고 편하게 질문해주셔도 괜찮아요!
| String carNameInput = InputView.inputCarName(); | ||
| int trialNumber = InputView.inputTrialNumberCount(); | ||
| // [2] 데이터 변환: 문자열 -> 자동차 객체 리스트 | ||
| var cars = CarManager.createCars(carNameInput); //cars 라는 자동차 객체 배열 생성 |
There was a problem hiding this comment.
var 대신 구체적인 타입을 명시해 주는 것도 고려해 보면 좋을 것 같습니다. var는 코드 길이를 줄여준다는 장점이 있지만, 변수의 실제 타입을 확인하려면 메서드 반환 타입을 따라가야 하기 때문에 코드 가독성이 조금 떨어질 수 있다고 생각해요!
특히 서비스 애플리케이션 코드에서는 변수의 타입을 명시적으로 드러내는 것이 코드를 읽는 사람에게 더 직관적이라고 생각합니다.
논외로, 라이브러리나 프레임워크에서는 구현 수정이나 유연성에 대비해서 var타입을 오히려 권장하는 경우도 있는데, 이 부분도 함께 학습해서 언제 var를 사용하면 좋을지 고민해보시면 좋을 것 같아요!
| import java.util.ArrayList; | ||
| import java.util.List; | ||
|
|
||
| public class CarManager { |
There was a problem hiding this comment.
Car 클래스를 제외한 모든 클래스가 static 정적 클래스로 선언이 되어 있어서 아래 질문 드립니다!
-
Car 객체를 제외한 모든 클래스를 정적 클래스로 구현하신 이유가 있으신가요?
-
어떤 경우에 정적 클래스를 사용하면 좋을까요?
-
클래스와 객체의 차이에 대해 학습하고, 정적 변수의 초기화 시점에 대해 학습해보시면 좋을 것 같아요!
혹시나 위 질문에 대해 충분히 공부해보시고 애매한 부분 남겨주시면 성실히 답변 해드릴게용! 너무 부담 갖지말고 클래스와 객체의 차이에 대해 꼭 짚고 넘어가면 좋을 것 같아요!
| package racing.view; | ||
| import java.util.Scanner; | ||
|
|
||
| public class InputView { |
There was a problem hiding this comment.
view 계층에 Input 과 Output이 분리가 될 필요 없이 한 파일에서만 사용하는 것이 더 좋은 선택인지
저는 View 계층에서 InputView와 OutputView를 분리하는 것이 더 자연스럽다고 생각합니다.
입력과 출력은 서로 다른 역할을 가지기 때문에, 클래스를 분리해 두면 각각의 View 객체가 하나의 책임만 가지도록 유지할 수 있다고 생각해요. 이렇게 책임을 나누어 두면 이후 기능이 확장되거나 출력 방식이 변경될 때 수정 범위를 줄이는 데에도 도움이 될 수 있습니다.
다만 말씀해주신 것처럼 레이싱카와 같이 규모가 작은 콘솔 애플리케이션에서는, 오히려 책임이 과하게 나눠지지 않을까 하는 생각이 들어서 여쭤보신 것 같아요! 둘다 나름대로의 근거가 있으니 충분히 둘다 좋다고 생각합니다.
| if (name.contains(" ")) { | ||
| throw new IllegalArgumentException("[ERROR] 자동차 이름에 공백을 포함할 수 없습니다."); |
There was a problem hiding this comment.
Readme에 남겨주신 내용처럼, 검증의 종류를 형식 검증과 나머지 비즈니스 규칙에 따른 검증을 나눠서 고민하신 것 같아요!
예를 들어, 쉼표가 연속해서 두번 나오는 경우(jun,,min)에 대한 검증과 이름길이에 대한 검증(예: sangjun - 5자 초과)는 검증의 종류가 다를텐데 모두 도메인에서 책임을 갖는 것이 맞을까요? 지금도 충분히 좋지만 검증을 어디서 하는지도 고민해보셨으면 좋겠습니다.
| public String getPositionVisualized() { | ||
| return "-".repeat(position); |
There was a problem hiding this comment.
만약 자동차 이동의 출력의 형태가 -가 아닌 *로 수정된다면 어떤 파일을 수정해줘야 할까요? 이 함수에 의해, OutputView가 아닌 Car 도메인 내부를 수정해야 할 것 같습니다.
| } | ||
| return cars; | ||
| } | ||
| public static void Duplicate(List<Car> cars){ |
There was a problem hiding this comment.
자바 메소드명 네이밍 규칙, 카멜케이스로 통일해주시면 좋을 것 같아요!
| public static void start(List<Car> cars, int trialCount) { | ||
| for (int i = 0; i < trialCount; i++) { | ||
| runRound(cars); | ||
| System.out.println(); // |
There was a problem hiding this comment.
이 부분도 출력에 대한 메소드니까 OutputView에서 끌어오는 것이 어떨까요?
| } catch (NumberFormatException e) { | ||
| throw new IllegalArgumentException("[ERROR] 시도 횟수는 숫자여야 합니다."); | ||
| } |
There was a problem hiding this comment.
형식 검증을 View 단에서 실행하고, 유효하지 않은 값이 Domain에 전파되기 이전에 반환시킨 점 좋은 것 같아요! 다만 위에서 "시도 횟수가 1 미만" 점은 형식 검증보다 도메인 규칙 검증에 가깝지 않을까요? 이렇게 해석된다면 view에 해당 검증을 위치시키는 것은 어색하다고 생각합니다.
2 participants
안녕하세요 리뷰어님 !!
시간을 내주셔서 리뷰를 해주시는데 제가 가독성 좋은 글과 코드를 작성하지 못하여 죄송하게 생각하고 있습니다.
남은 미션은 제가 더 가독성이 좋고 핵심적인 의미만 전달 할 수 있게 코드,pr,리드미 를 작성하도록 하겠습니다.
정말 감사하며, 좋은 하루 되시길 바라요 :)
🚀 구현 기능 및 작업 내용
MVC 패턴 기반 설계: Domain, View, Controller의 역할을 명확히 분리하여 유지보수성과 확장성을 고려했습니다.
Car 객체의 자율성 부여: 단순한 데이터 뭉치가 아닌, 스스로 자신의 상태(이름, 위치)를 관리하고 입력값에 대한 유효성을 검증하는 '살아 숨쉬는 객체'로 구현했습니다.
CarManager를 통한 집합 관리: 개별 자동차 객체들을 효율적으로 제어하고 관리하기 위한 매니저 클래스를 도입했습니다.
Java 메서드 활용: 자바에서 제공하는 표준 메서드를 적극적으로 활용하여 가독성 높고 효율적인 코드를 작성했습니다.
🏗️ 설계 및 아키텍처
본 미션에서는 기능 분리와 객체지향 원칙 준수를 최우선으로 했습니다.
Domain (Car,CarManager,Race)
(1) Car
자동차의 이름과 이동 거리를 저장하며, 생성 시 이름 형식 및 공백 여부 등 **자기 자신에 대한 유효성 검증(validate)**을 직접 수행합니다.
(2) CarManager
생성된 자동차 객체들의 리스트를 관리하며, 중복 확인 등 전체적인 비즈니스 로직을 담당합니다.
(3) Race
자동차 명단(CarManager)과 시도횟수를 파라미터로 입력 받게 되면, 자동차 경주를 실행하고 각 자동차 객체는 자신이 얼마만큼 이동했는지 car position에 기록이 추가됩니다.
우승자를 결정하는 메서드가 controller를 통해 호출이 된다면, 우승자 명단을 작성한뒤 controller에게 반환해주며, ouputview를 통해 출력할 수 있게 됩니다.
Race 파일에는 경기에 관련된 메서들만 모아서 관리하였습니다.
View (InputView, OutputView)
사용자의 입력을 받고, 처리 결과를 시각적으로 출력하는 역할에만 집중합니다.
Controller : Domain과 View의 중계자 역할
CarManager를 통해 Race 와 OutputView 사이의 흐름을 제어하며 전체적인 경주 프로세스를 조율합니다.
🎯 핵심 집중 사항
객체지향: 객체가 스스로 움직이게 하는 구조를 지향했습니다.
철저한 예외 처리: 사용자의 잘못된 입력(특수문자, 중복 이름, 잘못된 시도 횟수 등)에 대해 IllegalArgumentException을 발생시켜 프로그램의 안정성을 확보했습니다.
가독성 있는 코드: 변수명, 메서드명을 명확히 하고 기능 단위를 작게 쪼개어 누구나 읽기 쉬운 코드를 작성하려 노력했습니다.
✅ 체크리스트
자바 컨벤션을 준수하였는가?
MVC 패턴에 따라 역할이 적절히 분리되었는가?
테스트 케이스를 통해 모든 예외 상황을 검증했는가?
불필요한 공백이나 미사용 코드가 제거되었는가?
💡 추가 제안 및 문의
해당 PR의 MVC 패턴의 기능 분리의 오류나 view 계층에 Input 과 Output이 분리가 될 필요 없이 한 파일에서만 사용하는 것이 더 좋은 선택인지 등에 관하려 기타 피드백을 해주신다면, 꼭 새겨듣겠습니다. 감사합니다.