Are TDD and POAD Competing Methodologies?

Question

Over the summer, I've been reading a lot about design. Two notable pieces that I read were Test Driven Development: By Example by Kent Beck, and another named Pattern-Oriented Analysis and Design: Composing Patterns to Design Software Systems by Yacoub.

These books take two very different approaches to designing software systems. My impression is that both of these techniques are at opposite ends of the spectrum. I come to this conclusion because:

• In POAD, we design strictly from patterns. In TDD, we refactor to patterns on an as-needed basis.
• In TDD, we keep models light weight. In POAD, we rigorously develop models for different levels of granularity. We use code generation and round tripping to keep the models and code consistent.
• POAD seems more theoretical, and less proven to work. Many software developers practice TDD.

I realize that TDD is well proven to work, though I see a lot of reasoning behind using a pattern-oriented approach to design:

• Patterns offer a higher level of abstraction than classes.
• Patterns allow you to ignore details of higher granularity.
• Trying to understand the system only in terms of code may become more difficult, however POAD provides higher level models that provide traceability. Using these models in conjunction with the code can make the system easier to understand at a faster pace.

So, given this, are these methodologies competing and mutually exclusive? I feel like I prefer POAD, though I certainly see TDD as a valuable design methodology. Is there a preferred approach?

Answer 1

I wouldn't consider those two approaches competing or mutually exclusive.

Even using POAD, you're still writing code. That code can still be Unit Tested. You can still write those tests before you write the code, watch them fail, write the code, and check for success.

It seems to me that they should be able to walk happily down the road to better code, hand in hand.

Answer 2

They are very different and very competing. And TDD does not recommend refactoring to patterns.

Patterns are programming concepts, not programming concretes. Although we encode our abstractions about the domain into our programs, we should not encode our abstractions about our programs into our programs.

Patterns are a way to understand your program in relation to other programs, identifying essential similarities, but are not a way to write your program. We identify essential similarities between otherwise different sets of code and call that a "pattern." Programming to patterns is not recommended - it is not like programming to contracts or programming to interfaces. Patterns do not direct the programming - they offer a way to conceptualize your programs and talk about them. You can say things like: "at a broad level, this group of classes in the XYZ module implements the ABC pattern." But you should not have classes named e.g. AbcPatternImpl.

Patterns are great. Pattern-driven development is flawed.