3주차 C++ 과제 4
3주차 C++ 과제 4
연금술 공방 관리 시스템 구현 과제
- 프로그래밍 기본 요소(변수, 배열, 함수, 조건문, 반복문)
- 다형성 / 상속
- STL
- SOLID 원칙
등을 고려한
게임 속의 연금술 공방 관리 프로그램을 만들어 보는 것이다
구현 기능
- 레시피 추가, 레시피 출력, 재고 현황 출력
- 물약 소모, 물약의 빈병 반환 후 자동 제작, 재료를 통한 레시피 검색, 종료
클래스 설명
클래스 구조
AlchemyWorkshop
- PotionDictionary -> PotionRecipe 를 관리
- PotionRepository -> PotionStock 을 관리
AlchemyWorkshop
- 사용자에게 포션관련 작업을 제공하는 클래스
- PotionDictionary 와 PotionRepository 클래스를 가진다
- 각각의 클래스에게 포션의 세부 작업을 분배
PotionDictionary
- PotionRecipe를 관리하는 클래스
- 레시피 추가, 전체 레시피 출력, 검색을 담당
- map<string, PotionRecipe> 를 통해 포션 이름과 레시피를 관리
PotionRecipe
- 포션의 이름과 재료 목록(set)을 가지는 클래스
- 기본적으론 Vector를 사용하였으나 재료를 통한 검색 기능을 위하여
Set으로 변경
- 자신의 레시피 출력, 특정 재료를 포함하는지의 여부에 대한 기능 포함
PotionRepository
- 포션의 재고 관리용 클래스
- 포션 제작, 제공, 빈 포션병 회수, 모든 재고량 출력 기능을 포함
- map<string, PotionStack>을 통해 포션 이름과 스택을 관리
PotionStack
- 포션의 재고(보유량,빈병 개수)를 가지는 클래스
- 생산,제공, 현재 포션 재고량 출력, 빈병 회수의 기능 포함
- PotionRepository로부터 분리(재고 관련 옵션 변경 시)
PotionRepository 역시 수정되어야 하기에 기능을 분리
(SRP)
트러블 슈팅 - 객체 지향적 클래스 설계
처음에는
AlchemyWorkshop 와 PotionRecipe 클래스만이 존재하였다
‘포션 레시피’를 관리하는 ‘포션 샵’ 클래스
기본 요구사항에 ‘포션 검색’이 들어왔기에
이건 사실 ‘포션 샵’이 제공할만한 기능은 아니지 않나? 싶었기에
‘포션 사전’이라는 클래스를 추가하여
‘레시피’에 대한 관리를 위임하고
‘포션 샵’은 ‘포션 사전’을 가진 상황에서
‘사용자’(Main)가 원하는 기능만을
public 함수로 노출시키는 쪽으로 가닥을 잡았다
‘포션 재고’를 관리하는 ‘포션 저장소’ 클래스
이후 ‘재고’에 관한 내용이 도전 과제로 존재하였다
도전 과제에선 ‘포션 레시피’가 Stack이라는 임의의 인터페이스를
사용하는 방식을 예시로 들었다
다만 나는 ‘레시피’가 ‘재고’와 개념상 합쳐지는게 다소 마음에 들지 않아
‘포션 저장소’라는 클래스를 만들어
‘포션 샵’의 기능으로 사용하는 쪽을 택하였다
(지금 생각해보니 그냥 ‘Potion’이라는 상위 클래스를
만들고 ‘재고’라는 Interface를 쓰는것이 더 깔끔했을지도 모른다)
‘포션 재고’ 그 자체를 나타내는 클래스 추가
다만, ‘평가 기준’을 보니
‘차후 확정성을 고려하였는가’를 보아하니
다소 고민이 되었다
‘재고’가 단순히 ‘남은 개수’와 ‘빈 포션 병’을
담당하는 것이 아니라, ‘가격’ 등의 요소를 포함하게 된다면
‘포션 저장소’의 함수들이 전체적으로 수정될 수 있었다
그렇기에 ‘포션 재고’를 나타내는 별도의 클래스를 만들었다
결론적으로 SOLID 원칙을 잘 지켰는가?
사실 이 부분이 제일 까다롭다
‘단일 책임 원칙’ 이나 ‘개방 폐쇄 원칙’은 비교적
잘 지키려 하였으나
별도로 ‘상속’을 구현하여 사용하지 않았기에
‘리스코프 치환’ 이나 ‘인터페이스 분리’, ‘개방 폐쇄 원칙’을
고려하진 못하였다
다만 개인적인 생각은
‘포션’ 관련 클래스만 다룰 것인데
‘샵’ - ‘포션 샵’ 상속 이라던가
‘ISearchable’ - ‘PotionDictionary’ 방식이
다소 직관적이지는 않아보였다
만약 차후, 비슷한 계열의
‘WeaponDictionary’ 라던가 하는 클래스가 생긴다면
부모 클래스나 인터페이스를 고려할 수 있겠지만
(+ 물론 대규모 프로젝트라던가 RPG 게임의 설계단계라면
처음부터 고려하는 것이 맞을 것이다)
당장 과제를 수행하는데
다소 추상적인 개념을 만들어 놓는 것이 다소 힘겨웠다
상속과 인터페이스를 고려한다면 더 좋은 설계를 할 수 있었겠지만
당장은 단일 책임 원칙과 개방 폐쇄 원칙을 지키려는 감각을 키운것에 만족한다
댓글남기기