PDA

View Full Version : prefered way to name things


cpucpu
04-12-2010, 12:12 AM
This is an easy one.
KeyboardManager vs ManageKeyboard
ScrollManager vs ManageScroll

and so forth. how'd you do it?

TomMalufe
04-12-2010, 03:41 PM
I would use KeyboardManager but put it in a manager package (maybe). Actually, all I can say for sure is that I would name it KeyboardManager.

cpucpu
04-12-2010, 07:22 PM
Yeah, many things i have are called manageX, and started to feel like the counterpart could sound more appropiate. I actually have it under ui likewise mouse manager.

maskedMan
04-12-2010, 07:40 PM
Class names should be nouns, since classes represent "objects."

fooManager is a noun
manageFoo is a verb.

Therefore, I'd say fooManager is the way to go.

MichaelxxOA
04-14-2010, 08:24 PM
A suggestion unrelated to your original question. One of Arthur Riel's Object-Oriented Design Heuristics (http://www.amazon.com/Object-Oriented-Design-Heuristics-Arthur-Riel/dp/020163385X) is "Do not create god classes/objects in your system" (http://en.wikipedia.org/wiki/God_object). He goes on to say "Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem."

If you're curious (as I am) for what purpose are you abstracting keyboard management and scroll management?

cpucpu
04-17-2010, 02:34 AM
Yep. But not only that, i also have managers for mouse, collitions, ... it's very handy :) I don't really think that be a bad practice, again they're very productive and easy to use.

As for your particular question, in the case of keyboard i'm abstracting it for a very, very simple reason. want to register some keys? intead of register every damn key in their very own addEventListeners with their won handlers functions, i am tired just to write this, i just manageKeyboard.regiterKeys({keys and callbacks}); and write their callbacks.

This kind of abstraction won't be suitable everytime, but has been a very sweet experience, and it also lets room to develop a very structured and standarized api aswell.

maskedMan
04-17-2010, 04:56 PM
intead of register every damn key in their very own addEventListeners with their won handlers functions, i am tired just to write this, i just manageKeyboard.regiterKeys({keys and callbacks}); and write their callbacks.


But you don't have to register a new handler for every keystroke... that's actually a *really bad* way to go about it in the first place. You'd have about 50 listeners firing off every time *any* key is pressed, while they *all* try to figure out whether they should care about the one key you pressed.

Instead, you should just have one listener and inside that, use a switch or something of the sort to determine which key was clicked and call something else from there.

cpucpu
04-17-2010, 11:05 PM
Yeah i am sorry for that, i didn't want to write that. My point actually is that when you develop 'managers' you do that cause you don't want to re-develop that logic for every new project, so to save dev time you code and later rapidly implement that consistent api, so you can concentrate in project's original needs. Sound handling or keyboard handling among others are very general things whose implementation needs will hardly change from one project to another.

maskedMan
04-18-2010, 05:05 AM
Sound handling or keyboard handling among others are very general things whose implementation needs will hardly change from one project to another.

Oh man, if only that were true...

You can generalize to a certain extent, yes. I'd be careful thinking you can put a nice leash on sound and call it 'managed' in Flash, though. There's a lot of different ways in which people 'expect' sound to behave that can be mutually exclusive, and a single "manager" is hard pressed to keep up.

cpucpu
04-18-2010, 06:00 AM
As for sound, think on it as a real sound device, a physical radio for example.
All people knows how to use it, and want wants from it, buttons more buttons less you can define what a radio is made of, what it will do, and construct a general purpose radio. Developing a sound manager to satisfy those needs is very general. If then comes a dj a wants to handle sound thats another whole story.

Sound handling or keyboard handling among others are very general things whose implementation needs will hardly change from one project to another.
But again, your sound needs will hardly change from one project to another. Unless you be a sound enginner, a sound handler class will be quite enough to you for sure. Just make sure you develop a good api that satisfy you and your dev team.

mindprism
09-13-2010, 11:06 AM
NounModifier and NounVerb

bradosia
01-16-2011, 05:01 AM
KeyboardManager
ScrollManager

make the biggest topic go first then the descriptions afterwords.
in this case the manager is descibing it