atomic flyswatters

I started Freeman and Freeman’s “Head First Design Patterns” from O’Reilly Press. The book is not about systems analysis, but program design, but I thought I’d write about it anyway. I have Gamma et al Design Patterns book. My pattern with most technical books is I buy them, read a couple of chapters and then stuff them on the shelf. The primary reason is that I’m lazy but also, technical books are hard to read. Also, I usually need to read about one very specific bit for a problem at hand. Design patterns are code templates: “best practice” ways of solving common problems. As such, you need to have them squirreled away in the back your head so your current problem looks familiar–like a pattern. Then you can go back to the Gang of Four Design Pattern book for the details.

I used to keep the diagram of the GOF patterns on my cubicle partition. Not that I looked at it. I haven’t programmed for the last five years as I concentrated on analysis. Still, analysis requires a working knowledge of programming and the nut of programming is design. The Head First book looked like a good way to refresh my understanding of the GOF patterns.

–At this in time I recommend programmers have both books–

I read about the first pattern and I thought, All that for a marginally easier way to change which code gets invoked for a particular instance? Do systems really change that much? Now mind, my concerns are with core functionality of a system, not the presentation layer. Just thinking of all the widgets on a browser page makes me think the Strategy Pattern could be a good thing for them. But it seems like wretched excess for the core system, which should be rather stable.

I am also reading the Eric Raymond’s “Art of Unix Programming” which also seems somewhat hesitant of the virtues of the object-orientation. [I may have completely misread all of these books, I do that a lot.]

In general MY overarching pattern is ‘Make it as simple as possible (and no simplier)’ Because it will be complex enough on its own. You shouldn’t make too many allowances for change because change tends to come in ways you never saw coming. At least that happened to me, at lot.

The Head First book knows that and does not recommend jumping into the Strategy Pattern because you can but because you discover a need for it.

To tie this back to systems analysis, when you read this section in the Head First book, notice that the methods that do the work are never described. The pattern is not about doing any of the real work. Not unlike some middle managers I’ve known. Like eye-candy for end users, this is syntatic candy for programmers. Important but not that important. [I wrote that last sentence hoping to avoid flames but I doubt it, the saving grace is that the probability anyone will read this is zip.] For design and for analysis, a thinking pattern you should use is a periodic sanity check: What are we really trying to accomplish here? What are our goals? Are we accomplishing it? Are we chasing rabbits? Are we beguiled by the problem insteading of focusing on the goal?