Skip to main content
Software Engineering

Return to Answer

Rephrased part of the answer to sound less argumentative.
Source Link
Greg Burghardt
Greg Burghardt
  • 46.1k
  • 8
  • 87
  • 150

  • It is utterly not standard advice.

  • Splitting that code into its own class is not mandatory.

  • This advice is often given when dealing with a very large class, and splitting the class up makes the code easier to reason about.

    • And you can identify an abstraction that can be pulled out of that large class, which lives just fine on its own.

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").

  • It is utterly not standard advice.

  • Splitting that code into its own class is not mandatory.

  • This advice is often given when dealing with a very large class, and splitting the class up makes the code easier to reason about.

    • And you can 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").

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").

Source Link
Greg Burghardt
Greg Burghardt
  • 46.1k
  • 8
  • 87
  • 150

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.

  • It is utterly not standard advice.

  • Splitting that code into its own class is not mandatory.

  • This advice is often given when dealing with a very large class, and splitting the class up makes the code easier to reason about.

    • And you can 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?