TDD, 클린 코드 with Java (미션 3, 4 - FP, OOP, 리팩터링)

세 번째 미션인 사다리 타기는 자바 8의 스트림, 람다를 사용해 함수형 프로그래밍을 활용하는 것이 주된 목표입니다.

네 번째 미션인 수강신청은 레거시 코드를 리팩터링 하는 것이 주된 목표입니다.

 

 

세 번째 미션인 사다리 타기에서 경험해야 할 목표는 다음과 같습니다.

• 자바 8의 스트림, 람다를 활용한 함수형 프로그래밍
• In -> Out, Out -> In 방식으로 도메인 객체를 설계하는 경험
• 책임 주도 설계 기반 인터페이스를 활용한 프로그래밍

 

네 번째 미션인 수강신청에서 경험해야 할 목표는 다음과 같습니다.

• 레거시 코드를 리팩터링 할 때 테스트 코드를 통해 보호하는 경험
• Q&A 서비스의 질문 삭제하기 기능의 레거시 코드를 리팩터링하는 경험
• DB 테이블보다 도메인 모델을 TDD 기반으로 먼저 개발해 보는 경험
• 레거시 코드를 점진적으로 리팩터링 해보는 경험

 

 

미션 3 - 사다리타기(FP, OOP)

• 1단계 - 스트림, 람다, Optional
• 2단계 - 사다리(생성)
• 3단계 - 사다리(게임 실행)

 

(IntelliJ) 파일 끝에 개행을 자동으로 추가하자.

 

책임과 역할의 적절한 분리

split하는 책임은 InputView가 가지는 것이 맞을 것 같아요!
Participants는 List<String>만 받아서 생성하도록 변경하면 좋을 것 같네요

기존 코드는 Participants 객체의 생성자에서 이름을 입력받고 split 하는 로직까지 포함되어 있었는데 이 책임은 InputView 객체가 가지도록 변경했습니다.

 

코드가 변경되는 케이스를 고려했을 때 split이 아니거나 split의 구분자(NAME_DELIMITER)가 변경된다면 기존 코드는 도메인(Participants) 객체의 변경이 필요하지만, 생각해보면 도메인 객체가 비즈니스 로직이 아닌 외부 요인으로 인해 변경하는 케이스가 존재하기 때문에 입력받은 이름을 split 하는 역할은 View 클래스에게 위임합니다.

 

 

현재 코드는 도메인이 view를 의존하고 있는 것 같습니다.
만약 출력 요구사항이 변경되어 다른 ----- 가 아닌 ~~~~~ 로 변경된다고 했을 때 도메인이 수정되는 문제가 발생합니다.
Line은 Line 생성에만 집중하고 Line을 그리는 것은 view 패키지 내 클래스가 처리하면 될 것 같아요.

위 Participants와 동일하게 도메인(Line)이 View를 의존하고 있는 코드입니다.

 

 

테스트 네이밍의 가독성을 고려하기

As-Is)

 

To-Be)

 

 

미션 4 - 수강신청(레거시 코드 리팩터링)

• 1단계 - 레거시 코드 리팩터링
• 2단계 - 수강신청(도메인 모델)

 

가독성이 좋은 테스트 코드

해당 테스트 코드를 이해하기 위해서 여러 함수들을 알아봐야 하는 구조로 되어있어요.
가동성이 좋은 구조로 테스트 코드 작성해보는것도 좋은 경험일것 같아요.

 

 

연관된 상태를 묶어서 관리하는 객체(VO) 도출하기

연관된 상태를 묶어서 관리하는 객체를 도출해낼수 없을까요?
그렇게 된다면, 인스턴스 변수 갯수도 줄어들것 같구요.