When refactoring many functions that share state in to a single class, how can you avoid writing an "escort" class?

Question

This well-known article criticises Java on the basis that it does not allow you to write functions that do not live in a class. This flaw forces you to write classes with names that look suspiciously like verbs, such as GridCellHander or GarbageDisposalDestinationLocator. In other words, it looks like you've built a class (i.e. a noun) to escort these methods (i.e. verbs). I believe that the article is entirely correct and I feel disturbed when I write a class with a name similar to these, particularly in a language that does not have Java's restrictions.

However, it is utterly standard advice that if you have a small amount of methods within a class that are all the only users of some of the class's state, then those methods and their shared state should all be placed in a different class. This maintains cohesion and keeps your classes small.

How can this advice be followed without writing an "escort" class that clearly only exists to hold these methods?

For example, I'm currently dealing with a grid. Some of its cells represent times. These times need to be sent to my server. I originally had two independent methods for handling them, one for deleting from the server and one for upserting. When I realised that they shared state, I put them and their shared state in a TimeCellHandler class. This let me significantly simplify the parameter list of the methods and let me write helper methods that they share. This follows the guidance described in my second paragraph, but violates the first. I can't just call this class TimeCell, because it plainly doesn't represent those cells; It only represents the small subset of their data needed to talk with the server about them.

Note that this question is language agnostic. The article linked gives the impression that functional languages (e.g. Scheme) can always replace TimeCellHandler with something better, but I'm just as happy to see an OOP or non-OOP answer. I don't care if you have to resort to CLOS or macros. I will be happy with any answer that demonstrates how to group two methods that share state in a sensible way that does not involve naming a class (or your language's most similar concept) in such a way that it makes it obvious that the class only exists to hold the methods.

Answer 1

So you've followed people's advice and split some logic and state into a class, but you cannot give this new class a good name. Now is a great time to examine the design decisions that lead you to this conundrum.

This part of the question immediately caught my attention:

However, it is utterly standard advice that if you have a small amount of methods within a class that are all the only users of some of the class's state, then those methods and their shared state should all be placed in a different class. This maintains cohesion and keeps your classes small.

This advice is often given when dealing with a very large class, and splitting the class up makes the code easier to reason about. You should be able to identify an abstraction that can be pulled out of that large class, which lives just fine on its own.

As with all advice on software design, you must assess whether this is beneficial to your current code. I also don't see how relentlessly moving code into smaller and smaller classes maintains cohesion. The concept of cohesion applies equally to how well classes cooperate with each other as it does to the members within a single class.

Fields do not need to be used in 100% of the methods in a class for that class to be cohesive. These things need to work well together and compliment one another. If they do that, don't separate them. They belong together (hence they are "cohesive").

Each time you reorganize some code, it should be fairly easy to give it a good name. The methods and internal state combined with your knowledge of the business process you are modeling should guide you when naming this new abstraction.

When you can no longer find a good name, stop. Put that code back where it used to be. It was fine there. There is nothing wrong with a subset of methods in a class accessing a subset of fields.

Another part of the question jumped out at me:

I can't just call this [TimeCellHandler] class TimeCell, because it plainly doesn't represent those cells; It only represents the small subset of their data needed to talk with the server about them.

I can see a couple of missing abstractions which might lead you to better names:

• What is this small subset of data? Is there a business concept associated with it? Consult with your end users, a subject matter expert, or whoever is gathering requirements for the application. They might already have a good name.

• Talk to the server? Deletes? Upserts? This sounds like data access logic to me.

You might be missing a business class that represents that subset of data. You also might be missing an abstraction that allows you to access and manipulate data in permanent storage, be that a file system, web service, or database.

Names become easier to identify once you refocus on the business process you are modeling. Try to identify other common categories of logic, like data access. This can lead you to better names, and other opportunities to move code into appropriate abstractions that still maintain cohesiveness.

Then you don't need "escort" classes and this question becomes moot.

Oh, and a quick thought experiment. If you cram a bunch of free floating functions into their own file, what would you name the file? And would that name be any better than the class that only serves as a container for those functions? Why wouldn't you name the class the same as that file?

Answer 2

These times need to be sent to my server. I originally had two independent methods for handling them, one for deleting from the server and one for upserting. When I realised that they shared state, I put them and their shared state in a TimeCellHandler class.

This is fine? Now you just need a name that represents what the code is rather than what it does. TimeCellServerConnection? Something similarly nounlike.

And you might point out that simply changing a name has no impact at all on the code's actual design. There's no change in performance or behavior. I'll leave it as an exercise for the reader the consequences of this fact.