I found an article by Martin Fouler that has made me doubt my design choices, particularly about data objects. Martin Fouler 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:

1. Validation: at this stage, the data is validated – have we moved credits to this person's account before? Have we handled this item before? Can we retry, or have we reached the "manual mode" threshold?
2. Process: at this stage, we do the actual work of moving the credits from one account to the other. We use the objects retrieved in the validation phase, to lower the number of queries to the database, and also to improve our application's performance.
3. Post-process: at this point, we check the data and if the data must be auto-corrected (I.E. the user has entered wrong information and we know how to automatically fix it), we mark it for autocorrection.

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:

1. The validation object stores all of its retrieved data that is useful to the rest of the process in a data transfer object (DTO). This object has only setters and getters.
2. The rest of the classes (the process class and the post-process class) accept the DTO as 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?

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:

1. Validation: at this stage, the data is validated – have we moved credits to this person's account before? Have we handled this item before? Can we retry, or have we reached the "manual mode" threshold?
2. Process: at this stage, we do the actual work of moving the credits from one account to the other. We use the objects retrieved in the validation phase, to lower the number of queries to the database, and also to improve our application's performance.
3. Post-process: at this point, we check the data and if the data must be auto-corrected (I.E. the user has entered wrong information and we know how to automatically fix it), we mark it for autocorrection.

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:

1. The validation object stores all of its retrieved data that is useful to the rest of the process in a data transfer object (DTO). This object has only setters and getters.
2. The rest of the classes (the process class and the post-process class) accept the DTO as 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?