...
| Code Block |
|---|
PersonName personName = new PersonName("David", "Lee", "Roth");
String kerbName = "dlr";
String emailAddress = kerbName + "@mit.edu";
int pidm = 12212871;
int mitId = 90002312;
Student student = new Student(String.valueOf(pidm), String.valueOf(mitId), kerbName,
personName, emailAddress);
Calendar now = Calendar.getInstance();
student.setCitizenship(new Citizenship("US", "United States"));
student.setEthnicity(new StudentEthnicity());
Calendar birthDate = Calendar.getInstance();
birthDate.set(Calendar.YEAR, birthDate.get(Calendar.YEAR) - 20); // Born 20 years ago
student.setBirthDate(birthDate.getTime());
student.setDeceased(false);
student.setGender(Gender.FEMALE);
student.setStudentHolds(new ArrayList<StudentHold>());
student.setVersion(1l);
student.setCreateBy("testuser");
student.setCreateDate(now.getTime());
student.setModifyBy("testuser2");
student.setModifyDate(now.getTime());
// Enrollment profile:
Set enrollProfiles = new HashSet();
// ... more code that builds enrollment profile objects...
student.setStudentEnrollProfiles(enrollProfiles);
|
...
Here's a screenshot showing the Javadoc for the Core Data Factory class.
Does the Core Data Factory Satisfy the Goals?
Here's how I think the factory prototype satisfies the goals:
- Make the framework simple and easy to use
Once you have an instance of CoreDataFactory, getting a stucb Student object is a single method call.
- Keep the interfaces uncluttered
Taking student as an example, there are two build options: one that takes no arguments, one that takes a single termCode argument. We could have created a longer arg list for finer grained customization, but it seems better to keep the interface short and simple. If a unit test needs to tweak the data, it can do that after getting the student object.
- Provide the basics that should be good enough for most tests, but allow the flexibility for unit tests to tweak the data if necessary.