Tip use of child classes versus references

This page completes the class definitions page posted in this section. A class must include only child classes when the linked data is updated at the same time.

When a complex document is defined as a class that refers to a set of additional classes, the developer might have the temptation to include these classes as child classes. The result is a huge class that takes a lot of resources when loaded.

First wrong example

Let's have an example based on a sales order:

• A sales order has a header, lines, and possibly sub-lines. These sub-classes are managed globally: it is usually impossible to create a line that is not attached to a header.
• A sales order refers to a customer, and the sales order line refers to products. They must not been described as child classes because a customer can be created without having to create an order, and a product can be created without having to create an order line.
• The customer can embed addresses as child classes because the creation of an address can be in some implementations linked to the creation of the customer.
• every address refers to a country.

If we wrongly consider that all these classes are nested child classes, reading a sales order class will load:

• N instances of lines.
• The instance of customer with an array of addresses instances linked to country instances, a payment term instance, a default sales rep instance ...
• N instances of products (linked to the lines), sales rep (linked to the lines), every product instance linked to an array of unit instances, to another unit instance (the unit found on the line)...

With this simple wrong method, if we consider a 10 lines sales order (2 sub-lines per line) for a customer having 3 addresses, 2 sales rep having 2 addresses each, and products available in 3 units:

• 1 sales order instance.
• 10 line instances.
• 20 sub-lines instances.
• 10 product instances.
• 30 units instances.
• 1 customer instance.
• 10+1 sales rep instances.
• 25 addresses instances.
• 25 country instances.

... and of course much more if we consider all the "small additional entities linked to the main entity. This gives an "octopus class" that takes a long time to download and to handle, with no benefit.

The right design is to consider that the only child instances of the sales orders are the sales order lines, and the sub-lines. All the other properties linked to a class are references: their data type is associated to a class, but no embedded child class exists in the main class for them.

Using references rather than embedded classes will allow to load only the sales order, lines, sub-lines instances. If at a given moment, the access to a reference data is needed, it will be easily possible to use an operation with the reference key as parameter.

Second wrong example

A more insidious example would be an entity that refers itself, either directly (the conflict is easy to detect) or indirectly.

First direct example: an item class refers to a replacement item class. If this is implemented as a child class, we will have an infinite nesting of items...

Second example : an item class has two collections of children classes : item/customer, and item/supplier.
On every item/supplier class there is a reference to suppliers. When loading the supplier class, it might be interesting to have a list of references on the items supplied. Once again, if these references are managed as embedded classes, we will have an infinite nesting of classes.

Conclusion

Use references rather than child classes when the instances can be created autonomously.