Which Design Pattern is best for Iterative development?

Question

Is there such a thing as having the most prefered design pattern for building applications in TDD or the iterative mode?

Answer 1

Use a dynamic language like Python or Ruby to develop: You don't have to fight with many of the problems other languages have which are the reason for "design patterns" in the first place.

Dynamic languages in combination with automated testing will give results really quick so you know which direction to take. If you realize then that you should use a static language for performance reasons or whatever you can translate the dynamic software you have already built.

Answer 2

I'm not sure that's a meaningful question. But I won't let that stop me...

It's entirely likely that specific patterns may become apparent as being appropriate to aspects of the design of your application as it evolves under your chosen agile process, but to (hopefully not mis-) quote Ron Jeffries, "the code will tell you".

Edit: But if you want a definitive answer, then Bridge. That's a good one. Or Visitor, I like that one too. Or most of the ones starting with "F". :)

Answer 3

Design patterns are tools to help solve particular types of problems. The use of patterns is governed by the problems defined by the scope of requirements, not by a development methodology.

Answer 4

Please don't mix different things. You use a pattern when it's applicable and saves you time, effort, and makes your code look more standard. It has nothing to do with your development methodology!

However, you may want to stress some things in your application architecture:

• Make things extremely modular. Embrace loose coupling.
• Define clear conceptual boundaries between modules. By conceptual I mean it should be clear for the start, feel natural. A random programmer asked about it should respond "Wow, it's obvious how you did it!".
• Start small. Don't try to produce ZOMG-this-will-be-the-best-and-most-universal-class-library-and-program-and-whatever. Make things work, and then extend, but only if necessary.
• Convince yourself that YAGNI (You aren't gotta need it). Don't do things you are not sure you have to do. It doesn't mean procrastination or something. It means don't do things because "I don't know, it may be useful in the future", "it's technically fancy", "I will include it just in case".
• DRY - don't repeat yourself. Make sure you don't run into code duplication problems. Think about code generators, good abstractions, and productive communication across the team.

Answer 5

I think the question could be rewritten so it makes more sense in these words:

"Which architectural patterns and strategies are useful in order to achieve flexibility when using a Test-Driven and incremental development strategy?"

My answer would be: patterns that help you decouple your clases and components, like:

• Inversion of Control and Dependency Injection - Help you keep the dependencies between your classes and components detached from specific implementations that are resolved until runtime (or startup time) allowing both using stubs for not-yet implemented functionality and for unit tests.

• Facades - Helps you isolate components providing well defined interfaces for interaction between them, reducing coupling.

• Factories and other creational patterns - They give you flexibility in the sections of your code responsible for instantiating objects.

Also remember that one of the mantras of incremental and iterative development is 'Do the simplest thing that could possibly work'. Don't over-engineer.

Does it makes sense according with what you asked?