Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX

Waiting for the Perfect API
Architectural Overview of Oracle ADF
The Agile Architecture Mind Map
Agile Architecture Step #1: Clean Up Your Mess
Automating HATEOAS Declaratively: REST’s Missing Link

advertisement
 

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 25, 2005
Page 5 of 5
advertisement
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 12345  
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

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