I have a QueueProcessor class that processes a work queue. I want to send an email out of a summary of all work done with a bunch of statistics. I am already using a mail class (Zend_Mail), so most of the email work is abstracted away for me, but I still have to figure out where to put the code to generate the summary information. I’m basically collecting data during the processing and then I have to transform the data into a format suitable for email.
My question is, should I create a separate class called QueueProcessorSummaryEmail, or is that considered bad design since it’s extremely tightly coupled to the original class? If I did make it it’s own class, I’d have to pass a ton of data to it for it to generate the email, but it’d be nice to have that kind of separation. If I don’t make it a class, all the data is available from inside the QueueProcessor class, but it just feels weird mixing the processing logic and the reporting generating logic in one class.
And for the record, when I say “report generating logic”, I don’t mean I’m generating HTML inline; I’m using a view for that. By formatting I mean taking the data and aggregating it into something usable by the email report.
Ryeguy,
My suggestion would be to create a decorator class (like say SummarizedQueryProcessor) to extend the functionality of the QueueProcessor. This will allow for a higher degree of separation of concerns and will simplify unit testing.
Ted