[회고] 우아한 테크코스 5기 프리코스 4주차 회고

객체지향 설계를 할 때 저는 객체를 객체스럽게 사용하는 방법을 잘 알지 못했습니다. 응집도가 높되 결합도가 낮은 설계를 하려면 어떤 기준을 적용해야 하는지 기준이 명확하지 않았습니다. 저는 "객체지향의 사실과 오해"라는 책을 읽고 구글링을 통해 비슷한 문제를 겪은 사람들의 조언을 참고했습니다. 그 결과 저는 "같이 변경되는 코드는 같이, 같이 변경되지 않는 코드는 따로", "객체에 메시지를 보내기"라는 기준을 정했습니다.

 

"같이 변경되는 코드는 같이, 같이 변경되지 않는 코드는 따로."

처음에 BridgeController에서 BridgeGame을 선언할 때 BridgeMap(랜덤으로 만들어진 다리)와 PlayerMap(사용자가 이동하면서 그려지는 다리)를 파라미터값으로 전달해줬습니다. 하지만 PlayerMap은 BridgeGame 안에서만 값이 변경되기 때문에 외부에서 값을 넣을 필요가 없었습니다. 그래서 BridgeGame을 선언할 때 BridgeMap(랜덤으로 만들어진 다리)만 파라미터값으로 전달하게 하였습니다.

public class BridgeGame {
   private final BridgeMap bridgeMap;
   private PlayerMap playerMap;

   private BridgeGame(BridgeMap bridgeMap) {
     this.bridgeMap = bridgeMap;
     this.playerMap = new PlayerMap();
     }
     // 생략 ...
}

 

"객체에 메시지를 보내자"

객체에 메시지를 던지는 것도 어디서 어느 객체가 해야 하는지, 어디서 판단해야 응집도는 높을지 고민을 많이 했습니다. 예를 들면, 랜덤으로 생성된 map과 유저가 이동하면서 생성한 map의 사이즈를 비교한다고 했을 때 아래 코드와 같이 표현할 수 있었습니다.

//BridgeMap 객체에게 PlayerMap를 보내 사이즈 같은지 물어보기
public boolean isSameSize(PlayerMap playerMap) {
    return bridgeMap.size() == playerMap.getSize();
}

 

“리팩토링 == 더 넓은 시야”

지난 주차 과제에서는 리팩토링에 테스트 코드의 중요성을 깨달았습니다. 이번 주차에서는 리팩토링 과정에서 전체적인 코드의 구조가 정리되는 것을 느꼈습니다. 예를 들어, 위에서 예시를 든 "같이 변경되는 코드는 같이, 같이 변경되지 않는 코드는 따로” 부분에서 BridgeGame 객채에 PlayerMap을 외부에서 전달하지 않아도 되는 것을 리팩토링하면서 깨달을 수 있었습니다.

리팩토링하면서 전체적인 코드의 흐름도 같이 볼 수 있었습니다. 예를 들어, 이번에 BridgeGameController에서 처음에 이동 여부 상태를 표시하는 코드를 따로 만들어서 사용했습니다. 하지만, Bridge.move()를 입력했을 때 바로 이동 여부 상태를 알 수 있게 변경하였습니다. 덕분에 코드는 더 간결해졌고, 직관적으로 바뀌었습니다.

 

코드가 궁금하시다면 여기로