name of class that manipulates the entities

Question

hi,

i have a general question regarding naming convention.

if I separate the data and operations into two separate classes. one has the data elements (entity), the other class manipulates the entity class. what do we usually call that class that manipulates the entity class?

(the entity I am referring to has nothing to do with any kind of entity framework)

manager? controller? operator? manipulator?

thanks in advance

Answer 1

I separate the data and operations into two separate classes.

Don’t. This flies in the face of object-oriented design.

Answer 2

I usually go with Manager.

Answer 3

Call it whatever you are comfortable with, just make sure you use that name consistently throughout your project. The closest thing we have is a Capability or a Receiver but even then these aren't quite what you're talking about.

However.

Do you have a specific reason for separating the data from the methods? Unless you talking about a class and its factory I'd be really surprised if this separation is truly warranted.

Answer 4

It depends on what kind of operations you're doing on those data contracts/entities. Here are some of my conventions. Let's use the example of a Fruit entity (and I'm not trying to imply these are all static methods, just pseudocode):

• Repository: provides CRUD operations on a piece of fruit
  • FruitRepository.Save(Fruit item);
• Manager: operations outside of simple CRUD.
  
  • InventoryManager.ShipFruit(Fruit[] items, string address);
• Controller: reserved for use in the interface, as in Model-View-Controller. Makes interface or flow decisions how to display or operate on fruit.
  • FruitController.ShowDetails(string fruitId);
• Processor: used on operations that are "batched" together. Often these are long-running or done offline.
  
  • FruitProcessor.RemoveSeeds(Fruit[] lotsOfFruit);
• Manipulator: provides specific operations on a single entity or a collection of them.
  
  • FruitManipulator.PeelFruit(Fruit item);
• Provider: provide more generalized or global operations.
  • FruitProvider.GetAllTypesOfFruit();
  • FruitProvider.IsInSeason(string fruitName);
• Exporter: Convert some fruit into a format intended for file storage or perhaps transfer.
  • FruitExporter.Save(string spreadsheet);
• Analyzer: Provides results about an individual piece of fruit or a quantity.
  • FruitAnalyzer.Weigh(Fruit[] items);
• Service: exposes functionality in a loosely coupled or remotely accessible kind of way.
• Assembler: Creates fruit by combining different data sources.
  • FruitAssembler.Combine(string speciesFile, string quantitiesFile);
• Factory: responsible for creating/instantiating fruit.
  • FruitFactory.CreateApple(); // red delicious, McIntosh, etc
• Builder: Provides a way to build up fruit by individual parts/properties.
  
  • FruitBuilder.AddSeeds(5); FruitBuilder.AddStem();

These are all somewhat loose. The main goal is to stay consistent within your own codebase and avoid conflicts with the technologies you're using-- ie. don't have a lot of Controller classes that aren't controllers if you're doing ASP.NET MVC.

Answer 5

Let's reason like following:

• If the logic uses only one entity, move it to the entity itself (See rich domain model vs. anemic domain model).

• So most of these classes are those which implement logic which deal with more than one entity, hence represent a collaboration.

Such class should not be named according to their responsibility. A technical term such as manager, controller, manipulator, etc. can still be use for naming convention, but the important part is first part of the name.

Example:

• Entities: Product and Customer
• Collaboration between the two: PurchaseService <-- what's important is Purchase, not Service