2023.03.21 일일 회고

취약한 기반 클래스

Piece를 상속하는 구현체 중에서 Pawn만 canMove() 메서드가 다르게 동작한다.

그래서 Pawn 이외에는 공통적으로 작동하기 때문에 부모인 Piece 에서 canMove()를 작성하고 Pawn에서만 따로 Overrid 해주었다.

추상 메서드가 아닌 메서드를 override하는 것은 코드의 예측가능성이나 일관성의 측면에서 위험합니다.
당장은 문제가 없어보이지만, 코드 중복을 이런 식으로 처리하다보면 취약한 기반 클래스 문제를 맞이하게 될 거에요.

부모 클래스의 변경이 자식 클래스에 영향을 미치는 클래스를 취약한 기반 클래스라고 한다.

이를 해결하기 위해 Pawn과 같은 계층에 Normal 추상 클래스를 정의하여 이 계층에서 canMove()를 구현하도록 했다.

객체 분리

리팩토링 과정에서 문제를 해결하는 방법에만 집중했다. 해결은 하긴 했으나 다음과 같은 피드백을 받았다.

다만, 이전과 같이 여러 클래스에 걸쳐 중복 코드가 등장했을 때 적당히 책임을 위임할 객체를 만들 수 없을까?란 생각을 꼭 해보시면 좋을 것 같아요. 앞선 세 개의 미션에서 배우고 익힌 내용들을 활용하면 훨씬 더 깔끔한 코드를 짤 수 있습니다 😄

피드백을 받고 내 자신이 부끄러웠다. 이전 미션에서 배웠던 내용을 잘 적용하고 있지 못한 것 같다. 항상 중복이 발생했을 때 객체의 분리를 생각하자!

자연스러운 협력

내가 구현한 체스 게임에서 객체간의 협력은 다음과 같다.

1. Board -> Squares -> Square -> Piece 순으로 메시지를 보내서 source 위치에서 target 위치까지의 경로를 물어본다.
2. Board 는 해당 경로에 기물이 있는지 없는지를 계산한다.
3. 경로와 기물의 존재 유무를 다시 Piece에 전달하여 이 정보를 바탕으로 Piece가 움직일 수 있는지를 다시 Board에게 전달한다.
4. 움직일 수 있으면 Squares -> Square 가 가지고 있는 Piece를 교체한다.

상태를 먼저 나누고, 상태를 가지고 있는 객체에게 책임을 부여하려다 보니 이러한 구조가 되었다.

물론, 객체지향적으로는 잘 구현했다는 피드백을 받았으나, 다른 사람이 이 코드를 봤을때 흐름 자체에 의문이 생길 수 있다.

따라서, 협력을 먼저 생각하고, 책임을 부여하고, 상태를 가지도록 한다면 보다 자연스러운 협력 관계를 표현할 수 있지 않을까?