Why you should not have Managers in your class name | Karan Kurani 1) { event.preventDefault(); window.history.back(); }"><br>← Back<br>Why you should not have Managers in your class name<br>February 12, 2018 photo<br>#managers<br>#coding<br>#design patterns<br>#software engineering<br>And why you should be careful about anything that ends with -er. Before I go any further, please go and read Steve Yegge’s blog post on the overuse of Nouns in Javaland.<br>Most coders I know do not give naming things the importance it deserves. It is highly critical to get the class/method name right the first time.<br>The name will affect the way you structure your code base, think about<br>it further down the line, how you refactor and extend it. Nothing<br>creates technical debt faster than choosing a wrong name for your class.<br>It will come back and bite you very painfully.

The name of a class will determine how you delegate<br>responsibilities to that class. Let me illustrate. Lets say you are<br>designing the iOS client for Shoutt.<br>The client needs to establish a connection to the server, fork over the<br>data and then handle the response. At this point many coders will say -<br>“Aha! What we need is a ConnectionManager which manages all these<br>tasks.” So we go ahead and create that class with the required<br>functionality.<br>It works fine until we realize that the app requires<br>multiple simultaneous connections to the server. Now because you have a<br>ConnectionManager, you go ahead and introduce an array inside the class<br>which maintains the state of all the open connections to the server. The<br>code is a tad little bit more complex because each connection is<br>established by a different object in the client and the response needs<br>to be routed to the appropriate caller.<br>Fine so far… Oh wait, but now the client also needs to<br>handle retries in case of failure. What do you do if one of the<br>connections fail? You introduce a hashmap in ConnectionManager which<br>maintains the number of retries a particular connection has made to the<br>server.<br>Oh crap, what if the object establishing the connection<br>wants to end it before MAX_RETRIES is reached? So now you have a<br>connection_id which is stored on each view and is used every time you<br>want to cancel the connection. Also, did I mention that sometimes<br>connections need to be asynchronous and sometimes synchronous (this<br>requirement crops up two weeks into building the app btw). So now, in<br>your code base, when you want asynchronous connections, there is an<br>event thrown in the ConnectionManager with the connection_id that shows<br>the response. But in case of synchronous connections it returns the<br>response immediately. So you have two methods on ConnectionManager<br>object called establish_sync_conn() and establish_async_conn().<br>At this point, your ConnectionManager object has an array,<br>a hashmap, probably another hashmap to track connection types and two<br>different methods just to create a connection. Its a very complex thing<br>to look at. Even worse is the fact that if someone else looks at your<br>code, it will take them a while to figure out whats happening where and<br>how everything is linked together. It also makes you prone to make<br>mistakes and have more bugs/complexity in your code.<br>What would have happened if you had named the class just Connection instead of ConnectionManager? Just because of the name being<br>Connection you think of it as a proper object (like a proper connection<br>- think of it as an information pipeline between the client and<br>server). You need multiple connections? Just create another object of<br>connection. What about a single connection for the entire app? You just<br>create a global connection variable which has that object. Retrying is<br>also maintained by each connection object independently. How about max<br>retries? You just have an internal max_retries variable in the class. So<br>each connection maintains it’s state internally. Since we have separate<br>objects for each connection, each object can just handle that<br>connection on its own and terminate it without worrying about whether<br>there are any other connections or not. What about the sync and async<br>type of connections? The answer is in the word type. You pass in the type of connection you want in the constructor and the object is setup accordingly.<br>Obviously the ConnectionManager could be designed differently and made cleaner, but giving the name Manager makes defining the responsibility of the class ambiguous. On the other hand, naming the class Connection would make its responsibility clear and unambiguous.<br>Anything that has the name manager (or anything else that ends in -er) in it is usually (not always) a code smell<br>that you haven’t designed your application properly. Eliminating that<br>type of class will automagically lead you to write much better code and<br>keep things simple as you extend your application.<br>Picking the right name helps you keep your code structure<br>clean. It also make it easy to extend as well as refactor. So next time<br>you are naming a class, please give it an extra 5...