naming -Manager, -Helper, -Factory is not good? My...

# naming

[chanjungskim]

naming -Manager, -Helper, -Factory is not good? My coworker said don't use it. And I don't understand because google also uses those names. And personally, I think those names are fine.

[bod]

I've heard people recommending against "XyzHelper" before, and "XyzManager" to a lesser degree, as there's a risk they will contain an ever increasing number of loosely related methods. So a more specific name is encouraged instead. I don't think this should be a hard rule, just a general advice that sometimes but not always applies.

Nothing against "XyzFactory", it's specific enough and I don't see what else you would name it.

[Oliver.O]

I consider class names ending in „er“ not a naming problem, but rather a design smell.

Here’s why: Such classes do not represent a concept which is easily understood by just looking at their name. Instead, they typically act like a dumping ground for an arbitrary set of functionality. To understand what they do you’d generally have to look into them.

My recommendation: When designing a class, try to define it like „_classname_ is a …“. If you can come up with a concise definition, you have found not just a proper name, but also a better class design. With „manager“ classes, this mostly doesn’t work and you‘ll end up with something like „_classname_ does …“.

[chanjungskim]

@Oliver.O Thank you for the explanation, But I don't get the point between 'is' and 'does'. For example, This class is a XyzManager. VS This class does manage something. Can you give me some more examples?

[Oliver.O]

It is a bit hard to come up with good examples, because we all are so used to bad designs which we have just internalized. When we learn hard stuff by repeated exposure, there is a point when we no longer notice that it was actually hard to get it initially. But I'll try:

A DatabaseConnectionPool is "a set of `DatabaseConnection`s, some of which are actively used, while others are cached for re-use". We know what it is right away and have an idea about its characteristics, like probably a limited size, right?

Now suppose, we name it a DatabaseConnectionManager and define it as "provides `DatabaseConnection`s". In this case, what it actually represents and what its characteristics are is not clear from its name or definition. Of course, we could learn over time how it actually works and internalize that. But getting it will never be as instant as with a properly defined non-manager class.

Another one from the world of UI systems: A View is "a visualization of a `Model`". A Model is "data capable of being visualized". In older systems, we find manager classes such as Controller or Presenter. We cannot really define what they are. And what they do is somewhat arbitrary. A certain function might sit in a View or a Controller. Practically, it may make more sense have it in a Controller, but this is not clear from the `Controller`'s definition (being just a manager class doing whatever stuff we see fit). Nowadays, in modern UI systems such as Compose you'll no longer find `Controller`s or Presenters, and these modern systems are way easier to work with.

This all might seem subtle, but in my experience, being disciplined in naming and defining classes according to what they are rather than what they do leads to designs which work better in the long run and are easier to understand for casual readers with infrequent exposure (and that might be your future self).

[Matteo Mirk]

Lots of good advice in here:
https://www.yegor256.com/2015/03/09/objects-end-with-er.html

[chanjungskim]

Now I feel like using '-er' is fine. Maybe the problem was too broad meaning. Google also uses like Modifier, Receiver, Listener, Observer, Controller, etc. I'd like to see big projects that don't use -er. 'NEVER USE -er' is nonsense. Then what about 'Student' or 'Class', 'Participant'? All the names must be specific and all class names must be clear, not only '-er'.