Wednesday, January 30, 2008

Design patterns

The benefit of design patterns is in a facility to communicate a complete idea without changing the course of the conversation to dive into a tangent.  They're touch stones.

One problem with design patterns is in their naming.  We use different names and we forget their names.  It's easy to do.

However, the main problem with design patterns is getting locked into their specification before the correctness of the choice can be validated.  Sometimes the problem and solution are simple enough that the question of applicability can be answered mentally. 

However in most cases, the subject and its containing system are complex enough that some consideration is in order for the benefit of minimizing project risk.

An analysis reviews an interface or library to consider the essential attributes of its fit value. 

An experiment goes down the road of using an interface and library to discover its actual fit value. 

The speed with which the analysis or experiment can be performed, and the quality of their predictions with respect to project success and risk, are elements of experience.  Experience knows that an interface or library that overtly fits the problem may have broader implications for the success or maintainability or interoperability of the system.

It's not because we want to be able to reason about and compose systems in a singular thought process that we can make it so by using the patterns and APIs in mind.  Building software systems simply remains harder work than that these days.

No comments: