[TDD, 클린 코드 with Java] 3.사다리타기 - FP, OOP

*개요

사다리타기 과제를 구현하면 피드백 받은 내용을 정리합니다.

 

2단계 - 사다리(생성)

매개변수 값 전달 시 변수명에 맞는 값을 전달하

 

 매개변수 전달 시, personCount라는 매개변수명을 가지고 있습니다. 따라서 실제 전달은 personCount를 해야 합니다. 

 

Factory 분리를 고민하라

 

 사다리를 생성하는 LadderFactory는 Ladder에서만 사용합니다. 이전에 로또번호를 생성하는 과제에서는 별도로 Factory를 분리했습니다. 제대로 로또 번호가 생성되었는지 테스트를 하기 위함이 큰데, 이번 리뷰에서는 오히려 만들지 않는 것이 낫다는 피드백을 받았습니다. 따로 정답이 있다고 생각하지 않습니다. 경우에 따라서 분리하거나 그냥 유지 할 수 있습니다. 

 

중복된 유효성 검증을 제거하라

 

 Line 유효성 검증은 이미 Line 생성 시에 완료되었습니다. 따라서 별도의 유효성 검증을 하지 않아도 됩니다. 애초에 생성될 때 생성자에서 처리하도록 하며 테스트를 합니다.

 

 nextBoolean()을 활용하라

 

boolean의 랜덤 값은 nextBoolean()을 활용할 수 있습니다.

 

 

사다리 만들기를 재귀로 구현하라

복잡한 구현 방식

 

 결과 값을 다시 매개변수로 활용하여 여러 번의 Line을 이동하도록 구현합니다. 현재는 list에서 값을 꺼내 일일이 비교하고 있습니다. getter로 비교하는 방식은 자제합니다. 재귀 형식을 사용하면 훨씬 편하게 줄일 수 있습니다. 첫번재와 마지막은 if문에서 검사하더라도 중간 값들은 재귀로 처리 가능하며 가독성이 올라갑니다.

 

 

도메인의 상수를 public으로 정의해 테스트에도 활용하라

 

 도메인에서만 사용되는 상수는 어차피 고정된 값입니다. 처음에는 테스트에서도 별도로 정의해야한다고 생각했으나 도메인에서 변경되면 테스트에서도 마찬가지로 변경되어야 합니다. 따라서 테스트에서도 도메인의 상수를 사용할 수 있도록 public으로 정의합니다.

 

 

객체 생성 시 재귀 처리를 이용하라 

 

 

재귀를 이용한 사다리 만들기

 

 객체 생성 시, 계속 새로운 객체를 만들어 리스트에 추가하는 방법도 있지만, 메서드에서 객체를 리턴하게 하여 만들 수도 있습니다. 

 

 

전략 패턴에 Strategy를 추가하라 

 

전략 패턴 사용을 구체적으로 드러내기위해 Strategy 를 뒤에 붙일 수 있습니다.

 

 

3단계 - 사다리(게임 실행)

 

실행결과가 정상 작동하는 테스트를 만들어라

 

 제대로 테스트를 만들지 못했기 때문에 정상적인 사다리 게임이 예외를 던졌습니다. 혹시 설계가 너무 복잡하여 테스트도 덩달아 어려워지지 않았는지 생각해봐야 합니다. 케이스가 많고 여러 개의 검증이 필요하다면 테스트를 좀 더 꼼꼼하고 세세하게 해도 괜찮습니다.

 

 

 

 

 

객체가 의미있는 상태 값을 가지고 있는지 확인하라

 

 

 Point 클래스는 boolean current처럼 1개의 boolean형만 가지며 getter로서 활용 되었습니다. 기본 자료형을 감싸고 싶었습니다. 하지만 한번 더 감싸서 얻는 이득이 없었습니다. 오히려 탐색 깊이만 늘어났습니다. 따라서 사다리 index를 좀 더 편하게 이해하기 위해 Point 대신에 뼈대의 의미를 가지는 Brace 클래스를 만들었고 left, right 2개의 변수를 가지도록 개선했습니다.

 

 

 

 복잡한 로직을 짠다면 정확성에 주의하라

  

 정상적인 사다리 게임 실행이 실패한 원인입니다. 기존에 짰던 로직 설계가 스스로 완벽하게 숙지되지 않아 잘못된 코딩을 했습니다. 기능을 구현할 때 여러 케이스를 고려해야 하고 매개변수가 헷갈린다면 기능 목록을 정리하여 좀 더 명확하게 코딩 할 필요성을 느꼈습니다.

 

 

구분자를 나누는 역할은 UI에 맡겨라

 

 구분자는 콘솔에 사용자가 입력합니다. 이를 객체에서 처리하도록 했지만, 데이터 가공은 ui에서 하는게 역할에 맞는 것 같습니다.  

 

 

일급 컬렉션에게 책임을 위임하라

 

 Line의 모음인 Lines를 정의했다면, for문을 통해 모든 Line을 호출하여 작업하는 것보다 Lines 일급 컬렉션에 책임을 위임하는 것이 훨씬 객체지향적으로 코딩 할 수 있습니다.

 

 

테스트를 위한 생성자 Fixture를 만들어라

 

각 테스트 클래스마다 반복적으로 등장하는 생성자를 미리 정의하기 위해 test 패키지에 Fixtures를 생성하여 활용합니다.

 

 

복잡한 테스트에 시각 효과를 더하라

  

 때때로 복잡한 테스트가 있다면, 쉽게 이해하기 위해 주석에 시각적 표현을 추가합니다. 

 

 

4단계 - 사다리(리팩터링)

 

2개의 패키지에 의존성을 제거하여 이어주는 팩토리 빈을 활용하라

 

 인터페이스 패키지와 실제 구현체 패키지가 서로 어느 것도 의존성을 가지지 않은 상태로 사용할 수 있도록 팩토리 빈을 활용합니다.  반환형은 확자성을 고려해 인터페이스로 하고 실제 구현한 구현체 클래스로 반환합니다. 한가지 주의 할 것은, 구현체 클래스 매개변수에는 인터페이스로 선언되어 있는데 구체 클래스를 넣어주는 것입니다. 만약에 다른 방식의 구현체가 있다면 인터페이스인 LadderCreateStrategy와 LineCreateStrategy는 유지하고 구현체만 교체하면 됩니다.