Level 1-1 : Racing-car

와일더의 학습 프로필 🃏

[TDD] 테스트 주도 개발 - 4

내용

이번 미션에서는 TDD 를 필수로 해야하는 미션은 아니었다. 하지만 나의 페어 ‘인비’와 TDD로 구현을 해보기로 했고, 미숙하지만 TDD 를 하여 코드를 구현해보았다.

모든 필요한 기능을 테스트로 먼저 만들어두고 구현에 들어갔는데 이 부분에서 구현되지 않은 기능에 대한 테스트들이 모두 빨간줄이 생기면서 구현한 기능에 대해서 테스트를 실행할 수 없었다.

하는 수 없이 테스트만 구현되어 컴파일 에러를 일으키는 테스트코드를 모두 주석처리하고 진행했는데, 나중에 알고보니 테스트를 구현해둘때는 최소한 컴파일 에러가 발생하지 않게끔 해두는 것이었다. 혹은 기능단위로 구현하는 방법이 있다.

TDD 를 처음 해보다 보니 자꾸 구현할 코드를 생각하고 그 코드에 맞게끔 테스트 코드를 짜려고 하는 모습을 발견했다. 뒤늦게 이 점을 깨닫고 무조건 원하는 기능에 대해서 테스트를 구현하고 테스트에 맞게끔 기능을 구현하기 위해 노력했다.

완벽한 TDD 를 하지는 못했지만 기본적으로 테스트 코드를 구현하는 방법에 대해서 학습을 할 수 있었다.

[OOP] 원시값 포장, 일급 컬렉션 - 4

내용

‘인비’와의 페어코딩에서는 생각도 하지 않은 부분 이었다. 그러나 1단계 미션 구현을 완료하고 난 후 페어와 헤어지고 나서 그 주의 금요일에 ‘제이슨’이 원시 값 포장과 일급컬렉션에 대한 수업을 진행했다.

해당 수업을 통해 불변 객체를 만들어 원시 값을 포장하는 이유에 대해서 알게 되었다. 원시 값을 포장 하는 방법은 원시 값을 필드에 만들고, Equals and HashCode 로 객체의 값이 같다면 같은 객체로 취급하도록 설정한다. 원시 값을 포장하면 생기는 장점은 책임 분리에 따른 테스트 용이성 증가, 심리적 안정감을 받을 수 있다. (유효성 검사를 포장한 원시 값 안에서만 하면 되기 때문이다. 즉, 유효성 검사가 보장됨)

당장 미션에 적용 시켜보고 싶었기 때문에 진행 중이던 레이싱카 미션을 리팩토링 하였다. 이전에는 (일급 컬렉션 == 레포지토리)라고 생각했는데, 그것은 잘못된 생각이었다. 해당 부분을 헷갈려 했는데, 리뷰어 ‘재연링’이 차이점을 알려주었다.

일급 컬렉션은 상태와 기능을 가진 컬렉션을 포장한 것이고 레포지토리는 영속화하기 위한 것이다.

해당 차이점을 이해하고 나니 일급 컬렉션을 쓰는데에 훨씬 수월해졌다.

[OOP] 불변 - 5

자바에서는 final 이 재할당만 금지한다. 즉 객체 내부의 메소드로 내부의 값이 변할 수 있다. 그렇기 때문에 객체를 포장하여 불변 객체로 만든다. 값이 변하지 않는다는 것은 상당한 안정감을 얻을 수 있다.

그중 하나는 할당된 값을 보장해준다는 점이 있다. 이외에도 많은 이유가 있지만 그 이유는 뒤에 다룬다고 한다.

당신이 메모리에 대해 걱정하는 것보다 불변 객체로 얻는 이점이 훨씬 많다고 한다. - 오라클 문서 -

메모리 관리는 GC 를 믿자!

해당 미션에서 position 은 움직여야 한다. 하지만 final 을 걸어버리면 위치가 바뀔 수 없게 된다. position.move() 를 할 때, 새로운 객체를 생성하여 재할당하면 final 을 지키면서 값을 변경할 수 있다.

[OOP] 생성자 - 2

내용

생성자에 대해서도 새롭게 알게된 점이 많았다. 생성자에서 다시 생성자를 호출해서 생성하는 법에서 그동안 생각도 못했던 부분이라 놀랬다.

생성 로직이 복잡하다면 생성자를 통해서 생성하는 것이 아니고 팩토리를 통해서 생성해야한다. 생성자는 최소한의 유효성 검사와 값을 할당하는 기능만 가지고 있어야 한다. 생성자는 생성자의 역할을 충실히 할 때 생성자가 많아도 괜찮다.

생성자가 많아지면 활용할 수 있는 방법이 많아진다.(클라이언트의 사용성 증가) 단, 메소드가 많아지는 것은 단일 책임 원칙을 위반하는 것이다.

좋은 객체는 5 ~ 10개의 생성자와 5개 이하의 public 메소드를 가지고 있다. - 엘레강트 오브젝트 -

그리고 ‘제이슨’이 정적 팩토리 메소드에 대한 설명도 했는데 아직 해당 부분은 코드에 적용 시켜 보지 못했다.

[JDK] 스트림 API - 1

내용

미리미리 스트림 API 사용법을 일상화 해두었기 때문에 이번 미션에서 큰 문제 없이 코드를 보기좋게 하는데 사용할 수 있었다.

[설계] MVC 패턴 - 5

내용

MVC 를 자주 봐 왔지만 정확하게 뜻하는 의미를 이해하지 못했다. 이번에도 이해하는데 시간이 좀 걸렸다. 하지만 이제는 제대로 이해한 것 같다.

우선 비즈니스 로직에 대해 알아야 했다. 비즈니스 로직은 데이터를 생성·표시·저장·변경하는 부분을 일컫는다. 즉, 기능 관련된 것을 뜻하고 이는 모델(도메인)이라고 볼 수 있다.

뷰는 입력과 출력을 관리하는 것이다.

컨트롤러는 모델과 뷰에서 구현한 기능을 서로 연결 해주기만 하는 역할을 한다.

여기서 중요한 것은 도메인과 뷰는 서로 의존(호출)해서는 안된다. 의존은 컨트롤러에서만 한다고 이해하고 기능 구현을 하니 훨씬 이해가 쉽게 되었다.

[OOP] 전략 패턴 - 3

이것은 가장 마지막 리팩토링을 할 때 사용했다.

레이싱카가 움직이는 goForward() 기능을 랜덤한 상태에서 움직이게 해야했는데, 이 때 전략패턴이란 것을 사용하게 되었다.

미션에서는 랜덤으로 움직이지만 나중에 이것이 또 다른 특정 조건에서 움직이게 될 경우를 생각해야한다. 이럴 경우에 사용할 수 있는 것이 움직임의 여부를 가지고 있는 인터페이스를 만들어서 goForward() 를 호출할 때, 파라미터로 넘겨주는 방법이었다.

사실 처음 사용 해보기 때문에 정확하게 이해 했다고 보기는 힘들다. 우선은 대략적인 이해를 하고 추후에 반복적으로 해당 기능을 써보면서 몸소 익혀야겠다.

끝으로…

처음 작성 해보는 학습 프로필이고 따로 작성을 계획하고 만든 글이 아니다. 미션이 다 끝나고 나서 작성을 하다보니 잘못된 내용이 많을 수도 있다.

나 이외의 누군가가 이 글을 읽는다면 위와 같은 사항은 이해해주면 좋겠다.