TIL - 25일차

🟩 오늘의 목표

• 팀 프로젝트 협업 과정에서 수정된 Item 클래스의 변경 사항을 이전 버전과 비교 분석한다.
• 팀원의 피드백을 반영하여 매개변수 전달 방식 및 반환형 변경의 기술적 이유를 이해한다.
• 클래스의 책임을 분리하고 리팩토링하여 객체 지향 설계의 완성도를 높인다.
• 팀 협업을 통해 더 유연하고 확장성 있는 코드를 작성하는 법을 익힌다.

 

🟧 1. 팀 프로젝트 협업 및 피드백 반영

---

팀원들과의 적극적인 상의와 피드백을 통해 기존에 작성했던 Item 클래스를 대폭 수정했다. 개인적으로 설계했을 때는 고려하지 못했던 인벤토리 시스템과의 연동, 객체 유효성 검사 등의 실무적인 관점을 팀원들의 도움으로 반영했다. 혼자 코드를 짤 때보다 팀 전체의 규격에 맞추어 인터페이스를 개선하는 과정이 코드의 질을 높이는 데 큰 도움이 되었다.

 

---

🟧 2. 매개변수 전달 방식의 변화: 참조자에서 포인터로

🟦 포인터(*) 매개변수 도입

기존 Use(Player& player) 방식에서 Use(Player* player) 방식으로 변경했다. 참조자를 사용할 때는 객체가 반드시 존재해야 했으나, 팀원들의 피드백에 따라 포인터를 사용함으로써 호출 측에서 객체의 유무(nullptr)를 체크할 수 있는 유연성을 확보했다. 이에 따라 멤버 접근 시 도트 연산자(.)가 아닌 화살표 연산자(->)를 사용하여 player->GetHP()와 같이 호출하도록 코드를 수정했다.

 

🟧 3. 함수의 반환형 변경: void에서 bool로

---

🟦 사용 성공 여부 피드백

아이템 사용 함수의 반환형을 void에서 bool로 변경했다. 이는 아이템을 단순히 실행하는 것에 그치지 않고, 아이템이 실제로 효과를 발휘했는지(예: 체력이 가득 차서 포션 사용 실패)를 호출자에게 알려주기 위함이다.

🟦 조건부 아이템 소모 로직

HpPotion::Use 함수에서 체력이 이미 가득 찬 경우 false를 반환하고, 정상적으로 회복된 경우 true를 반환하도록 설계했다. 팀원들과의 회의를 통해, 이 반환값이 true일 때만 인벤토리에서 아이템 개수를 감소시키는 로직을 구현하기로 결정했다.

 

🟧 4. 클래스 책임 분리 및 리팩토링 결과

---

🟦 변수 관리의 일원화

팀원들의 제안으로 이전 코드에 포함되었던 count_ 변수를 Item 클래스 내부에서 제거했다. 개수 관리는 개별 아이템 객체가 아닌 인벤토리 시스템에서 담당하도록 역할을 분리했다. 클래스의 책임이 명확해지면서 Item 클래스는 순수하게 아이템의 고유 기능에만 집중할 수 있게 되었다.

🟦 생성자 구조의 단순화

초기화 리스트를 통해 부모 생성자에 이름을 전달하던 방식에서 기본 생성자 호출 방식으로 변경했다. 멤버 변수의 초기값을 클래스 정의부에서 직접 지정(ItemName_ = "")함으로써 코드의 간결함을 유지했다. 이러한 간소화 작업 역시 팀원들의 코드 리뷰를 통해 가독성을 높이는 방향으로 수정했다.

 

🟧 5. 아이템별 구체적 로직 구현

---

🟦 HpPotion 및 AtkPotion의 Override

Item 클래스를 추상 클래스로 유지하며 Use 함수를 순수 가상 함수로 선언했다. HpPotion에서는 현재 체력이 최대 체력보다 적을 때만 회복이 일어나도록 무결성 검사를 수행했고, AtkPotion은 포인터를 통해 플레이어의 공격력을 즉시 업데이트하도록 구현했다. 모든 자식 클래스가 성공 시 true를 반환하여 팀 프로젝트의 공통 인터페이스 규격을 맞췄다.

 

🟫 오늘 느낀 점

팀원들의 도움과 피드백을 통해 함수의 인터페이스를 포인터로 바꾸고 반환형을 bool로 개선하며 시스템의 확장성을 고려한 설계의 중요성을 깊이 깨달았다.