3 Answers
3

If a class is properly encapsulated it's hard to tell if it even has fields from outside.

Some classes are immutable. You can't change their fields once their objects are constructed. Your class is also immutable. But not only can't its object change, you only have one way to build it.

That doesn't mean you have to think of the whole thing as a verb. It can still be a noun. It's just a noun that comes in only one flavor.

What you have is a bag of functions that move around together. If your class is properly designed those functions have something to do with each other. That single unifying idea that brought them together should give the class it's name. The name should make clear what functions belong in the class and what functions don't. If people read the name and then are surprised by what they find inside then you have a bad name.

When I find myself in this situation, I take a step back and think about how I am going to call the methods. Forget nouns vs. verbs for a minute. Then I play fill-in-the-blank and go with what sounds most natural.

___________.saveSync()

dataManager.saveSync()?

saveHelper.saveSync()?

entityRepository.saveSync()?

In some cases I don't even name the class until after I have called it from a few places. Call it NewClass1234 until you can see it being called in context, and then read the code aloud while trying different names.

You could also show the code to a coworker and ask for suggestions. I try to reduce the amount of time coworkers will puzzle over my naming, so getting that feedback upfront can help.