Five Great Patterns for Dealing with References : Page 5

In the old days, when applications primarily consisted of a number of windows and a database, using reference data was still easy. You would create a reference table and refer to it from your main tables. Nowadays, in object-oriented environments, where your business logic is key, there are more alternatives for dealing with references.

by Sander Hoogendoorn

May 26, 2005

Page 5 of 5

When to Use Which Pattern?
Using references is inevitable when using business classes. However, there a lot of different implementations, all of which are variations or extensions to one of the five patterns mentioned above. The big issue is when to use which pattern. Table 1 sums up the characteristics for each of the patterns using the criteria defined earlier.

Table 1. Characteristics of each of five different patterns and their key criteria.

	Type safety	Collections of values	Display values	Flexibility	Extensibility (inheritance)
Enumeration	Yes	Yes	Limited to enumerated values	Fixed, change of code required	No
Constant collection	Not when used as parameter	Yes, using reflection	Limited to defined values	Fixed, change of code required	Yes
Descriptor	Yes	Yes, using reflection	Yes	Fixed, change of code required	Yes
Small business class	Yes, when defining static instances	Yes, easily retrieved from database	Any combination of its fields	Flexible, alter dedicated table	Yes
Smart reference	No, anonymous	Yes, easily retrieved from database	Any combination of its fields	Flexible, alter single table	Yes

The first three patterns are best in situations where a limited and fixed number of elements are expected. The three patterns mainly differ in that different display values can be used or where extensibility by inheritance is required. The last two patterns are best used in situations where there is a large collection of elements, and this collection is unlikely to change more often than the code is put in production. This requires the elements to be stored externally, rather than being hard coded, most commonly in a database.

Together, these five patterns, and the numerous variations and extensions to them, will give you control over the references you need to deal with in your projects.

Sander Hoogendoorn is a Partner with Ordina, a large software consultancy company in the Netherlands. He is specialized in modern software development, from software development methods, object orientation, UML, component-based development, and software architectures including Java and .NET. Sander is a member of the advisory board for Software Release Magazine and writes a monthly column for SDN Magazine. He speaks frequently at seminars and conferences in Europe, and his book 'Pragmatic modeling with UML 2.0' (in Dutch) was published by Addison Wesley in 2004. (www.sanderhoogendoorn.com)

« Previous Page 1 2 3 45