operations with data or not

[Don Kiddick]

How do you decide whether to put an operation on the class that contains the data or on a seperate class that processes the class that the data is in? OO theory tells us that behaviour and data should be kept together, but some patterns such as MVC, explicitly seperate them.

For example, I want to turn my Customer instances into XML so I can send them to another system which understands XML. Do I go for :

 String xml = customer.toXml(); 

or

 String xml = xmlTranslator.translate(customer); 

and what heuristics do you use to make your choice ?

I've been thinking about this recently and I tend to use what "feels right". I wondered if anyone has any insights into this choice.

thanks, D.

[Mark Spritzler]

Responsibility. that is the question that I use to determine what goes into one class and what does not and should be in a seperate class. So in your case of Customer and XML, is it the Customer's responsibility to produce XML? It is your customer's responsibility to give its name, address, creditcard number, and pay. But most customer's know nothing about XML, so that is why a seperate class would take the Customer, ask it for the information that it knows, and produce XML on its behalf.

Does that help?

Mark

[Ilja Preuss]

To extend on what Mark said, the Single Responsibility Principle is the driving force here. It states that a class should only have one reason to change.

In your example, putting the XML generation on the Customer class is likely to violate the SRP - the Customer class would then need to change not only when the business rules for Customers change, but also when the XML format changes. It would also raise the question what you do if you needed other persistence mechanism - JDBC, for example.

On the other hand, the SRP is not a hard and fast rule - if only because the notion of "one reason to change" isn't really well defined. Often I find that things that at first looked like they belong onto the class really needed to be changed for reasons that I didn't anticipate. I take that as an opportunity to learn something and to improve the design, by extracting the functionality in that moment (that is, by refactoring the design to the current needs).

So lastly it actually comes down to gut feel, guided by past experience.

[Don Kiddick]

Thanks Mark & Ilja, that helps a lot.
D.