I found an article by Martin Fowler that has made me doubt my design choices, particularly about data objects. Martin Fowler has written an article about what he thinks is a code smell.
In this article, he says:
The best smells are something that's easy to spot and most of time lead you to really interesting problems. Data classes (classes with all data and no behavior) are good examples of this. You look at them and ask yourself what behavior should be in this class. Then you start refactoring to move that behavior in there. Often simple questions and initial refactorings can be the vital step in turning anemic objects into something that really has class.
Now, on to my own use case of data classes/objects/DTOs/whatever. :-)
I am writing a set of classes that move credits from our company's sim to the sim of a recipient. This process has three stages:
Now, the items 2 and 3 are using a lot of data that is retrieved or initialized in stage 1: the event manager, the order and payment and transaction objects, and so on. What we do is the following:
data transfer object(
DTO). This object has only setters and getters.
processclass and the
post-processclass) accept the
DTOas their constructor argument and do their processing, event management, and data manipulation on those objects. In the end, those objects are persisted in the database.
Is the data object (or the data transfer object) not recommended here? Should we use another way for sharing data between these three classes?