Table of contents

오늘 한일

로또 4단계 merge

3단계 마지막 피드백을 적용하고 4단계는 피드백 없이 merge 됐다.

  • 자주 사용하는 값 객체는 상수로 선언하기도 함

    • BigDecimal.ZERO, BigDecimal.ONE 등 참고

  • 멤버변수가 final로 선언되어 있다고 하더라도, 캡슐화를 지키는 것을 권장

  • 값객체의 내부값을 꺼내서 비교하는것보다는 값객체끼리 서로 비교하는게 더 좋을 듯

    • myMoney == Money.ZERO 혹은 Money.ZERO.equlas(myMoney)

  • numbersGenerator을 정적 메서드로 생성하지 않는게 더 좋은점은 느슨한 결합을 위해서

    • numbersGenerator를 정적 메서드로 생성하면 랜덤으로 숫자를 생성하는 부분과 강결합이 생김
    • OCP, DIP 를 고려
    • 가장 좋은 방법은 기본 생성자에서 스스로 BoundedUniqueRandomNumbersGenerator를 생성하는게 아닌, Appplication.java에서 LotteryMachine를 생성할 때 DI

3단계 피드백을 반영하여 로또기계를 구매기계와 추첨기계로 나눴다. 값 객체를 사용하는 부분에서는 객체에서 값을 꺼내오지 않고 메시지를 전달하는 방식으로 변경했다.

사다리 2단계 구현 & merge

본격적인 사다리 게임을 구현하는 2단계를 완료하여 피드백을 요청하여 merge 됐다.

사다리는 처음부터 설계를 하지 않고, TDD로 개발하면서 리팩토링으로 클래스를 추출하는 방식으로 진행했다. 그러다보니 리팩토링이 진행될수록 패키지에 클래스가 많아져서 패키지를 이동하는 경우가 많았고, 구현에만 6시간은 걸린 것 같다. TDD로 개발한다고 할지라도, 미리 대략적인 도메인을 설계한 뒤에 진행하는 편이 나은 것 같다. 그래도 나름 리팩토링의 재미를 느낄 수 있었다.

사다리 3단계 리팩토링 & 피드백 요청

원래 qna 2단계를 진행하려 했는데, 사다리 2단계를 빨리 merge 해주셔서 사다리 3단계를 바로 진행했다. 3단계는 요구사항이 추가되지는 않았지만 리팩토링을 통해 더 나은 구조를 만드는 단계였다.

2단계에서 구현한 클래스 구조가 3단계 힌트에 주어진 구조와 비슷해서 3단계는 금방 끝났다. 2단계에서는 사다리에서 (false, true)를 오른쪽 방향, (true, false)를 왼쪽 방향, (false, false)를 이동하지 않는 point로 가정하여 구현했지만, 2단계에서 원시값을 포장하여 Point라는 클래스를 추가했다. 3단계를 완료함으로써 모든 클래스의 멤버변수가 2개 이하면서, 콜렉션은 일급콜렉션을 사용하는 구조를 갖게 되었다.

백준 DP: 이친수, 스티커

이친수 문제는 메모장에 적다보니 피보나치 수열 문제라는 것을 금방 찾을 수 있었지만, 스티커는 점화식을 구하지 못했다. 결국 스티커 문제는 다른 사람 코드를 참조해서 풀었는데, 그림을 그려봤다면 점화식을 찾을 수 있었을 것 같다.

오늘 느낀점

사다리 3단계를 완료하고 몇몇 분들의 코드와 비교해봤는데, 전혀 다른 구조로 작성된 코드가 많았다. 훨씬 깔끔한 구조도 많았는데, 역시 나는 아직 멀었다 ㅠㅠ

dp 문제에서 점화식이 구해지지 않으면 n - 1의 결과 값들과 연산을 수행하는 방식으로 구현했는데, 대부분 틀린 답이 됐다. dp 문제는 무조건 그림을 그려서 점화식을 찾아봐야겠다.

내일 할일

  • 사다리 4단계 구현
  • qna 2단계 구현
  • 백준 dp 3문제
  • 소프트웨어 악취를 제거하는 리팩토링: 불필요한 추상화, 미활용 추상화 공부
  • 플러터 1/4/7/14 앱 기능 설계