Crystallitis

Design Pattern Essentials

September 26th, 2008 12:20 am · No Comments

I spent the day in class with Steve Tocky and roughly twenty others, absorbing and sharing knowledge. It has been a long time since I’ve been in a classroom environment. Too long. I regret having missed the opportunity in previous companies. I decided on this course as I have only recently started reading up on and consciously applying Design Patterns. I want to better be able to identify problems to which specific patterns would succeed and others fail.

The morning started with an introduction to design patterns and their surrounding terminology. We looked at patterns in other disciplines, specifically, civil engineering and their use to build bridges. We discussed “forces” that determine when a specific pattern should or should not be applied. We skipped over the UML slides after everyone agreed their understanding was solid enough. Then we got into the juicy stuff, the design principles.

We spent a good chunk of the day discussing several important fundamental design principles. One of the most important roles of a software developer on the overall software solution, in addition to being a fundamental design principle, is to minimizing complexity. Steve has introduced me to two more ways of analyzing and measuring code for its complexity that have completely blown me away - Cyclomatic Complexity Analysis and Fan-out.

Cyclomatic Complexity Analasis measures the number of linearly independent paths through a program’s source code. Cyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to the commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. The concept is similar to the Flesch-Kincaid Readability Test in which a passage of English text is measured for complexity. Fan-out measures the number of other classes a given source file relies on. The square of its value has been shown to indicate the amount of maintenance required in functional programs.

I’ve always found complexity analysis so interesting, yet I’ve done so little to really investigate it and measure it, other than the obvious Big-O Analysis and other simpler measures of complexity. There’s so much out there to learn; so little time to learn it.

Following the discussion of design principles we spent quite a bit of time on the Model-View-Controller “pattern” (then the Model-View-Controller-Infrastructure “pattern”), before getting into Adapter, Facade and Bridge patterns. I’m not keen on using the Adapter pattern, but I was able to ask a few questions regarding our own design in place of the Adapter pattern and had many questions answered. I haven’t used a Facade, but I have used the Bridge pattern. We’ll try to cover a bigger chunk of patterns tomorrow.

I ate lunch with a project manager from Blue Nile (Neil and I purchased our wedding bands from BN) and have enjoyed the comic relief from the WebMD crew. There is a pretty clever guy from Boeing and a few other interesting individuals. That definitely helps to pass the time. The class ended with a sampling of brewmaster Steve Tockey’s home brew along with some wine and cheese. A perfect way to end the day! Construx has a “kegerator” in their staff room - a modified refrigerator with three beer taps. Of course, no American/Canadian interaction is complete without a few Canadian digs - an “eh” here and a “pass-the-bud” there. Don’t worry, I dug back!

Tags: construx · design patterns · technology

0 responses so far ↓

  • Be the first to comment below.

Leave a Comment