A programming rant

Now I'm by no means an expert on OOP, far from it - I'd be the first person to admit I've got lots to learn. But I feel I must vent slightly...

OOP is not singletons. It's not creating a TextureManager class and a InputManager class, and a LevelManager class, and a ModelManager class, then bolting the whole lot together with sticky tape and sheer bloodyminded stubborness. It's not about using private member variables and then just writting setters for them so you can tinker with them from some far removed part of your code. In short, it's not about taking your C code and stuffing it into a bunch of ill-fitting classes [1].

I'm fed up of seeing (and dealing) with all-encompassing, overreaching 'classes' where theres only one ever instanciated (usually a singleton) and just ends up being used everywhere. These always have vauge names like SomethingManager and even move vauge responsibility.

Names define a thing. Change the name and you change the thing. A moment of lazyness (when someone comes up with a name like FooManager) means the class has no well defined behaviour or reponsibilities. Suddenly it becomes a dumping ground for all Foo related code, regardless of whether it actually belongs in there in the first place. We almost always end up with ill-defined dependancies (or rather, we have lots of dependancies because nobody knows which dependancies are acceptable and which aren't). Eventually it becomes that you can't do anything with a Foo without going via the FooManager. FooManager gets bigger and bigger, and because of the aforementioned problems it becomes impossible to make it smaller - everything is intermingled and theres no natural 'fault lines' at which to split it up into smaller, more managable classes.

Eventually you end up with something thats big, brittle and totally impossible to reuse. It takes more time to maintain it than it does to use it, and the whole thing gets scrapped and rewritten. And then it gets rewritten in exactly the same way, because it'll almost always start with an equally vauge name.

Please, next time you create a class, think about it's name. Names are hard, I know, but thats no excuse for using shoddy undescriptive names. Other name fragments which are suspect include "Handler", "Data" and "Object". They add nothing of meaning - they're just noise.

Most times it seems that instead of FooManager the name FooPool would be more suitable, but I'm sure theres several other common alternatives that people can think of.

[1] Actually this is unfair. C code can be quite nice, but in this kind of case it's almost always bad C code in the first place.

Share this comment

Link to comment

Thats a really neat way of looking at method names, I like it! Flicking though my current code I can already see that the well named ones follow that convention, I'll have to see if I can come up with something better for the rest.

0

Share this comment

Link to comment

You're dead on. I used to code like this. Manager here, Manager there. Monolithic classes with far too many responsibilities... It's good that I saw the error of my ways, and I'm more or less cured now.

About an earlier post of yours: I'm also in favor of "implement quickly, then refactor and optimize", especially with a quick-to-write language like Python. You don't become as protective of things that took a day to write than things that took a week.