Friday, March 6, 2009

Over-Engineering and Design Patterns

I began studying design patterns in roughly the same period that I read Beck’s treatise on eXtreme Programming (Beck,1999). There is a conflict between the two schools and it’s important to consider it. The design pattern mantra is that we have identified a pattern that occurs often in programming and we have a way to solve it. No sense reinventing the wheel, there’s a pattern that solves the problem in a way that creates desirable software architecture. By learning these patterns we are creating a system of best practices which includes a richer vocabulary. By applying these patterns, we create more loosely coupled systems that are easier to maintain and change. From a pedagogical perspective, this is important to learn and a key stage to development. The process of understanding your system’s responsibilities and identifying these patterns is important in the development of OO thinking - which is entirely different from procedural thinking. But then the student encounters the “Stop Over-Engineering” people and becomes confused.

After passing through his phase of studying, understanding and applying design patterns, Kerievsky (2002) wrote a short paper entitled, “Stop Over-Engineering.” He thoughtfully describes his evolution to the following recognition: “But over time, the power of patterns led me to lose sight of simpler ways of writing code.” After relating a story where he realized, while pair-programming, that his approach to solving a problem was "… like applying a sledgehammer when a few light taps with a small hammer would do," he proceeds to describe what I believe is the next pedagogical stage in a programmer’s education, refactoring.
Nevertheless, a student of OO programming can’t stop over-engineering unless they know how to over-engineer in the first place. Kerievsky’s insight and subsequent treatise (Kerievsky, 2005) is the product of an active consultant in the software construction business. Students must learn the difference between the teachings of a professor and the teachings of a professional. The latter isn’t necessarily concerned with the entire pedagogical structure - their audience includes those who have mastered the stages leading up to their current level of understanding. The Kerievsky teachings are not for those who haven’t already studied design patterns. So, in my opinion, learn to over-engineer first (Gamma et al, 1994; Metsker, 2002; Shalloway & Trott, 2004;Martin, 2002 ) and then begin your studies of Kerievsky (2005) , Fowler (1999) and Beck (2002).

REFERENCES:
Beck, Kent (1999) eXtreme Programming eXplained: Embrace Change [ISBN 0201616416]
Fowler, Martin (1999) Refactoring [ISBN 0201485672]
Kerievsky, Joshua (2002) Stop Over-Engineering [http://www.industriallogic.com/papers/StopOverEngineering.pdf]
Kerievsky, Joshua (2005) Refactoring to Patterns [ISBN 0321213351]
Martin, Robert (2002) Agile Software Development: Principles, Patterns and Practices [ISBN 0135974445]
Metsker, Steven (2002) Design Patterns Java Workbook [ISBN 0201743973]
Shalloway, Alan and Trott, James R. (2004) Design Patterns Explained: A New Perspective on Object-Oriented Design, 2nd Ed. [ISBN 0321247140]

No comments:

Post a Comment