Step 3: Create a record generator

Since records are represent by Java Beans, a more accurate name for a record generator might be "BeanGenerator". Since we'll be distinguishing two processes during data synthesis, creation and modification, an even more accurate name would be BeanCreator, which is the name used in the source code.

A bean creator is essentially a collection of field generators. Typically, it is implemented as a managed map of field names to field generators, but the interface is actually much simpler than this. The interface for a record generator has just one method, createBean(T), which is parameterized by T, the type of record being generated.

package net.sf.adatagenerator.api;

public interface BeanCreator<T> {

        T createBean(T template) throws CreationException, ModificationException;

}

In our case, we'll be creating records of type GeneratedCdc1Record. We won't implement the BeanCreator interface directly, but rather we'll build on the base class AbstractBeanCreator, which does most of the work of managing a map of field names to field generators for us. The abstract class defines a simple lifecycle for generators:

• NOT_BUILT

  The generator is constructed but not initialized.

• BUILDING

  The generator is being initialized.

• BUILT

  The generator is ready for use.

A subclass of AbstractBeanCreator has to implement just one method, buildGeneratorMapInternal, which is a protected method that is called when a bean creator is being initialized. The method has one input parameter, which is an instance of a <<<FieldDependencyManager. A FieldDependencyManager is used by field generators to declare any dependencies that they have on one another. After a subclass has used a FieldDependencyManager instance to build its internal map of field generators, the AbstractBeanCreator base class uses the FieldDependencyManager instance to determine the order in which field generators will be invoked when record values are being created. In this initial implementation of a CDC data generator, there are no dependencies between field values; later on, in a more sophisticed implementation, there might be dependecies between the first name fields and gender, or between the vaccination date and the date of birth.

package net.sf.adatagenerator.ex.cdc1.bean;

import net.sf.adatagenerator.api.CreationException;
import net.sf.adatagenerator.api.FieldDependencyManager;
import net.sf.adatagenerator.api.ProcessingException;
import net.sf.adatagenerator.core.AbstractGeneratorMap;
import net.sf.adatagenerator.ex.cdc1.api.GeneratedCdc1Record;
import net.sf.adatagenerator.ex.cdc1.util.Util;

public class Cdc1GeneratorMap extends AbstractGeneratorMap<GeneratedCdc1Record> {

        public Cdc1GeneratorMap() throws ProcessingException {
                super();
        }

        @Override
        protected void buildGeneratorMapInternal(
                        FieldDependencyManager<GeneratedCdc1Record> fdm)
                        throws CreationException {
                map(Util.createDOBGenerator(fdm));
                map(Util.createFirstNameGenerator(fdm));
                map(Util.createLastNameGenerator(fdm));
                map(Util.createMiddleNameGenerator(fdm));
                map(Util.createMomFirstGenerator(fdm));
                map(Util.createMomLastGenerator(fdm));
                map(Util.createMomMaidenGenerator(fdm));
                map(Util.createMomMiddleGenerator(fdm));
                map(Util.createSexGenerator(fdm));
                map(Util.createSuffixGenerator(fdm));
                map(Util.createVacCodeGenerator(fdm));
                map(Util.createVacDateGenerator(fdm));
                map(Util.createVacMfrGenerator(fdm));
                map(Util.createVacNameGenerator(fdm));
        }

}