[우테코] 프리코스 4주차 회고록

awarduuu·2023년 3월 2일
0

다리 건너기

어느덧 프리코스 마지막 주차까지 왔습니다! 3주차에서 객체지향에 대한 맛을 봤다면, 이번 주차는 직접 요리를 한다는 표현이 맞을 것 같습니다. 최대한 더 잘게 쪼개기 위한 함수 10줄 제한, 클래스는 클래스답게 구현, 리팩터링 등 요구사항들이 더 추가되었는데요. 이번 주차는 최대한 피드백을 반영하기 위해 노력하다보니, 배운점과 아쉬운 점이 많았습니다.


로직 구성

main

/Domain
	/Bridge (생성된 다리와 움직임 비교 담당)
    /Move (이동 결과 생성을 담당)
    /GameCommand (게임 재시작 및 종료를 담당)
    /BridgeMaker (랜덤 다리 생성을 담당)
    /BridgeResult (이동과 이동결과 저장을 담당)
    /BridgeGame (다리 건너기 게임 진행을 담당)
/View
	/InputView (사용자의 입력을 담당)
    /OutputView (결과 값 출력을 담당)
/Controller
	/InputController (입력 로직을 담당)
    /BridgeGameController (다리 건너기 게임 전반 로직을 담당)
/Utils
	/Validator
    	/BridgeValidator (다리 길이 입력 예외처리 담당)
        /MoveValidator (이동 입력 예외처리 담당)
        /CameCommandValidator (재시작 여부 입력 예외처리 담당)
    /Constant (공통 사용 상수 담당)
    /Util (공통 사용 함수 담당)
    
 test
 
 /Domain
 	/BridgeTest
    /MoveTest
    /BridgeResultTest
 /Utils.Validator
 	/BridgeValidatorTest
    /moveValidatorTest
    /GameCommandValidatorTest

개발 순서는 3주차와 똑같이 Domain -> View -> Controller -> Validator -> Test로 진행하였고, 기능 개발이 완료 될때마다 체크리스트를 업데이트 했습니다.

  1. 클래스 분리와 객체 보호 그 사이 어딘가

클래스에서 가장 고려해야할 점은 '상태'와 '행동'이라고 생각합니다. 최대한 상태와 행동 모두 클래스에 존재하게 하며, 이들의 논리가 적절하면 건강한 클래스이기 때문입니다. 하지만 객체지향에 익숙하지 않아서 그런지, 클래스를 더 잘게 쪼갤 수록 게임 전반을 관리하는 BridgeGameController에서 처리할 행동이 너무 많아졌습니다. 그래서 리팩터링을 통해 BridgeGame에서 List와 Bridge 클래스를 인스턴스로 사용할 수 있게끔 만들어 다리 건너기 게임 준비 단계와, 게임 중 단계를 구분할 수 있었습니다. List와 Bridge를 전달만 해주고, 이를 활용하는건 BridgeGame에게 책임을 주니 로직이 간결해졌습니다. 하지만 문제가 생겼습니다. OutputView에 사용할 List를 가져올 방법이 getter 외에는 없었습니다. 최대한 객체의 인스턴스를 보호하고자 하였지만, 간결한 로직이 우선이라 생각하여 어쩔 수 없이 getter를 사용하였습니다. 3주차에서도 겪었던 어려움이었기에 더욱 해결해보고 싶었지만, 이후 마땅한 방법이 떠오르지 않았습니다. '매개변수로 설정하여 책임을 전가하라'를 어떤 변수상황에서도 적용할수 있게 연습해야겠다는 깨달음을 얻은 좋은 경험이었습니다.

  1. 상위 클래스 테스트의 어려움

Validator를 따로 두었기 때문에 사용자의 입력에 관한 테스트는 크게 어려움이 없었지만, domain에서의 테스트는 조금 어려움이 있었습니다. 먼저, 타 클래스를 매개변수로 받아 이들에게 행동을 하게 하는 void의 경우 테스트를 진행하지 못하였습니다. 자신의 인스턴스를 업데이트하는 void 또한 값을 꺼낼 방법이 없으니 테스트 할 수 없었습니다. 이를 해결하기 위해 '업데이트 후 값을 다시 내보내는 함수'로 최대한 작성하여 하위 클래스들의 테스트들은 성공 할 수 있었습니다. 하지만 상위클래스 메소드들은 이 방법 역시 통하지 않았습니다. 이를 해결할 수 있는 방법은 단 하나, 객체지향언어 이해도를 최대치로 끌어올리는 것이라 생각합니다.

  1. 전달 - 행동 - 전달

아직 객체 지향적인 코딩은 어렵지만, 객체 지향적인 논리는 어느정도 체화가 된것 같습니다. 객체는 전달받은 값을 저장받으며 이를 가지고 다른곳에 전달할 값을 만드는 행동합니다. 그리고 이 행동은 한 가지 일만 하게끔 설정합니다. 이를 지키려고 노력하다보니, 추가되는 요구사항들이 저절로 지켜졌습니다. 그리고 목적이 같은 행동들을 하는 클래스를 묶어 관리하는 습관도 생기게 되었습니다. 지난 4주동안의 프리코스를 통해 저를 포함한 모두가 '객체 지향 중독자'가 되어가는 모습은 정말 잊지 못할 경험인 것 같습니다.

profile
선한 영향력을 만드는 개발자

0개의 댓글