File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Domain object construction Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Domain object construction" Watch "Domain object construction" New topic
Author

Domain object construction

Ben Narendren
Greenhorn

Joined: Oct 01, 2009
Posts: 19
I have a HotelManager which will call two external services to create a AvailableHotel domain object.

1) HotelManager calls HotalAvailabilityDelegate
2) HotelAvailabilityDelegate connects to the external service, gets the data and creates a AvailableHotel domain object and returns it to HotelManager
3) HotelManager calls HotelAmenitiesDelegate
4) HotelAmenities delegate calls an external service and returns a HotelAmenitiesResponse
5) HotelAmenitiesResponse is used to fill in the rest of the data in AvailableHotel object by making a call like AvailableHote.populateAmenities(HotelAmenitiesResponse).

My problem is that the first time when HotelAvailabilityDelegate returns AvailableHotel, its a partial object in the sense that it doesn't have any Amenities info in it. Is this good design?

I thought of having HotelAvailabilityDelegate return a HotelAvailabilityReponse and creating the AvailableHotel object in the HotelManager itself. But the problem is I don't want to create an additonal object called HotelAvailabilityReponse just for data transfer.

Any thoughts anyone?
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
My problem is that the first time when HotelAvailabilityDelegate returns AvailableHotel, its a partial object in the sense that it doesn't have any Amenities info in it. Is this good design?


There really is no way to identify if your design is good without the actual business requirements.

I thought of having HotelAvailabilityDelegate return a HotelAvailabilityReponse and creating the AvailableHotel object in the HotelManager itself. But the problem is I don't want to create an additonal object called HotelAvailabilityReponse just for data transfer.


Why don't you want to create a data object?
Ben Narendren
Greenhorn

Joined: Oct 01, 2009
Posts: 19
I am creating a data/domain object - AvaiableHotel. I don't want to create an intermediate data transfer object to get the data back from the external service delegate.

Myl question here is: Is it good design that the first delegate returns a partial domain object (without the Amenities info) and the second delegate fills in the rest of the data (Amenities info) on that domain object ?
Arnold Reuser
Ranch Hand

Joined: Nov 20, 2003
Posts: 196
Your design is surely not lacking. But some improvements could be made.

* If the HotelManager is an actor. Then the flow is actually a conversation, maybe even covering a complete use case, of the HotelManager with the system.
A Session Facade could be used to implement this conversation and expose a coarse grained interface to the HotelManager.
Just to emphasize this a bit more. The Session Facade would call the HotelAvailabilityDelegate and HotelAmenitiesDelegate as part of this conversation.
The HotelManager will, as a result of this, not be exposed to the internal details and the partial domain object.

There are several approaches related to your question of the partial domain object.
One is by using Transfer Objects and the second is by used the State pattern.
About the Transfer Objects :
* If both HotalAvailabilityDelegate and HotelAmenitiesDelegate are communication by using Transfer Objects instead of a partial Domain Object AvailableHotel
These Transfer Objects could be used, at the end of the conversation, to assemble and return the complete AvailableHotel domain object.

About the State pattern :
* If you would like to keep using the Domain Object instead of the using intermediate Transfer Objects.
By introducing state, as part of the domain object, you could alter the behavior of the domain object when it's internal state changes.
So if you view the converstation as a workflow with a set of states. These states could be used to determine the state of the Domain Object.
Based on the state of the Domain Object you could alter it's behavior e.g. throw IllegalStateException for public methods of the Domain Object
that can't be executed because the Domain Objects is incomplete.

My preference would be by using Transfer Objects or by simply accepting that partial Domain Objects exist.
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
An object is an object. If none of its data variables are populated, it is still an object. An object is a temporary concept. You shouldn't worry too much about the data that is not populated, if it is not needed at a specific point in time in the execution path. If it is needed and is not present, this is a problem. If it is not needed and will be populated in the next few milliseconds by another object, then this is fine if it works.

Aside, having the word "Hotel" in all of the Class names is extremely confusing and could easily be considered "poor" design.
Ben Narendren
Greenhorn

Joined: Oct 01, 2009
Posts: 19
Arnold and Jimmy, Thank you so much for your wonderful input.

I guess for now I can live with partial objects (bcos since both of you assured me that this is not poor design). DTO's are out of the question since there are DTOs and VOs involved at the external service level and at the view level correspondingly bcos of some restrictions we have and I don't want to add another layer of DTOs . So I guess if I have problems in the future with partial state, I'd go ahead and throw the IllegalStateException. That was an excellent idea btw, Arnold

Thanks
Ben
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
Sounds good. Your perception of "partial objects" is a bit awkward. An object is "complete" even if none of its data members are populated with "values." Actually, an object's data members always have values. For object data members, they are populated with null values and primitive data members are populated with their default values. So, once an object is created by the JRE it is complete.

However, this is a trivial point and if it helps you to understand it better, this is fine.

Good luck son!
Arnold Reuser
Ranch Hand

Joined: Nov 20, 2003
Posts: 196
If you would like to keep using partial domain objects and are thinking about using the state pattern approach.
You can, as stated before, throw IllegalStateException for public methods of the Domain Object that can't be executed because the Domain Objects is incomplete.
And to add another application of using this state pattern approach :

You could also validate whether a partial domain object is sane from the perspective of the state that it is in.
A sanity check could be executed on both the field and oject level during construction and modifiation of the object.
How to implement this sanity check is up to you. You could implement it as part of the domain object, externalize and add it during construction of the oject, wire it by using AOP, ...
As long as you harness your object you will do fine.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Domain object construction