RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Five Great Patterns for Dealing with References

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.

n a UML class model, classes are described by having attributes, operations, and relationships with other classes. When such a model is converted into code, both the public attributes and the relationships will appear as properties in your classes. These properties have types, which generally fall into one of the following categories:
  • Basic types. Simple properties such as FirstName, StartDate, or Limit have simple property types, such as string, datetime, or int.
  • Value types. Properties such as Email, ZIP, or CreditCard are a bit more sophisticated. Such properties tend to enforce validations on the possible values of properties, including regular expression and range checks. Therefore, types of such properties are described in value types, such as BankAccount, ZIP, or CreditCard.
  • Business class. Properties of classes that implement a relationship with another class in general have the type of that class, either representing a single instance or a collection of instances of the related class. A Project class, for instance, is likely to have a property Manager of type Employee.
  • Reference types. When the value of a property comes from a limited collection of values, the type of that property uses a reference type. There are several implementations for reference types, ranging from enumerated types, such as CourseLevel in a Course class to small referential classes, including a Country or Currencies class.

At first glimpse, enumerated types and referential classes appear to be to the most obvious patterns for implementing reference types, but there are other patterns that can do the job for you. This article includes five such patterns; I'll show you when each of these patterns is applicable and useful.

Each pattern is measured up against a number of criteria:

  • Type safety. When referring to the property involved, is this type safe? When the type of the property is passed as an argument in an operation, can only values from the limited collection be used? Is it possible to type check values in code, without making the code vulnerable to typing errors? For instance
       if (MyCourse.CourseLevel == CourseLevels.Expert) { … }
    is not really equivalent to
       if (MyCourse.CourseLevel == "Expert") { … }
    The second example relies on perfect user input in order to be validated. But eventually, someone will make a typo.
  • Collection of values. When developing a user interface, quite often all possible values from the collection of the property’s type need to be displayed, for instance in drop-down lists or radio buttons. How much programming effort is involved in retrieving all possible values for a certain reference type?
  • Display values. In some cases, it is desirable to display different values than the technical values that are used in your code. For instance, an enumeration CourseLevel might define a value VeryHigh, but this might appear on screen as Very high.
  • Flexibility. Can the values of the elements in the collection change without changing or breaking the code? Is the number of elements fixed or can new elements be added without endangering the application code?
  • Extending reference types. In some cases, it is useful to define a referential type, and than later be able to inherit from it and extend it with new values. Suppose you’re using a framework that uses a reference type Actions that contains all actions the framework is aware of. Developers might need to use both existing functionality as well additional Actions that aren't yet defined. They can get exactly what they need by extending Actions.
Now, let's look at a number of different patterns for dealing with references, and monitor how these patterns behave to the aforementioned criteria.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date