Keeping the classes clean

As part of my ongoing effort to solve NARC-11 Stop using the JMS queues for queuing snapshot harvests I've run into the HarvestDefinition class, and I'm a bit confused about what this classes purpose is. The name of the class and the first part of the class description implies this a clean data entity, but the last part of the description and the implementing code contains functionality for generation Job objects based on the HarvestDefinition and write these job to the database. This set of extra 'useful' functionality might seem like a good idea, but the problem is that responsibility of the HarvestDefinition class isn't any longer clearly defined.

One of the very most efficient ways to lose control of your OO design, is to muddle the responsibilities of the components/classes making up your system. In OO, classes are meant to function as logical partitions of the different problem areas of the system, enabling us to reduce the system complexity and allow developers to focus on small isolated sections of code when manipulating the code. The responsibilities of a class can be categorized into two disjunct sets:

• Business domain responsibilities: In the case of the NetarchiveSuite system examples would be HarvestDefinitions, HarvestJob, BatchJobs, Indexes, Archives etc. Here the class properly started out as a pure harvest definition data object, but was somewhere down the road extended to also know about HarvestJobs which should be distinct data object compared to HarvestDefinitions.
• Software domain responsibilities: This might be database access, communication, mapping, gui, model entity, etc.: In the case of the HarvestDefinition it properly started out as a plain model entity class, but was again a some point bloated with a functionality for mapping harvestdefinitions to HarvestJobs and database access for updating the persistent model.

Have a look at the Monster object antipattern or God object antipattern for further discussions on what to look for.