창고 개발 기록 (NPC)

처음에는 인벤토리의 기능을 모두 공용으로 쓰려했고
기능의 낭비가 많아 창고 부모 클래스와 인벤토리 자식 클래스를
MVC로 나눠서 제작했다.

 

그래서 창고 클래스를 NPC역할을 하는 모든 것들에게 부착하고
공용으로 사용하려 했지만 정말 당연하게도 문제가 발생했다.

NPC는 UI를 사용하지 않는데 창고 클래스의 컨트롤러에서는 UI 정보를 받고있고
모델에서는 Refresh 메서드로 UI를 계속 갱신하고 있다.

 

따라서 오늘 팀원과 회의를 하면서 NPC가 가지는 보관함 기능을 독립적으로 제작 할지
아니면 창고와 인벤토리 클래스를 자식으로 넣고 순수히 아이템의 추가, 삭제의 기능만
가지는 상위 부모 컨트롤러 클래스를 제작할지에 대해 이야기 했다.

 

내 의견은 상속을 하는건 그 자체로 기능의 변경에서 이로움이 있지만
너무 많은 기능들이 포함되어 있다면 그 자체로 오히려 변경에서 번거로움이 있을 수 있고,

팀원의 의견은 여러개의 공통된 기능을 상속을 통해 관리하면 이를 관리하는 다른 클래스들도 편해질 수 
있고 코드의 간편함과 변경성에서 이점을 얻을 수 있다는 것이었다.

 

사실 상속이 객체지향 프로그래밍 관점에서 굉장히 유용한 기능이긴 하지만
상속에 너무 의존하는 것은 좋지 않고 오히려 클래스를 독립적으로 만들어서
관리하는게 모듈화의 측면에서 좋다고 생각했다.

 

이 때문에 많은 고민을 했지만 상위 클래스의 정보에 인벤토리나 창고의 객체 정보를

캐스팅하여 넣어준다면 사실 그거만큼 편한 것도 없긴하고 이거야 말로 상속과 객체지향 프로그래밍의
큰 장점이라고 생각하여 창고와 인벤토리를 관리하는 부모 클래스를 하나 더 만들기로 했다.

그러면 이제 해야할것은 창고 클래스가 부모면서 아이템과 UI의 정보를 가지고 있었으니
창고 클래스와 인벤토리 클래스를 독립적으로 제작하여 부모 클래스의 기능을 상속받도록 하는 것이다.

근데 사실 이러면 또 인벤토리와 창고가 비슷한 기능을 하기 때문에 만들었던 구조를
붕괴 시키는 상황이 되는 것인데.. 사실 창고랑 인벤토리는 기본적인 기능만 보면 비슷해보이지만
정말 다른 기능들이 많이 추가될 수 있는 상황이기 때문에 이 부분을 오히려 독립적인 클래스로
제작하는게 나아 보인다.