Jump to content
  • Advertisement
Sign in to follow this  

Abstract classes and inheritance help

This topic is 3215 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I am trying to make a base item/object class that every object will build off of. For example
//This is the item class
class Item {

        virtual void setID(int id) = 0;
	virtual void setName(string name);
	virtual void setWeight(int weight);
	virtual void setType(ITEM_TYPE type);
	virtual void setConsumable(bool consume);
	virtual void setUsable(bool use);

	virtual int getID() = 0;
	virtual string getName();
	virtual int getWeight();
	virtual ITEM_TYPE getType();
	virtual bool isConsumable();
	virtual bool isUsable();


    int itemID;
    int itemWeight;
    bool usable;
    bool consumable;
    std::string itemName;
    ITEM_TYPE itemType;

//here is a resource class for example a resource is an item

class Resource: public Item
	Resource(int id, string name, ITEM_TYPE itype, int weight)


	vector<string> loadRes(string file); //load resource file to vector

	void setID(int id);

	int getID();
	//RES_TYPE getResType();

	//int hardness;
	//int quality;
	//int durability;
	//RES_TYPE rType;

I know i am missing some forward declarations for setName, Weight etc etc. My question is, I am not really understanding what the real difference is if i make those virtual or not, an Item will never be declared i.e Item * i = Item(); you will always create a resource/weapon etc etc. So item will never be used by itself, it is just a base to build the other items off of. Am I on the right track? Should the item class be purely abstract? I am not sure what the drawbacks are to that, based on the current code whether its abstract or not is just the difference between actually declaring setID() in each class or setName(), as opposed to if it were not virtual or pure virtual i could just do something like Resource *r = Resource(blah, blah) r->setID(1); and it would work using the declaration in item.cpp So is the extra writing of setID in every single individual item class going to help down the road? I am not sure. Sorry for long post i'm not really sure how to explain what I am getting at.

Share this post

Link to post
Share on other sites
I think you are misunderstanding OO. Your base Item class is... kindof useless from the client code's perspective.

Instead of trying to write the Item class, write some classes that use items. Ideally, they will try to be fairly agnostic of the exact items being used. You might find that this is impossible, you might find that you need to have a special interface for handling weapons, armour, consumables etc. Use what you have learned to define the interface that the item should have (or possibly consider having a few base classes, i.e. weapons, clothing...)

Finally, in C++ it is a good idea to give any base class a virtual destructor.

Share this post

Link to post
Share on other sites
Well I was thinking of the item class as like an object class, probably didnt name it very well as item.. But basically resources are an object, weapons are an object, armor is an object, etc.

I am not sure if that makes it any clearer or if your post still stands, I just figured grouping all the objects to interface off an existing class, I don't know though so :P I could be way off as you stated


EDIT: Also basically every single item/object will have an id, a name, a weight etc. So your saying just do away with an inherited class? I just figured because every single object regardless of weapon/resource etc.. will all have one of those functions.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!