Character Controller & abstract character class

[drwbns]

Hi guys, I was working on making a generic character class but I ran into a problem. With my characterController class, should I publicly inherit the Character class or make it a member of characterController?

[Mind Calamity]

I think that's a matter of preference, except if you have the generic character controller as a member, you won't be able to access it's protected members.

I prefer inheritance, as it gives me the ability to override functions, and use 1 method for update (for example) which takes the generic class as a parameter, instead of having multiple for different types of characters.

[drwbns]

Ok, I designed the character class with getters and setters to the member pointers. Is there any disadvantages to doing this?

[Mind Calamity]

I prefer inheritance, as it gives me the ability to override functions, and use 1 method for update (for example) which takes the generic class as a parameter, instead of having multiple for different types of characters.

[drwbns]

Hmmm. I'm still pretty new at class designing. I was thinking to have a class for each character which all inherit a generic controller class. Is this a bad approach, or just different?

[Mind Calamity]

I think that's the "standard" approach. Or at least it is for me. It's the most logical one (again, for me) anyway.

This would be a good use case for the factory pattern.

[drwbns]

Hmm different constructors for the controller class or for the character class or both?

[bstone]

Don't drain your stamina with "class designing". Unless you have years of experience and can see down to the minor detail through a forest of abstractions I recommend you leave the "design" attitude completely. What you should do is start with the simplest thing that works and improve it step by step, refactoring your code and reorganizing your class hierarchies based on the information (i.e. relationships, ownership, API quirks, C++ rules) that you discover while working toward your goal. And don't build your code around "patterns", use them where they can be useful, but don't think "patterns" - think "the simplest thing that works".

The concepts, operations, and relationships mentioned here are the ones that come naturally
from our understanding of the application area or that arise from further work on the class structure.
They represent our fundamental understanding of the application. Often, they are classifications of
the fundamental concepts.
...
Beware of viewgraph engineering!

Listen to the Man!

[drwbns]

Thanks for the info bstone, I'll try that

[syedhs]

It is pretty much the argument Inheritance vs Composition, and if you googled around many people would love to do composition.

Regarding the class design, I agree with the principle do not overdo with class design and if you have not yet coded even 1 line. But you can get ahead of yourself by reading others people code which has matured. Which means, they probably have done try & error & refine stages for at least 2-3 times, so you are going to save yourself time by doing that And you are learning a lot too.

[drwbns]

Thanks for all the replies. I wanted to come up with a simple logical inheritance structure so I can work with multiple characters containing different meshes, animations, and maybe special abilities per character type. I guess the questions comes down to, should class characterType be templated? should composition be used to add a characterController to the characterType class? - considering a characterType isnt a controller, but has a controller. Also, should a controllerClass inherit a generic character class for data members such as runSpeed, weight, name, etc. ?

I'm reading up on component based systems and wondering if that might be an easier route to take for the heirachy I want to have in place. Any thoughts from anyone on experience of using / implementing a component based system and what the pros and cons are?

Edit: If anyone is interested in learning more about component based systems just google search "Evolve your heirarchy"