레지스탕스 아발론 디스코드 봇 뜯어고치기 (3)

김병윤·2022년 1월 3일
0

개발 일기

목록 보기
3/4

지난 번 글이 11월이었는데... 2022년이 되서야 새 글을 올리네요...ㅠ 저번 글에서는 객체 지향 프로그래밍에 도전해보면서 어떻게 실패하고 있는지를 작성해보았습니다. 그 후로 다른 일들도 처리하면서 동시에 레지스탕스 아발론 봇을 완성했는데요! 그 과정을 한 번 보여드리겠습니다.

지난 글에서 보여드렸던 사진은, 객체 지향 프로그래밍을 잘 몰랐기에 발생한 그림이었습니다. 그 때까지 저는 메소드를 각 단계별로 분류했었는데요, 갈아엎은 이후에는 메소드를 실행하는 주체별로 분류하였습니다. 예전에는 '언제 이 메소드가 실행되는가?'를 생각했다면, 갈아엎은 이후에는 '누가 이 메소드를 실행하는가?'를 생각했단 말이죠. 그렇게 해서 요리조리 그려본 결과...

  1. 게임을 층괄하는 딜러
  2. 라운드를 진행하는 딜러
  3. 게임에 참여하는 플레이어

이 3가지로 객체를 분류하였습니다. 그런데 이렇게 분류만 하면 100% 완성한 게 아닙니다. 각 개체가 어떻게 연결되어있는지 작성해야 완성했다고 볼 수 있죠. 그래서 이번엔 관계를 추가해보았더니...

아? 객체가 3개였는데, 5개로 늘어났네요! 그 이유는, 플레이어가 접근할 수 있는 정보와 접근할 수 없는 정보를 따로 분리하기 위함이었습니다. 플레이어가 Host와 Dealer에게 정보 업데이트를 요청하면, Host와 Dealer가 게임 상황에 따라 처리를 해주는 것이죠!

...하지만 생각해보니, 어차피 변수들을 다 private으로 만들고 접근을 getter와 setter로만 만들면 충분히 구현가능한 것 같더라고요! 그리고, 저 관계도에서 참가자 모집 및 특수 직업을 설정하는 사람은 정해지지 않아서, 관계도를 새로 그려보았습니다. 그 관계도가 바로...

이 관게도입니다! Game의 데이터에 접근하는 역할은 Host가 아니라 메소드로 통합시켜버렸고, 대신 Host에게는 게임 시작 전 옵션을 설정하는 역할을 주었죠.

이렇게 관계까지 추가해서 설계를 해보았는데, 과연 이 설계가 그대로 유지가 될지...!(안 된다는 뜻입니다) 다음 글에서 알아보도록 하겠습니다. 두둥!

profile
가장 위험한 삶은 위험하지 않은 삶이다.

0개의 댓글