'신청' 모델 추가를 위한 객체 설계

 

게시글 상세 내용을 서버에서 가져와 정보를 출력해주는 부분까지 구현했다.

 

사용자 1의 User Id로 로그인했다.

 

일단은 사용자가 신청한 글의 신청취소 버튼을 누를 시 참가 정보가 즉시 삭제되어 반영된다.

 

사용자 1이 자신이 신청한 배구 글의 신청을 취소할 경우 참가자 목록에서 즉시 삭제된다. 반대의 경우도 똑같이 작동한다.

 

다음으로 구현할 사항은 신청 시 즉시 참가자 목록에 반영되지 않고 '신청' 단계를 거치게 하는 것이다. 다음과 같이 동작하게 하는 것을 계획하고 있다.

 

1. 운동에 참가를 희망하는 사용자가 신청 버튼을 누르면 게시글 목록과 게시글 상세 정보에 나타나는 신청 버튼은 신청취소 버튼으로 변경된다. (게시글 상세 내용 보기 기능에도 신청/신청취소/참가취소 버튼을 추가할 계획이다.) '신청' 상태는 운동에 참가가 확정된 것이 아니기 때문에 게시글 상세 내용을 확인해도 참가자 정보에 해당 사용자의 정보는 나타나지 않는다.

2. 모집 게시글을 작성한 사용자는 게시글 상세 내용을 볼 때 신청자 목록을 확인할 수 있다. 각 신청자별로 수락/거절 버튼이 나타난다.

3. 작성자가 특정 사용자의 참가를 수락 버튼을 눌러 수락할 경우 신청자 목록에 있던 해당 사용자 정보가 참가자 목록으로 이동된다. 해당 사용자는 게시글을 확인할 때 참가자 정보에 자신의 정보가 추가되어 있고, 버튼이 신청취소에서 참가취소로 바뀐 것을 확인할 수 있다. 신청자가 참가취소를 누르면 참가자 정보에서 자신의 정보가 사라지고 버튼이 참가취소에서 신청으로 바뀐다.

4. 거절 버튼을 누를 경우 신청자 목록에 있던 사용자 정보는 사라진다. 해당 사용자는 게시글을 확인할 때 버튼이 신청취소에서 신청으로 바뀐 것을 확인할 수 있다.

 

 

이제는 기존의 모델에 '신청'의 역할을 담당하는 새로운 모델이 추가되어야 했다. 사실 아직까지는 기능의 구현이 객체에 어떤 동작이 정의되어 있고 객체들 간의 협력을 통해 기능을 구성한다기보다는, 객체가 가지고 있는 데이터를 가져다 보여주는 수준으로밖에 객체가 이루어져 있지 않았다.

 

동료가 근 며칠 간 객체의 협력 관계를 고민하면서 모델 구조를 다시 설계하는 모습을 보았다. 마침 나도 모델이 하나 둘 덧붙기 시작하려는 만큼 모델들이 어떤 협력관계를 가져야 할지 고민할 시점이 온 것 같았고, 저서 '객체지향의 사실과 오해'에 제시되는 커피 주문 모델을 참고해 현재 내 모델 구조에 협력 관계라는 게 있기는 한지, '신청' 모델은 다른 모델들과 어떤 협력 관계를 갖게 될 것인지 협력 구조도를 그려보면서 생각해보았다.

 

 

현재까지 작성된 게시글 목록 조회, 게시글 상세 내용 조회의 기능이 가져야 할 협력 구조도를 고안한 것이다. 그림을 그릴 때는 그런 생각이 들지 않았었는데, 그림을 다시 확인해보니 '목록이나 정보를 제공하라'는 명령을 전달하는 주체를 지칭하는 게 '앱에 가입된 사용자' 모델인지 (즉 게시물의 정보를 받아서 다른 객체에게 메세지를 전달하는 게 '사용자 모델'이 맞는 것인지), 아니면 앱을 사용하는 물리적인 사람인지 헷갈리는 느낌이 있다.

 

 

다음으로는 이제 구현해야 할 신청 및 수락/거절 기능이 가져야 할 협력 구조도를 고안해보았다. 일단 사용자가 게시글 하나가 들고 있는 하나의 '경기'에 참가 신청을 하는 것이므로 '경기' 모델과 이어져야 한다고 생각했다. 그 과정에서 신청이나 수락/거절의 동작을 맡는 어떤 객체가 있어야 할 것 같다고 생각해 모델이 추가될 수 있을지 고민해봤는데 맞는 것인지 애매한 부분이 있었다.

 

노아 트레이너님께 도움을 요청해 '신청' 모델이 객체로써 어떤 역할을 맡아야 하는지 여쭤보았다.

 

노아 트레이너님은 실세계의 '신청서' 종이를 통해 신청이 이루어지는지를 예시를 말씀해주셨다. 예를 들어 동아리에 참가 신청서를 냈다고 생각해보면, 신청서에는 동아리 정보가 있고, 신청자는 신청서에 개인 정보를 적는다. 동아리 회장이 신청서를 아직 안 봤으면 신청 상태이고, 신청을 승낙하거나 거절해 신청서에 적힌 신청 상태를 바꾸는 것으로 신청자의 동아리 참가 상태 여부를 판별할 수 있다.

 

들은 내용을 바탕으로 신청 모델이 일단 어떤 구조를 갖춰야 할지 적어보았다.

 

 

 

신청 모델을 추가하고 기능을 구현하면서 구현하는 플로우에 문제가 느껴지는지 신경쓸 필요가 있을 것 같다. 구현 도중 뭔가 이상하다 싶다면 절대 질문을 늦추지 말도록 하자.