Okky
fender,jojoldu님의 글을 읽고 느껴지는 부분, 공감되는 부분에 대해서 정리해보기
아래 코드에서 개선할 수 있는 부분은 무엇이 있을지 생각해본다. #
public Card draw(){
int size = cards.size();
int select = (int)(Math.random()*size);
Card selectedCard = cards.get(select);
cards.remove(select);
return selectedCard;
}
위의 코드는 (카드덱)객체에서
- 가지고 있는 카드 리스트 중 랜덤한 카드 한장을 뽑고
- 그 카드는 리스트에서 제거하는 코드이다.
이 코드를 한번 더 개선할 수 있다고 한다면, 무엇을 개선하면 좋을까?
객체를 모델링할 때, 다음과 같은 것들을 고려해본다. #
구체적인 구현 사항은 이후에 생각한다. 일단은 인터페이스 레벨에서 모델링을 해본다.
1번의 모델링이 어느정도 익숙해지면, 그 다음은 (다음단계)일반화/추상화에 대해 고민해본다.
모델링을 연습할 때에는 어떠한 프레임워크를 사용하지 않고 순수 언어(java) 로 작성해본다.
가능하다면 API 는 에러를 발생하지 않도록 작성한다. #
API 는 유효하지 않은 상태가 발생하지 않는 방향으로 설계/작성한다.
나의 경우에 유효하지 않은 요청이나 특정 조건에 맞지 않으면, 무의식적으로/가벼운 마음으로 Exception 을 던졌던 부분들이 있었다.
“API 는 유효하지 않는 상태가 발생하지 않는 방향으로 설계하는 것” 은 이런 상황에서도 좋은 피드백이 되는 것 같다. (이렇게 이해하였다.)
객체, 객체의 행위의 역할/책임에 대해서 더욱 신중히 생각한다. #
" 예를들어 ‘Player.showCards()’ 같은 메서드는 과연 가지고 있는 카드를 콘솔에 뿌리는 것이 플레이어의 역할인가 자문해볼 여지가 있습니다. 만일 이 프로젝트가 카드 게임 제작을 위한 일반적인 API로 사용될 수 있다면 그런 부분은 나중에 웹기반 게임을 구현한다던지 할 때 문제가 될 것입니다. “
” ‘Dealer.receiveCard()‘을 보면 내부적인 규칙에 따라 카드를 받는 것을 거부하더라도 호출자 입장에서는 알 수 있는 방법이 없습니다. 콘솔 메시지를 보이는 건 사용자를 위한 것이지 호출하는 프로그램을 위한 것이 아니기 때문에 이러한 부분은 좀 더 개선이 필요하다고 생각합니다. “
영어는 정확한 문법에 맞게 작성한다. #
메서드명을 작석할 때, 호출하는 쪽에서 내부 사항에 대해 예측할 수 있도록 (혹은 꼭 뜯어보지 않아도 알 수 있도록) 작성한다. #
직관적/가독성이 좋은 네이밍은 중요하다.
메서드가 하나의 역할/행위만 하는 것이 보장될 때, 이는 더욱 잘 지켜질 것이다.