The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

We're becoming illiterate

<RANT>

Anybody else hate classes that have the word "Manager" or "Handler" or <fill-in-the-blank> in them?  Sheesh..  If you're going to spend time to try to write a class, why not spend a few minutes to think of an appropriate class name?

Also, does anyone else run across misspellings in method names?  I think that's awesome:

  OnRecieve() // Moron

Or methods that use cutesey things like replacing the word 'For' with '4'?

  Prepare4Processing()  // Should be shot

</RANT>
Meganonymous Rex Send private email
Thursday, October 05, 2006
 
 
Manager" or "Handler" - propose an alternative.
Denis Krukovsky Send private email
Thursday, October 05, 2006
 
 
+++++++++++++++++

Agree, I hate that.

e.g. Microsoft's .NET database gateway class for Oracle is called OracleHelper.  Helper??!!  Every class is helpful or else why use it!?!
Mike S Send private email
Thursday, October 05, 2006
 
 
> Every class is helpful or else why use it!?!

I have a public Foo class, which implements the public IFoo interface.

I'd like (as an implementation detail) an auxiliary class, that would be used in the implementation Foo: this helper class would be "FooHelper".
Christopher Wells Send private email
Thursday, October 05, 2006
 
 
StrategyAdapterFactoryBuilderManagerFacade
DEBEDb Send private email
Thursday, October 05, 2006
 
 
> Also, does anyone else run across misspellings in
> method names? 

How's creat(2) for ya? :)
DEBEDb Send private email
Thursday, October 05, 2006
 
 
interface IHandlerManager
{
  void ManageHandler(handler);
}

// Usage
IHandlerManager manager = GetManager4Handler(manager);
manager.ManageHandler(handler);


Personally, I don't know what your problem is.  This stuff is golden.
Posted by me
Thursday, October 05, 2006
 
 
My key point is: there's something in a name.  If you don't know what to call something, then you probably don't understand the problem.
Meganonymous Rex Send private email
Thursday, October 05, 2006
 
 
Man, I wish we could edit these posts.

...GetManager4Handler(handler);

Glad I caught that before it went into production (handler is defined as type Object, so the compiler wouldn't have helped me).
Posted by me
Thursday, October 05, 2006
 
 
Posted by me:

I bet we work at the same place!

LOL
Meganonymous Rex Send private email
Thursday, October 05, 2006
 
 
So... something like "ConnectionPoolManager" is right out, then?
John Haren Send private email
Thursday, October 05, 2006
 
 
If it manages a pool of connections, then "ConnectionPool".

"FooHelper" - helps in what way?
Mike S Send private email
Thursday, October 05, 2006
 
 
Anything related to programming with the word "Manager" in it, such as the term "Development Manager", is definitely a bunch of bullshit.

:)
Meganonymous Rex Send private email
Thursday, October 05, 2006
 
 
"If it manages a pool of connections, then "ConnectionPool"."

It's not the "connection pool" itslef, it is the object that manages/controls the pool. So you need to come up with some name to distinguish it. The bottom line is that we can't always come up with something super descriptive. After all, don't you have a "manager" who watches over you? Should this person's title be changed because the word manager doesn't have any real meaning? Of course not! We all understand what a manager does. So why not let us use the title when it makes sense?

The real issue is people using these types of phrases even though they don't fit in the current context. If an object manages something then call it a manager. But if it doesn't manage anything... then don't.

See this link for more on this rant. You are only about six months behind the curve with this post. ;)

http://www.codinghorror.com/blog/archives/000553.html
Turtle Rustler
Thursday, October 05, 2006
 
 
That's why I like to abbreviate my suffixes.

class PoolMgr, for instance.
AllanL5
Thursday, October 05, 2006
 
 
Perhaps the problem isn't what to call the ConnectionPoolManager.  Perhaps the problem is why we have one in the first place.  Why does the ConnectionPool need a manager?  Why can't it manage itself?
Kyralessa Send private email
Thursday, October 05, 2006
 
 
I have no problem with calling a manager a manager, if that's what it does.  It's the "calling everything a manager/handler" stuff that kills me.  It shows that the developer was hasty during the "design" process.

I rarely rant here.  I usually lurk and try to help when I know something, but this is a sore point with me today for various reasons (legacy code i now own.)
Meganonymous Rex Send private email
Thursday, October 05, 2006
 
 
+1 Kyralessa

Exactly my point Re: Design.
Meganonymous Rex Send private email
Thursday, October 05, 2006
 
 
I wish nameing conventions were the pinnacle of the problems I have to deal with in the code I maintain
newby
Thursday, October 05, 2006
 
 
... and yes, I did spell that wrong.  I'm illiterate too.
newby
Thursday, October 05, 2006
 
 
"Why does the ConnectionPool need a manager?  Why can't it manage itself? "

Because I may have more than one connection pool? Or maybe "connection pool" is implemented as an abstract class and you use the factory pattern to create and therefore manage a pool based on other conditions?

But even though a connection pool may actually be a good candidate for an object that should manage itself, we know that not all objects can. For example, I have an IconManager class. This class is responsible for creating and maintaining a cache of icons that are being used. When someone needs an icon they ask the IconManager for it. This saves tons of resources and ensures that things get cleaned up properly. Now you could say that an icon class could manage itself. But not in the way that my IconManager class does. I'd also bet that most people would understand the role of a class called ResourceManager. Managing resources makes a lot more sense than managing a connection pool since as stated a connection pool could technically manage itself in many situations. 

Anyway... There is nothing evil about the word manager. Apply it when it makes sense and not when it doesn't.  :P
Turtle Rustler
Thursday, October 05, 2006
 
 
Turtle Rustler:

Those are great examples of where the word "manager" makes sense.  Although I was trying to be sort of tongue-in-cheek, I'm not against any word per se, I'm against poor designs and I believe that poor names may be a sign that the underlying design is also poor.

And, this is not a new idea.  (Nor is it the biggest problem I face today, Newby) but it's what's ticking me off at the moment.
Meganonymous Rex Send private email
Thursday, October 05, 2006
 
 
I am guilty of both problems sometimes and it bugs me.  For some reason I still find coming up with good names difficult.  Bad spelling gets me way too often also, where's the red squigly for my misspelled method name!  Come on IDE's you do everything else for me! :-)
Bill Rushmore Send private email
Thursday, October 05, 2006
 
 
If you can't easily name something descriptively (and a generic name is often indicative of the programmer's inability to do so)... then... you probably can't describe clearly and concisely.

And if you can describe some element of your design (function, class, etc.) clearly and concisely, the name is the least of your problems.

Or to put it another way: Generic not-descriptive names are often a sign of bad design.


But then again, you've got to love code like

MyObject theObject = GetManager()->GetHandler()->DoIt() ;
Sunil Tanna
Thursday, October 05, 2006
 
 
+1 It's not the words, it's the design.

I just use certain words as a heuristic to challenge myself to see if I really know where I'm going with my design.

e.g.

IconManager: "This class is responsible for creating and maintaining a cache of icons"

Ok, IconCache, then.  Just tells me a little bit more about what the class does.

And yes, I've been accused many times of over-obsessing on words!  I'm getting treatment...
Mike S Send private email
Thursday, October 05, 2006
 
 
"IconCache" is fine too. But the manager does a little more than just cache the icons. And most people are more comfortable remembering the syntax/name of a more generic "manager" object than having to remember that a class is actually a "cache".

It goes both ways. I would prefer to have several objects with consistent naming like: IconManager, SoundManager, FontManager, and ImageManager; than to be more specific and have to remember names like: IconLoaderAndCache, SoundPlayerAndLoader, ImageLoader, and FontCreator.
Turtle Rustler
Thursday, October 05, 2006
 
 
"I wish nameing conventions were the pinnacle of the problems I have to deal with in the code I maintain"

They're hardly the only thing wrong with code I maintain, but they make everything else harder.  Right now I'm dealing with stored procs where somebody aliased tables "a", "b", "c", "d", and "e".  The aliasing has nothing to do with the problem I have to fix, but it makes it pretty darned hard to figure out what the tables are doing in that statement.  (But hooray for SQL editing in Visual Studio, where I can open the query designer window and change those aliases with no hassle; a far superior alternative to search-and-replace, since this person used the same alphabetic alias system in several places in the same proc to refer to different tables.)

"I would prefer to have several objects with consistent naming...than to be more specific and have to remember names like: IconLoaderAndCache, SoundPlayerAndLoader, ImageLoader, and FontCreator."

Who's remembering names?  I've got Intellisense.  :)
Kyralessa Send private email
Thursday, October 05, 2006
 
 
Hmm...

Maybe ConnectionPooler?  I.e. we say "farmer" not "farm manager" right?


Even so it has a somewhat unsatisfying feel on the tongue.
Slim Simi
Thursday, October 05, 2006
 
 
Actually, my last name is Swiss-German for "Farm Manager" (from what my great-great grandmother said).
Steve Moyer Send private email
Thursday, October 05, 2006
 
 
"Maybe ConnectionPooler?  I.e. we say "farmer" not "farm manager" right?"

A ConnectionPooler is a pooler of connections.  This sounds very different from a manager of connections.

And I'd venture to say lots of large farms have managers these days.
Posted by me
Thursday, October 05, 2006
 
 
The naming conventions that really drive me crazy are the ones that are based almost entirely on pattern labels.

StrategyVisitorImpl

Every time someone names a class like this, God kills a puppydog somewhere.

When classes are named like this, they leave all of the key semantic information out of the name. What kind of strategy is being applied? What kinds of objects are examined or modified during the execution of the strategy?

And what does the visitor do? If it's a visitor, then I know it's performing some kind of uniform operation on all of the Strategy objects, but what does the visitor actually ***do*** when it visits those objects?

A better name, in my opinion, would be something like:

PlayerAiLogicExecutor

Even if the AI logic is implemented with a Strategy pattern, and even if the Executor uses the visitor pattern to sequentially execute the different players' AI logic, I think the second naming convention is better. Because it puts important semantic information in the class name, rather than cluttering it up with "Look at me!! I know patterns!!" noise.

So, save a puppydog, and stop referring to pattern definitions in your class names.
BenjiSmith Send private email
Thursday, October 05, 2006
 
 
My personal favorite was a FooFacade and a BarFactory that were actually a FooFactory and a BarFacade..

It was in code designed by someone who obviously new lots of design pattern names, but didn't actually know what they were for.

Bug hunting in that was like bug hunting in the Louisana swamp lands. Lots of bugs, but finding the one you were looking for...
dwayne
Thursday, October 05, 2006
 
 
You think the front end code names are bad?

Try the database side.

A million times worse.

Just a snippet of some awesome table names:

AF00100
AF10000
AF40100
AF40101

At least your stuff is actual words...
D in PHX Send private email
Thursday, October 05, 2006
 
 
The need to use all these "Manager", "Handler", "Controller" suffixes seem quite ironic to me, in the world of OOD. On one hand you try to get away from the "old" function libraries by attaching verbs to made-up classes, but then -- naturally -- the whole library becomes the class.
hobit Send private email
Thursday, October 05, 2006
 
 
> "FooHelper" - helps in what way?

'Foo' (not it's real name) is the public methods which implement database persistence of user types. These methods are implemented by calling subroutines (several levels deep).

State (including the type of the object being persisted, the value of the object being persisted, and a reference to the current database transaction) needs to be passed down this call stack.

More state (e.g. the list of changes made to the user object by the subroutines) needs to be returned back up the call stack (e.g. so that changes made to the client-side representation of the object can be undone if the database transaction fails).

I could implement this (passing state up and down the call stack) using several parameters; but, instead, I just use one parameter, whose type I've named 'FooHelper'.

I guess I could have called it FooState or FooParameters or FooAuxilliary; but I find those no more descriptive that FooHelper.

Anyway .. all off topic, since the OP was intended as a rant. :)
Christopher Wells Send private email
Thursday, October 05, 2006
 
 
"If you don't know what to call something, then you probably don't understand the problem."

True dat. However, the problem comes when you are writing dynamic code, when the logical names of your code happen to also be reserved words. Here's a suggestion: bring back the underscore. PL/SQL developers never forgot about it.

As far as the ConnectionPoolManager, shouldn't they be class methods (or whatever they're called in your OO language of choice) of ConnectionPool?
Steve Hirsch Send private email
Thursday, October 05, 2006
 
 
DEBEDb's comment reminds me of a quotation in Kernighan & Pike's "The UNIX Programming Environment" --

"Ken Thompson was once asked what he would do differently if he were redesigning the UNIX system. His reply: 'I'd spell creat with an e.'"
Phil Lodine Send private email
Friday, October 06, 2006
 
 
"If you don't know what to call something, then you probably don't understand the problem."

Not necessarily. Maybe you just know that the user will not understand a name like "IconLoaderCacherDestroyer" so you opt for something more universally understood like "IconManager".


"As far as the ConnectionPoolManager, shouldn't they be class methods (or whatever they're called in your OO language of choice) of ConnectionPool? "

If you have access to the actual ConnectionPool class itself then that is also a valid way of implementing it. But if you have more than one type of connection pool or the connection pool is implemented in each RDBMS and you don't have the source code for it then ConnectionPoolManager makes more sense.

Another issue I have with being more descriptive in names is what happens when responsibilities change? Take IconManager vs. IconCache for example. What if later on I decide that I don't want to cache icons anymore and the sole purpose of the class is just to load icons? Or maybe I decide to only cache certain types of icons? Now the class is no longer really a cache.

Also, why does the user need to know that the icons are cached? Isn't it better to just tell them that we have an object for "managing" icons and they should use it per our specifications? Do they really need to know what kind of "managing" a manager class really does?

As I said before, I personally would rather see a group of consistent names that people understand how to use than to have every little detail spelled out to the user. Programmers are stupid. Give them simple names like IconManager, SoundManager, and FontManager. They don't need to know what goes on inside those classes, just how to use them.

Let the flames begin!
Turtle Rustler
Friday, October 06, 2006
 
 
I don't like flames, but I do like respectful debate. After all, why do we program in the first place if not to argue? (:=)

"Another issue I have with being more descriptive in names is what happens when responsibilities change?"

Change the name? Or, create another distinct class? Some ideas.

I love love love descriptive names. I insist on them. They should accurately describe what something is or what something does.
Steve Hirsch Send private email
Friday, October 06, 2006
 
 
> Another issue I have with being more descriptive in names is what happens when responsibilities change?

The same problem can happen with variables, function and even file names.  If you are really concerned about it, call your variables v1, v2... your functions f1, f2.... and your code files code1.cpp, code2.cpp, etc.
Sunil Tanna
Friday, October 06, 2006
 
 
Turtle Rustler:

Great point!  And I don't think it's a flame as much as a debate.  And every choice made by a programmer or engineer is a compromise of some sort and perhaps the result of just such a debate (even if you're debating yourself at your desk.)

Should a class name reflect the details of the implementation?  Probably not.  In this case, something like "IconManager" is probably a perfect name. 

In spirit, my original rant was against people who just pick lofty names out of thin air with little respect for the design/thought process, and not a rant against specific words.  I just did a bad job of writing my original post.

Paradoxically, I think that the adoption of "patterns" has made this problem worse, not better.  I'm curious to see what people think about THAT statement.
Meganonymous Rex Send private email
Friday, October 06, 2006
 
 
To answer Rex (the OP): could it be that someone writing buckets of code under tight deadlines just runs out of good names for things? At some point most people's creativity suffers under pressure.

Also, last I checked, most programmers don't write well and don't even like to write. Naming things is a linguistic skill.
Bored Bystander Send private email
Friday, October 06, 2006
 
 
"Should a class name reflect the details of the implementation?"

Probably.

Interfaces should have names that just describe the public API. Classes should have names that describe both the public API and the underlying implementation.

HashMap, anyone?

(Personally, I think the name "IconCache" encompasses the loading, cacheing, and destruction responsibilities of the class, and I like it better than "IconManager". But that's just a personal preference. At least it's not an IconInterceptorReflectorFactoryImpl.)
BenjiSmith Send private email
Friday, October 06, 2006
 
 
> To answer Rex (the OP): could it be that someone writing
> buckets of code under tight deadlines just runs out of
> good names for things? At some point most people's
> creativity suffers under pressure.

I don't know, but I'll tell you one thing, I'm sort of tired of the "under pressure" excuse.  Being under pressure is often a part of our job.  We are supposed to perform well despite the pressure.  Could a surgeon walk out and say, "Well, I only put about half the stiches in the guy that I should have, but I was under pressure.  I hope it works out."

> Also, last I checked, most programmers don't write well
> and don't even like to write. Naming things is a
> linguistic skill.

I've seen more "don't like to do it" than "don't do it well."  I find programmers to be some of the most interesting, well-spoken individuals I've ever met.  Just reading this board, I get the impression that good programmers are just all around good thinkers and communicators.  Just look at BenjiSmith's web site, or this one for that matter.  So, I'm not totally convinced, but I'll grant you that many would rather write code than write documentation.
Meganonymous Rex Send private email
Friday, October 06, 2006
 
 
"Should a class name reflect the details of the implementation?"

Probably not.  It should reflect the service visible to the client.  I might go with "IconRepository" as something that provides me with icons when I need them - whether it uses a cache or not is invisible to me as the client.

And what if provides multiple services?  Then I wonder about the design - see http://en.wikipedia.org/wiki/Single_responsibility_principle

I should say that my experience is in enterprise application development where I might be dealing with thousands of domain classes and it's important to get as much information as possible from a glance at the class name.

I think in library API design there are other priorities and implementation information, fewer classes and consistency in naming as Turtle Rustler says may be more inportant.
Mike S Send private email
Friday, October 06, 2006
 
 
"I've seen more "don't like to do it" than "don't do it well."  I find programmers to be some of the most interesting, well-spoken individuals I've ever met."

It's always seemed to me that the programmers who were good all-round communicators tended to write better code. I wouldn't make it a blanket statement, but in general, my experience has been that spaghetti code was most likely to come from those unable to communicate their ideas well in common language, either written or spoken.
dwayne
Friday, October 06, 2006
 
 
"IconInterceptorReflectorFactoryImpl"

That would be hilarious if it wasn't so true.  :)
Turtle Rustler
Friday, October 06, 2006
 
 
IconRepository is a good name. It tells you that it is something to do with storing icons, and one would presume it may have methods to store and retrieve from permanent storage.  It also tells you [or a future programmer] what sort of things shouldn't be in the class, e.g. editing an icon, or converting one icon file format to another.

IconCache is an okay name, even if it perhaps exposes too much detail of the implementation.  Like IconRepository, it's possible to make reasonable inferences about the sort of methods should be in the class, and what shouldn't.

IconManager is an awful name. It tells you nothing about the sorts of methods to expect in the class.  It doesn't define what the class should and should not do.  It is potentially a catch-all of anything to do with icons.  It simply spaghetti waiting to happen.

In short, even if it doesn't start out that way, after 5 years maintenance, from 20 programmers,  IconCache and IconRepository will almost certainly still be readable, focused, and serve a specific clearly definable purpose - but IconManager won't.
Sunil Tanna
Friday, October 06, 2006
 
 
I don't mind the use of Manager because it's a good signal to me that the code I'm looking at is most likely crap.  I've found that Manager classes tend to be where bad developers throw the equivalent of global variables and think it's okay because they put their globals in an object.  Even better is when Manager derives from a Singleton base class. 

I worked at a place where pretty much every subsystem had to have it's own "Manager" class no matter how stupid an idea this was.  For example, if they wanted a Shape class, they'd have a ShapeManager that you'd have to use to allocate new Shapes.  The actual Shape's behavior would be randomly distributed between the Shape class and ShapeManager class depending on what mood the developers were in when they were adding new code.  Concurrency was always fun because the Manager classes would of course have a ton of state.  I still have nightmares.  Ugh, thanks for reminding me!  (Actual class names have been changed to protect the guilty.)
SomeBody Send private email
Saturday, October 07, 2006
 
 
> Why can't it manage itself?

Why can't your manager right your code? Because roles dictate responsibilities and responsibilities are indicated by names and we want to separate out responsibilities rather than ball them into one tangles pile of code. Which you seem to advocate.

Manager indicates some sort of meta capability above and beyond a cohesive type. By including both in the same type you cloud both responsibilities. A connection pool should perform the responsibilities of a pool and just a pool. In my thinking that doesn't include responsibilities like handling collections of pools, creating pools, deleting pools, configuring pools, etc.

As someone said, using Manager everywhere is a problem. Simply using Manager can indicate a keen understanding of roles and responsibilities and the need to keep ideas cohesive.

Helper has very specific meaning. Handler also usually has a specific meaning. Why would you prefer to get rid of that helpful information.

Having an example would be  helpful. My guess is you can't think of names that would be widely seen as better.
son of parnas
Saturday, October 07, 2006
 
 
I use "handler" as well. But for cases where the class actually "handles" something. For example I have a class named SocketRequestHandler. Guess what it does (see answer below).









Answer: It handles requests made to the server through a socket connection. Note that it doesn't "manage" them or "help" with them so SocketRequestManager or SocketRequestHelper would probably be inappropriate names.  :)
Turtle Rustler
Saturday, October 07, 2006
 
 
OT:

"If you don't know what to call something, then you probably don't understand the problem."

Ever been through the naming of a product, complete with input from Marketing, focus groups, lawyers, etc.?
AFTO Send private email
Tuesday, October 10, 2006
 
 
Haha, no, but remember, this isn't a product.  It's a class name for internal use.  I can't imagine how bad it must be to come up with a committee-approved product name!  Especially if there are attorneys involved!
Meganonymous Rex
Wednesday, October 11, 2006
 
 
I dislike the use of abreviations, including 4 as "for" and 2 as "to".
Wouter Lievens Send private email
Wednesday, October 18, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz