Question regarding "Godclass" (C++)

[flo8464]

Hi.

I dunno if this is the correct place for that question, but as here are a lot of competent coders I just try.

Well, I am not completly sure how to structure my bot (it is not a WoW one).

I got a huge, huge class built above the heart piece, a hook on EndScene.
That class is more a container for other things like object handler, communication, AI ... everything that my bot does.

Basically, I inject my DLL, create an instance of my bot on the heap, that godclass' constructor does all the initialization for the whole bot and the remote thread leaves after the bot got "allocated". If the bot gets the command to quit, the object deletes itself and the destructor does the clean up.

I often hear that using "godclasses" like this is bad style.
What do you think about it and just in case someone would like to share his knowledge, how do you handle it? Thanks.

Greetings,
Flo

[pendra]

The point of object-oriented programming is to decompose the application into easier to understand components with well defined interfaces. This makes the code easier to read and understand, easier to refactor if/when necessary, easier to debug, etc. If you just pile everything into one big class, you aren't really utilizing the features of the language to their fullest. It will be hard to tell what the consequences of local code changes are, since it's hard to know which bits of your god class are relevant to it's various functions.

In general terms, if you're interested in learning when you should use classes and how they are typically put together, do some research into "design patterns". A good book on the subject is [ame=http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612]Amazon.com: Design Patterns: Elements of Reusable Object-Oriented Software (0785342633610): Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides: Books[/ame].

For a WoW bot in particular, it's hard to say what you should decompose into discrete objects without seeing your code, but here's some things to think about.

Keep all your code that directly interfaces with the WoW client segregated in it's own class or something, so that the majority of your bot remains wow client version agnostic. Having to do all that pointer goo is a necessary evil when you're reverse engineering, but try to keep it as contained as possible.

You could keep your AI code separate from the core bot logic like the object manager, etc, making a clean distinction between the code related to your bots intent and the code related to carrying out that intent. That will allow you to debug the two independently, which can be very helpful.

You could keep your communication stuff in it's own class so that the rest of your bot doesn't have to know or care about IPC. It can just send/receive messages, and the stuff dealing with how they get where they're going is contained.

The basic theme is to reduce the amount of information that each portion of you bot needs to know about the rest of the bot to a minimum, so that coding can be as local as possible, and it's easier to keep the consequences of your actions at the forefront in your mind while coding. Most mistakes happen when you fail to think of something.

My two cents, anyhow.

[flo8464]

Thanks for the answer, especially for the booklink, Design Patterns are definitly relevant to my interests.

Well, maybe I expressed myself wrong, but I wrote different classes for different tasks, the "godclass" just stores references to everything to be able to clean it up. Additionally, for example, if my AI needs data from the object manager, it fetches a pointer to the main class (which is a singleton btw), retrieves a pointer to the object manager from the main class and starts working with that data.

[pendra]

I think when people say "god object" they mean an object that actually has all the code in it. Having a top level class that holds pointers to all the sub-components is just fine, as long as it's quite small compared to the components it manages. Somebody has to instantiate all the components and hook them up to each other, after all. The only thing I would worry about is making sure your sub-components don't have circular dependencies unless it absolutely cannot be avoided, because that can get ugly in a hurry.

[amadmonk]

Make sure you understand anti-patterns, too. Design patterns are king, but you have to equally know when NOT to apply them.