• E-mail
• Print
• Comment
• Font Size
• Digg
• del.icio.us
• Discuss article

Refactoring to Patterns/Data Access Patterns

Posted on: Thursday, 5 January 2006, 06:00 CST

By Schneider, Ray

Refactoring to Patterns Joshua Kerievsky. 2005. Addison-Wesley (http://www.awprofessional.com). 367 pages. ISBN 0-321-21335-1.

Data Access Patterns Clifton Nock. 2004. AddisonWesley (http:// www .awprofessional.com). 469 pages. ISBN 0-13-140157-2. GSQE Body of Knowledge areas: Software Engineering Processes: Analysis, Design, and Development Methods and Tools

I have a confession to make: "I'm a patterns junkie." If there's a new book on patterns around I piek it up and devour it because I'm also a design junkie. I think the patterns movement is the closest thing to a real design technology in the software field.

Joshua Kerievsky has written a book that needed to be written. The majority of time that a piece of software exists, it is in a state rather amusingly called maintenance. If ever there was a misnomer, calling a persistent state of feature creep "maintenance" certainly qualifies. Sure some bugs get fixed, but the majority of the time software is experiencing not the correction of errors in coding, but a random walk adding topsy features just tacked on, making an ever-growing mudball of chaos pretending to be code. Sure there are exceptions, but not enough of them.

Kerievsky, early on, talks about why he wrote Refactoring to Patterns. He says, "After a couple of years... I discovered that my knowledge of patterns and the way I used them frequently led me to over-engineer my work." This observation links up with the Extreme programming principle "You ain't gonna need it." Too often people add features to their programs to take account of future contingencies that simply never materialize. The tendency that Kerievsky notes he calls the Patterns Panacea, which is frankly a kind of "cookbook engineering" mentality-we don't have to think because we're using patterns.

The flip side of the problem, and more important than overengineering, is the under-engineering problem that patterns partly addresses. It is produced by crazy schedules, the make-do psychology of "it's working now, don't touch it," and "who cares if the code is totally obscure we have to get it out the door." Shipping junk code is one of the dirty little or not so little secrets of the software industry where often quality is sacrificed on the altar of time to market.

Management often exacerbates this situation by invoking the "if it ain't broke we don't need to fix it" mindset and the result is a slow descent into mudball chaos that Kerievsky calls the "fast, slow, slower rhythm of software development." There simply has to be a better way.

In chapter 2 Kerievsky brings on his star: refactoring. The key is to remove duplication, simplify complexity, and clarify obscurity, but not at the expense of over-engineering. As the book unveils its vision of evolutionary design through refactoring to patterns the story is told with compelling clarity and an anecdotal style that makes it fun to read. By chapter 3, groundwork laid. Kerievsky returns to patterns. Patterns capture wisdom and knowledge of patterns lets us apply that wisdom, but not if they are employed blindly.

Kerievsky points out, "Good designers refactor in many directions, always with the goal of reaching a better design." The result is that evolving an optimal design doesn't so much mean embracing certain patterns but instead moving, dynamically, to, toward, and away from patterns. Observing the ways that he has refactored code on real projects, Kerievsky presents a table that summarizes his experience, starting with particular patterns and evolving to applications of the patterns or toward other patterns or sometimes away from one pattern to a simpler pattern or idiom. This table summarizes the expanded discussions that follow in what he calls A Catalog of Refactorings to Patterns.

The majority of the book is a catalog of refactorings to patterns. Each is presented in a pattern format that includes name, summary, motivation, mechanics, example, and variations. Patterns are illustrated using code drawn from real projects. In all 27 refactorings are presented, gathered together into themes treated in different chapters: Creation, Simplification, Generalization, Protection, Accumulation, and Utilities.

One simply can't go wrong with this book. It treats patterns in a dynamic way that is more the way they should be used, not as set pieces to be orchestrated in big upfront design, but as therapeutic correction of those bad smells so as to evolve dynamically toward the optimum design. It belongs next to the gang of four's Design Patterns on one's bookshelf.

In a brief afterward, John Brant and Don Roberts, co-creators of the world's first refactoring browser write: "The true value of this book lies not in the actual steps to achieve a particular pattern but in understanding the thought processes that lead to those steps. By learning to think in the algebra of refactoring, you learn to solve design problems in behavior-preserving steps,... Don't use this as a reference book, but as a primer."

The second book I've added to my patterns bookshelf is Clifton Nock's book Data Access Patterns. He calls it in the Introduction: "a catalog of data access patterns." Nock presents a systematic catalog of 25 patterns divided into five strategic areas. Some are universally applicable to common design problems in data access while others are less pervasive but applicable to many application domains.

The patterns in this useful catalog are grouped into five primary strategies. Decoupling patterns are describing for "decoupling data access components from other parts of an application." Resource patterns offer strategies for relational database access. Input/ output (I/O) patterns simplify I/O operations that translate between relational data in its physical form to its object representation in the application domain. Cache patterns address ways to reduce data access bandwidth. Finally, concurrency patterns deal with "strategies for robust, concurrent data access" that preserves data integrity.

All of the patterns are presented in a consistent pattern form: name, description, context, applicability, structure, interactions, consequences, strategies, sample code in Java, and related patterns and technology.

Data Access Patterns augments the gang of four's classic Design Patterns by specializing patterns and introducing domain-specific patterns focusing on the specific domain of data access. These two books. Refactoring to Patterns and Data Access Patterns, are both welcome additions to my growing bookshelf of software design patterns books.

Reviewed by Ray Schneider

(rschneid@bridgewater.edu)

Copyright American Society for Quality Dec 2005

Source: Software Quality Professional

More News in this Category