When do I call my class controller, manager or service?

Question

Maybe it is obvious to you. I'm new to java (half year work) and I had a discussion with my collegues. I have troubles naming my classes according to their responsibilities. For that, my classes gain responsibilities they should never have.

Can you help me?

BTW: I'm working current at a project where I have to use a persistance-layer from service classes. I have split my packages to model, service and persistance.

Costrel

Answer 1

There are certain patterns and guidelines behind these term, which is where I usually base it on:

Controller is based on the Model-View-Controller design pattern and should be used explicitly for the classes that implement the controller functionality based on this design pattern. E.g. if you are using Spring MVC and you extend from one of the Controller classes.

Service is a little less specific, but I recommend basing the implementation on the Service Layer pattern from "Patterns of Enterprise Application Architecture". Basically where a controller is more platform specific (e.g. transport via HTTP and rendering of Hypertext, usually HTML for web based controllers) a service shouldn't have to know about who is using it and how. You are just providing a uniform interface that can be used in turn by e.g. a web controller.

Managers well... manage stuff. Connections, application context, sessions; usually as a central location where components throughout the application can talk to.

Athanor

Answer 2

To add to the good answers already given, if you find that you have a hard time finding a suitable name for your classes, then maybe you should investigate if your classes have more than one responsibility. If this is the case, then you should definitely refactor your code to isolate responsibilities into separate classes.

Borodin

Answer 3

For naming convention please read the official convention.

Manager - As the name suggest which manages things in your code like EntityManager, it manages Entities, TransactionManager - It manages transaction. So you can have something called as SecurityManager which manages which Algo to use for encryption e.t.c

Controller - Again name speaks a lot, controls how what needs to be done, or how things to be done. For e.g. ActionController - takes care of what to do on receiving user action event

Service - Consider it something like postalService, a task performed by someone on a general note, you can make use of it.

Packaging code needs lots of thinking, your application packaging should always align to the business model which it is catering to.

Along with business model then you need to think if the feature is very much at heart of the application so you will move it to the core, say if the feature is for talking to other application you would like to move it under integration and so on.

Orly

For the convention, it should be mentionned that sticking to your business's conventions rather than Sun's is better. Sun's guidelines is certainly a good starting point, but in the end, your cowerkers will be maintaining your code (and you will end up maintaining theirs), so you should follow your company's convention (if you have one that is..). – Borodin

Agreed, but definitely more or less your company coding standard will kind of follow sun ;) – Orly

I would expect what you say is true ;) But I guess we could have some fun digging for the craziest coding standards out there. – Borodin

Official conventions are no longer supported, see disclaimer by Oracle oracle.com/technetwork/java/codeconvtoc-136057.html – Issi

That convention has nothing to do with what OP is asking. – Joselow

Answer 4

I do not know if I ever named a class manager so I'll leave it out.

For me controller is something controlling or deciding where should something (signal, message,..) go.

Service is an interface (and implementation of that interface) providing some functionality, usually at the border of system or sub-system. Hides implementation details as much as possible.

Exostosis

What's your secret to avoiding "manager" in class names? – Purdah

@MichaelOzeryansky i think the poster means without needing to offload to a 3rd party function to handle. Managers are usually a class that has another sub-class doing the service or logic being demanded. So, it's possible if you access directly (i.e. without an additional layer of separation), you can circumvent its uses. (Bundle logic and services directly into core function will remove need for manager). – Naomanaomi

@Naomanaomi My most common use case of managers is combining a few services into a function call. Instead of doing this combination each time, I defined the function in a manager. The manager may also be instantiated with common properties to be used among all the services. But the posted said "I do not know if I ever named a class manager", so I was asking specifically about that. Avoiding naming something "manager" by naming it "controller" isn't avoiding the problem. – Purdah

No, I tend to avoid the term manager as it is too vague. I would probably use it for a class, instances of which are supposed to take care about assignment of resources and even their lifecycle or access to them. That does not happen often I need such a thing. Just combining some calls does not deserve a special name, calling it manager does not fit - as for design patterns it sounds the most like a facade. – Exostosis

Answer 5

If you can, avoid terms like controller, manager, and service altogether. These are generic terms and classes should have specific names, not generic names. Generic names often lead to the creation of God objects.

E.g. assume you have a class named PasswordManager, what does that class do? Obviously it manages passwords, okay, but what does that even mean? It persistently stores passwords encrypted to disk, it keeps decrypted passwords in memory, as reading them from disk and decrypting them is an expensive operation, and it provides passwords to the app parts that need access to them. But instead of having one generic manager object, why not creating three classes named PasswordDiskStorage, PasswordMemoryCache and PasswordProvider, where the name tells you exactly what the purpose of this class is?

A StringBuffer class in fact manages a string buffer, so you could name it StringBufferManager but naming classes is all about what they are not so much about what they do. Controller has a fixed meaning in abstraction models like MVC but doesn't mean much outside of it as pretty much every code you write controls something to some degree and would thus be a controller.

See also:

Naming Classes - How to avoid calling everything a "Manager"?

How do I avoid writing Manager classes?

How to avoid "managers" in my code

Tiu