3주 차 미션은 설계 실수도 있었고, 코드에 욕심이 생겨 스스로 많은 생각이 들었던 한 주였다.
2주 차의 problem
1. 값을 하드코딩 하지 않는다. (공통 피드백)
2주차 미션을 풀 때는 '1', ', '등의 문자를 상수로 정의하지 않고 하드코딩 하였습니다.
3주 차 미션에서는 이러한 문제점을 해결하기 위해 각 클래스에 상수로 정의하였습니다.
private static final String ONE_STEP = "-";
private static final String RESULT_MESSAGE = "최종 우승자";
private static final String COLON = " : ";
public static final String CAR_NAME_MESSAGE = "경주할 자동차 이름을 입력하세요.(이름은 쉼표(,) 기준으로 구분)";
public static final String TRY_MESSAGE = "시도할 회수는 몇회인가요?";
public static final String ROUND_RESULT_MESSAGE = "실행 결과";
2. 변수 이름에 자료형은 사용하지 않는다. (공통 피드백)
private List<Car> carList;2주 차 미션을 보면 carList 외에도 List형태이면 전부 xxxList로 한 모습을 볼 수 있습니다.
변수명에 자료형을 사용하지 않기 위해 어떤 변수명을 사용할지 정말 고민을 많이 했습니다.
그 결과 List가 아닌 단어의 복수형인 s를 붙이기로 했습니다.
private final List<Integer> numbers;
private final List<Lotto> lottos;List 외에도 int, double 등 자료형을 사용하지 않도록 주의하면서 코딩을 했습니다..
3. 기능 목록을 업데이트한다.
프리코스에서 강조하는 살아있는 기능 목록을 만들기 위해 기능 목록을 자주 업데이트 했습니다.
기존에는 커밋을 한 뒤, 업데이트를 하는 방식이 아닌 한 번에 기능 목록을 전부 작성 한 뒤, 목록에 맞게 구현했습니다.
그러다 보니 목록에 맞게 코딩을 하지 않을 때도 있었으며, 기능 목록을 살아있게 유지하지 못했습니다.
3주 차 미션에서는 기능 명세서를 작성한 뒤, 작성한 내용을 구현하고 기능 명세서에서 다음 기능을 작성한 뒤 구현하는 방식으로 진행하였습니다.
Keep
1. 기능 목록을 살아있게 유지한다.
기능 목록을 살아있게 유지하니까 기능을 처음부터 확정 짓지 않고 유동적으로 기능 목록을 작성할 수 있어서 좋았습니다. 4주 차 미션을 수행할 때도 미션 단위로 기능 명세서를 작성 한 뒤, 구현하는 방식을 적용하려고 합니다.
Problem
1. 입력받은 문자열의 유효성 검증(Validation)을 Controller가 아닌 View에서 처리한다.
MVC 패턴에서 View는 입력 및 출력만 담당하는 역할을 합니다.
1~3주 차에서는 View가 유효성 검증까지 하면 두 가지 역할을 해 SRP를 위반한다고 생각해, Controller에서 진행했습니다. 하지만 이는 여러 가지 단점을 가지고 있습니다.
- Controller에 불필요한 로직이 생성됩니다.
- 불필요한 로직이 생기므로 처리 시간이 길어져 사용자의 경험이 낮아지게 됩니다.
이러한 단점 때문에 Validation은 Controller가 아닌 View에서 처리해야 합니다.
2. main 메서드가 두 가지 일을 하는 것을 지양한다.
public static void main(String[] args) {
// TODO: 프로그램 구현
InputView inputView = new InputView();
OutputView outputView = new OutputView();
LottoService lottoService = new LottoService();
LottoController lottoController = new LottoController(inputView, outputView, lottoService);
lottoController.run();
}3주 차 미션의 main 메서드입니다.
main 메서드에서 객체를 초기화 한 뒤, 프로그램을 시작하는 역할을 하고 있습니다.
이는 단일 책임 원칙을 위반하므로 객체를 초기화하는 클래스를 만들어야 합니다.
3. 객체 지향 세계에 현실 세계의 개념을 가져오지 않는다.
제목을 보고 이게 무슨 소리야?라고 하실 수 있습니다.
당첨 번호를 구매자가 비교를 한다.
현실 세계에서는 당연한 이치입니다. 매주 토요일 오후 8시 34분에 하는 로또 방송을 보며 로또 번호를 비교를 하는데 객체 지향 세계에서는 구매자가 당첨 번호를 가지고 있지 않습니다. 이러한 문제점은 Player(구매자) 메서드를 생성한 뒤, 지각하였습니다. 객체지향 세계에서는 객체들이 메시지를 통해 정보를 주고받습니다. 현실 세계처럼 메시지를 주고받지 않더라도 모든 일을 처리할 수 있는 '사람'과 같은 존재가 없습니다. 그러므로 메시지와 상태를 통해 정보를 주고받도록 설계해야 합니다.
Try
1. while문을 통해 반복을 관리하지 말고 함수형 인터페이스를 사용해 보자.
while문을 통해 반복을 관리하면 큰 문제가 생기지 않지만 재사용을 하지 못해 다른 부분에서 똑같은 기능의 반복을 하려고 하면 똑같은 코드가 생기는 큰 단점이 생깁니다. 이를 해결하기 위해 재사용성이 높은 함수형 인터페이스를 한번 사용해보려고 합니다.
2. "이유가 있는 코딩을 하자"
나의 카테고리 중에는 "왜?"라는 카테고리가 있습니다.
그만큼 왜 이렇게 구현을 했는지? 에 대한 이유가 중요합니다. 4주 차 때는 "이유가 있는 코딩"을 할 수 있도록 모든 내용을 이해하면서 코딩해보려고 합니다.
