Better Software - March 2008 - (Page 46)

by Alan Shalloway and Rob Myers PatternS are not “SolutionS to a ProbleM in a context.” This definition was originally applied to patterns as a teaching tool. Once patterns are understood, this definition tends to be limiting—and potentially counterproductive. In fact… deSign PatternS are wayS of thinking. Patterns are really about identifing common problems and then solving them. Patterns provide a set of issues (“forces”) that the developer must address. They also present potential ways to resolve these forces and provide a language with which to communicate about these forces. deSign PatternS are about handling variation. In software, most of these forces relate to how the code must adapt to change or how changing requirements affect the code. This is one of the greatest problems in writing code: dealing with change. Patterns can help us inject new functionality into our code in a way that keeps the code quality high. Which is why… agile Software develoPMent MakeS PatternS More iMPortant than ever. If you are using agile methods, change is truly a way of life. Design patterns help you accommodate this change. deSign PatternS are aS Much about analySiS aS about deSign. Design patterns start with an intention to be implemented. This intention is really defined while analyzing the problem. Hence… the uMl deSign of a Pattern iS not a good indicator that you have a Pattern PreSent. Many of the implementations of design patterns look alike, particularly their corresponding UML diagrams. What differentiates one pattern from another are the forces involved and how they are resolved. PatternS cannot be overuSed. When you use design patterns appropriately, you are thinking in a better, more effective manner. This thought process will guide you into a design and implementation that fits the problem. If you force-fit what someone might call a pattern implementation into a problem where it doesn’t belong, you are not following the pattern thought process and are therefore not using the pattern properly. deSign PatternS uSe the SaMe PrinciPleS aS teSt-driven develoPMent (tdd). Both rely on essential code qualities such as cohesive, decoupled objects, and both resolve forces. Patterns help a good TDD practitioner follow a primary rule of TDD: Never create redundancy. Patterns are very much about this. you often evolve your deSignS to PatternS. Thinking in patterns means handling variation when it becomes present in a manner that maintains high code quality. Patterns handle variation by “finding what varies and encapsulating it.” You can do this once variations start to occur. Thus, you can start with a simple solution and evolve to the pattern as the forces require. PatternS are SeriouSly MiSunderStood. You’ve probably figured this out by now! 46 BETTER SOFTWARE MARCH 2008 www.StickyMinds.com http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - March 2008

Better Software - March 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: Breaking Ground On SOA Software Development Worst Practices Mind the Gap Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.