Object Creation

[ Team LiB ]

Object Creation FACTORIES and Constructors for Cargo Even if we have a fancy FACTORY for Cargo, or use another Cargo as the FACTORY, as in the "Repeat Business" scenario, we still have to have a primitive constructor. We would like the constructor to produce an object that fulfills its invariants or at least, in the case of an ENTITY, has its identity intact. Given these decisions, we might create a FACTORY method on Cargo such as this: public Cargo copyPrototype(String newTrackingID) Or we might make a method on a standalone FACTORY such as this: public Cargo newCargo(Cargo prototype, String newTrackingID) A standalone FACTORY could also encapsulate the process of obtaining a new (automatically generated) ID for a new Cargo, in which case it would need only one argument: public Cargo newCargo(Cargo prototype) The result returned from any of these FACTORIES would be the same: a Cargo with an empty Delivery History, and a null Delivery Specification. The two-way association between Cargo and Delivery History means that neither Cargo nor Delivery History is complete without pointing to its counterpart, so they must be created together. Remember that Cargo is the root of the AGGREGATE that includes Delivery History. Therefore, we can allow Cargo's constructor or FACTORY to create a Delivery History. The Delivery History constructor will take a Cargo as an argument. The result would be something like this: public Cargo(String id) { trackingID = id; deliveryHistory = new DeliveryHistory(this); customerRoles = new HashMap(); } The result is a new Cargo with a new Delivery History that points back to the Cargo. The Delivery History constructor is used exclusively by its AGGREGATE root, namely Cargo, so that the composition of Cargo is encapsulated. Adding a Handling Event Each time the cargo is handled in the real world, some user will enter a Handling Event using the Incident Logging Application. Every class must have primitive constructors. Because the Handling Event is an ENTITY, all attributes that define its identity must be passed to the constructor. As discussed previously, the Handling Event is uniquely identified by the combination of the ID of its Cargo, the completion time, and the event type. The only other attribute of Handling Event is the association to a Carrier Movement, which some types of Handling Events don't even have. A basic constructor that creates a valid Handling Event would be: public HandlingEvent(Cargo c, String eventType, Date timeStamp) { handled = c; type = eventType; completionTime = timeStamp; } Nonidentifying attributes of an ENTITY can usually be added later. In this case, all attributes of the Handling Event are going to be set in the initial transaction and never altered (except possibly for correcting a data-entry error), so it could be convenient, and make client code more expressive, to add a simple FACTORY METHOD to Handling Event for each event type, taking all the necessary arguments. For example, a "loading event" does involve a Carrier Movement: public static HandlingEvent newLoading( Cargo c, CarrierMovement loadedOnto, Date timeStamp) { HandlingEvent result = new HandlingEvent(c, LOADING_EVENT, timeStamp); result.setCarrierMovement(loadedOnto); return result; } The Handling Event in the model is an abstraction that might encapsulate a variety of specialized Handling Event classes, ranging from loading and unloading to sealing, storing, and other activities not related to Carriers. They might be implemented as multiple subclasses or have complicated initialization�or both. By adding FACTORY METHODS to the base class (Handling Event) for each type, instance creation is abstracted, freeing the client from knowledge of the implementation. The FACTORY is responsible for knowing what class was to be instantiated and how it should be initialized. Unfortunately, the story isn't quite that simple. The cycle of references, from Cargo to Delivery History to History Event and back to Cargo, complicates instance creation. The Delivery History holds a collection of Handling Events relevant to its Cargo, and the new object must be added to this collection as part of the transaction. If this back-pointer were not created, the objects would be inconsistent. Figure 7.5. Adding a Handling Event requires inserting it into a Delivery History. Creation of the back-pointer could be encapsulated in the FACTORY (and kept in the domain layer where it belongs), but now we'll look at an alternative design that eliminates this awkward interaction altogether.

[ Team LiB ]