Quote:Original post by PlayfulPuppy

Quote:Original post by OrangyTang
Classes should be small, simple and have a well defined name and purpose. 'Manager' violates all of these.

Although if you do that too much you'll just have a goddamned encyclopedia of classes you have to hunt through to get the required functionality.

An 'encyclopedia' as you put it is a good thing. You get smaller, loosely bound classes which increases flexibility and makes code reuse much better. 'Hunting though' isn't an option because you have a series of interfaces (inherant in the small-class approach) each of which provide greater and greater levels of abstraction, and you just pick the level you need at any given time.

Quote:A manager, to me, is any single object that preforms operations on multiple objects of a given type. It keeps a list of all relevant objects (All textures loaded, all entities in the map, etc) and provides an interface for operations that involve all of those objects (Garbage collection, sorting, finding, deleting, etc).

What's so wrong with that?

Because you've now got a big, clunky class which is tightly bound with every piece of functionality you have. If you even need a specific subset you're stuffed, flexibility is greatly reduced and code reuse is practically nil.

I personally see these as bad things.

Quote:Original post by OrangyTang
Nope. How does it manage them?

Aha, that is how you name classes. Thanks, I will now rename my class to ThisClassIsUsingGenericListForStoringAndThenEachTime-
SomeoneCallsUpdateForEachItemInThisListWhichBtwIsOfTypeProjectileUpdateOnTheseObjectsAreCalled.

Not.

If you could find one class inside the .NET Framework that you by the name can tell how it does things, well I would be surprised.

Quote:Original post by Kazgoroth
Actually, ProjectilesManager does sound weird. All you english speaking folk; just stop and say it. ProjectileManager is much nicer.

Yay! Thanks!

Quote:Original post by stylin
Enselic, my apologies if I misinterpretted the course of the thread.

NP. After all I am a Swede. [wink]

Quote:Original post by Enselic
I will now rename my class ...

The meat of the matter is that having a Manager class is too broad. You shouldn't include implementation details in a class name, no, but it should - in the case of [an] object managing-class[es] - describe in what way it[/they] manage.<br><br>A catch-all class such as this could do well to be broken up into smaller, purpose-specific classes, whose names describe exactly what they do with less outside context required; your definition of manager may differ from mine, but I'm sure we can all agree &#111;n what ProjectileCreator, ProjectileFactory, ProjectileConsolidator or ProjectileDatabase accomplish. Classes such as these make good candidates for superclassing as well, as opposed to ProjectileManager, which you can basically do nothing with as far as reusability is concerned.

Ok I can agree with that. Although in my case the manager we are talking about is < 100 lines of code, including comments, so it is a very basic manager. But yes, for a big manager, one should divide it into smaller subclasses.

Quote:Original post by OrangyTang

Quote:Original post by Enselic
but I think you can tell easily what a class named ProjectileManager does, especially in the conext of game programming.

Nope. How does it manage them? Does it act as a pool and recycle dead instances? Does it keep track of all active instances and handle updating all of them each frame? Does it keep them state sorted and other voodoo ready for rendering? Or does it act as a factory and hand out pre-configured particle systems based on xml/other data.

Classes should be small, simple and have a well defined name and purpose. 'Manager' violates all of these.

Everytime I use the word Manager I mean something that will

Quote:Original post by OrangyTang
act as a pool and recycle dead instances

Not "handle updating" or "keep[ing] them sorted and other voodoo ready for rendering."

Is there a better name for that?
ProjectilePool?

What if it handles file I/O for the data for these "Projectiles" as well so that the moment one is requested it is either loaded from disk or fetched from RAM?

Personally, I use ProjectileManager , seems more natural than ProjectilesManager.

If you're really unsure, just go with ProjectilePimp . Seems quite logical and unambigous to me. An object that pimps out objects of type projectile.

just kidding btw.