2016-12-20 1 views
-1

저는 현재 작은 모험을하고 있으며 아이템과 npc 인스턴스를위한 최상의 클래스 디자인이 무엇인지 알고 싶습니다.모험 게임을위한 클래스 디자인

상속 (ItemInstance -> EquipmentInstance)을 사용하는 매우 기본적인 클래스 디자인으로 시작했지만 이후의 디자인 선택에 더 유연 해지고 싶기 때문에 제대로 작동하지 않습니다. lootable NPC (예 : 작은 동물).

public class Instance { 

    public int instanceId; 

    public ItemInstance itemInstance; 
    public NPCInstance npcInstance; 
} 

itemInstance 수량, 무기 또는 장비에 대한 물론 필드를 잡을 수이 방법 :

그래서 나는 항목 인스턴스, NPC가 인스턴스 또는 둘 모두를 저장할 수있는 하나 개의 기본 클래스를 만들기 위해 아이디어를 내놓았다 npcInstance는 현재의 건강, 마나 및 그 모든 것들을 보유합니다.

그러나 이것이 좋은 해결책인지 또는 단점을 초래할 수 있는지 확실하지 않습니다. 물론 나는 대안들에 대해서도 열려 있습니다.

감사합니다.

+4

은 나에게 이상한 잡다한 해결책처럼 보입니다. 여기서 '이게 뭐지?'라고 물어볼 것입니다. 모든 곳에. 과거에 일부 엔진으로 작업 해 왔기 때문에 나는 당신의 첫 번째 개념을 선호합니다. 아이템은 아이템이고, NPC는 NPC입니다. 예를 들어 작은 동물을 약탈 할 수없는 동물을 원하면, 그 동물은 비어있는 전리품 표를 가지고 있습니다. 때로는 요구 사항을 넘어 설 수있는 충동에 저항해야합니다. _ 유연성이 얼마나 필요한가요? 유연성 (복잡성)에는 항상 관련 비용이 따릅니다. –

+0

몇 가지 예를 살펴 보는 것으로 시작할 수 있습니다. RPG Maker는 Ruby 형식의 모든 (상위 레벨) 소스 코드와 함께 제공되는 (매우) 간단한 엔진입니다. 엔진을 구입하지 않고도 스크립트를 찾을 수 있습니다. –

+0

null 필드를 확인하면됩니다. 글쎄, 정말 융통성이 필요합니다. 예를 들어 NPC (예 : 너구리)를 모자와 같은 미친 물건으로 착용 할 수 있어야합니다. :) – Zerebokep

답변

0

Minecraft와 같은 엔티티 기본 클래스는 꽤 ​​괜찮은 것처럼 보입니다. 그런 다음 속성이있는 기본 항목 클래스 Equipable

+0

[여기] (http://3.bp.blogspot.com/-02Pfz0VLLac/VJXz3a9dDDI/AAAAAAAAASg/-EAj79DsUwA/s1600/MinecraftEntityHierarchy.png)와 같은 의미입니까? 이것은 원래의 게시물에 표시된 것과 동일한 접근 방식 인 것 같습니다. 다른 이름으로 보입니다. – Zerebokep

0

클래스 디자인에서 미래를 미리 예상하는 것이 좋습니다. 그러나 애자일 개발에 대해 읽어 보는 것이 좋습니다. 특히, 다음 요구 사항에 대해서만 코드를 작성하고 모든 요구 사항에 대해 리팩터링하십시오. 개발 초기에 최적의 클래스 디자인이 어떻게 보이는지 미리 말할 수는 거의 없습니다.

간단하게 유지하는 것은 수업이 실제로 구현하려고하는 모든 것을 반영하도록 노력하는 것을 의미합니다. 당신의 경우 엔 아이템이 NPC의 소유라고 말하고 싶습니다. 왜냐하면 아이템은 주변에있는 아이템을 운반하기 때문입니다 (또는 작은 동물의 경우에). 시스템의 모든 클래스가 동작을 공유한다는 정당성이 있다고 생각되면 NPC와 항목 모두 인스턴스를 상속 할 수 있습니다. int 속성을 공유하기 위해 인스턴스를 상속하는 것은 과도한 것처럼 보입니다.

좋은 디자인은 SOLID 원칙을 따르십시오.

1

이 질문은 다소 논쟁의 여지가 있지만 엔티티의 상속은 대개 디자인 냄새라고 지적하고 싶습니다.

상속은 근본적으로 유사한 동작을 가진 클래스 간의 관계를 구축하는 것에 관한 것입니다.; 여기서 개체개체의 차이점에 대해 생각해 볼 가치가 있습니다.

  • 기업은 일반적으로 응용 프로그램의 기능 요구에 다시 관련 무언가의 상태 (사용자에 대한 정보를 저장, 예를 들어 "사용자"개체)의 표현이다.
    혼합 상태와 동작은 종종 SRP (Single Responsibility Principle)를 위반하는 비대 풍적이며 유연하지 않은 클래스로 이어지고 적절하게 관리하기 위해 더 복잡한 "if/else"코드가 필요할 수 있기 때문에 엔티티는 많은 동작을하지 않습니다.

  • 개체은 일반적으로 동작을 캡슐화하는 클래스입니다. 엔티티 또는 다른 객체와 상호 작용할 수도 있고 그렇지 않을 수도 있습니다. 객체는 내부 상태를 갖기도하지만, 사용자가 생각할 수있는 것이 아닌 동작과 관련된 상태가됩니다 (예 : 실행 취소/다시 실행을위한 동작 목록, isInitialised 플래그 또는 관리되지 않는 리소스의 핸들).

개체와 엔티티를 구분하는 것이 좋습니다. 이런 식으로 훨씬 적은 수의 엔티티가 필요하게됩니다. 예를 들어, Sword, Gun, Axe 등과 같이 여러 클래스를 만드는 대신 이라는 단일 엔티티로 끝날 수도 있습니다. "Sword", "Gun", "Axe"은 데이터에 표시됩니다. (엔티티 모델링은 객체 지향 모델링 매우 다른 사고 방식이다 엔티티 모델링, 대신 관계형 데이터의 관점에서 생각하는 데 도움이 될 수 있음)

은 일반적으로 상속 비슷한 행동을 가진 클래스를 만드는 방법에 대한 것입니다; 종종 잘 디자인 된 행동 클래스는 그 목적에 따라 이름이 붙여집니다. 예를 들어, Gun은 엔티티처럼 들리지만, GunDamageCalculator은 유용한 것을 할 수있는 무언가와 훨씬 비슷하게 들리며 AxeDamageCalculator 또는 CandlestickDamageCalculator

이 요약 - 유산은 인 대한 비유 IS-A 관계동작 적용되지 속성. 대부분의 소프트웨어의 현실은 Animal 또는 Car으로 표현하면 Vehicle이라는 용어로 설명하는 것이 좋지 않을 수 있습니다. 종종 "기본 클래스"라는 엔티티가 상당히 쓸모 없게되고 실제로 도움이되지 않습니다. 프로그램을 작성하십시오.