Applying Data Access Patterns

Reading and understanding patterns exposes you to ideas that may find a place in your own software designs. Applying data access patterns involves several skills. The most important skill is being able to identify an appropriate pattern when an applicable problem arises. In some cases, problems match pattern descriptions exactly and obviously. Others require a certain amount of creativity to notice that a pattern may be specialized in ways other than what the examples in the text describe. Nearly as important is being able to identify when a chosen pattern does not apply to a given design problem. Inappropriate patterns can convolute your design and might force you to build awkward constructs that compromise your design goals.

Practice and a willingness to try and discard solutions are the best ways to attain these skills. Here are some general items to consider as you apply patterns:

• Be familiar with the patterns— Read the pattern descriptions enough to understand what each pattern offers. You will not be able to apply a pattern with just this information. However, having a basic familiarity may remind you to investigate certain patterns in more detail when an applicable design or optimization problem presents itself.

• Refer to patterns in design and code documentation— A great advantage of documenting patterns is defining reusable nomenclature. Documented patterns give names to general and proven ideas. Refer to any patterns that you apply in your design and code documentation. This gives the reader a place to look to understand your design at a broader level and also saves you from explaining your design in detail.

• Change entity names to match your domain— Consider the class, interface, and operation names that patterns describe to be placeholders rather than final names. As you apply a pattern, replace its entity names with those that match your domain. Your code will make more sense to casual readers who are unfamiliar with the pattern.

• Take liberties with the patterns— Patterns describe abstract design ideas that have broad application. If a pattern solves a particular problem for you, but does not directly fit into your existing design, then change it. Even if you use parts of a pattern or change its structure or interaction, it still adds value to your application, and it is still worth documenting. It is always better to keep your design clean than to strictly adhere to a pattern.

• Do not constrain your design— Patterns are not a panacea for software design. Pattern catalogs collect and document related patterns, but they are by no means a totality of all solutions. Use patterns when they benefit your design, but do not constrain your design to the exclusive use of patterns.

• Invent your own patterns— As you practice applying patterns to design and optimization problems, you may also begin to identify abstract solutions of your own. Take the time to document these as patterns using a form of your choice and refer to them in your design documentation. You can expand on your own patterns in one place and refer to them elsewhere. When you only have one place to document patterns, you are more likely to take the time to explain their concepts in detail.