An Example of Hollow Objects

Let’s use the travel expense accounting system again with these classes: Employee, Travel, and Receipt. The employees travel around the world. During each trip they generate a certain amount of expenses. Let’s assume a company with 50 employees. In average each of them has made 50 trips and received 10 receipts per trip. If you now make a query for a certain employee, it is rather unlikely that you also need to access all his/her travels and receipts. Nevertheless without the concept of hollow objects (or lazy loading) checking a single employee object would cause loading 50 travel and 500 receipt objects.

After the query the employee object is in the hollow state if the parameter hollow is not set to false at the creation of the Query object. If a field of the object is accessed, for example FirstName, then NDO loads the data – the object has the state Persistent.

The first time, the field travels is used, NDO loads the Travel child objects, which have the hollow state.

Let’s assume the field purpose of one of the travel objects is accessed. The object data are loaded by NDO and the object state switches from Hollow to Persistent.

Touching the field expenses of a Travel object causes the child objects to be loaded as hollow objects.

If a field of one of the Expense objects is accessed, for example the field text, the Receipt object is loaded.

Instead of 551 only 3 complete and 6 hollow objects were loaded during the procedure up to now. That saves a lot of memory and therefore makes applications faster.