Reputation: 133
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
Upvotes: 12
Views: 5083
Reputation: 38635
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:
Upvotes: 1
Reputation: 2242
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):
FruitRepository.Save(Fruit item);
InventoryManager.ShipFruit(Fruit[] items, string address);
FruitController.ShowDetails(string fruitId);
FruitProcessor.RemoveSeeds(Fruit[] lotsOfFruit);
FruitManipulator.PeelFruit(Fruit item);
FruitProvider.GetAllTypesOfFruit();
FruitProvider.IsInSeason(string fruitName);
FruitExporter.Save(string spreadsheet);
FruitAnalyzer.Weigh(Fruit[] items);
FruitAssembler.Combine(string speciesFile, string quantitiesFile);
FruitFactory.CreateApple(); // red delicious, McIntosh, etc
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.
Upvotes: 46
Reputation: 7759
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.
Upvotes: 1
Reputation: 546143
I separate the data and operations into two separate classes.
Don’t. This flies in the face of object-oriented design.
Upvotes: 0