Hi Markus ---

I see DP as a way to categorize common needs (with maintenance, et al) and not necessarily to blueprint new development. In that respect, I expect a good object model to crossover into several patterns or have several patterns represented in a single object.

Call me a heretic, but I see DP as guidelines for maintaining and enhancing code and not as an end-all, be-all means of architecting solutions.

>> Is it just me, or do you also have a problem reconciling UML-based modelling
>> and basic OOAD with design patterns? I just about gave up on conciously
>> designing code along pattern lines.
>
>Keep in mind that patterns might be very small scale solutions for problems that might in fact be implementation issues. Consider the Template Method pattern, for instance. It might be used at such a small scale that it won't even show up in the model. So this one would be very hard to be mapped to a UML model (other than in very detailed message trace diagrams, I guess...). And I don't think they necessarily should...
>
>But then of course, there are large patterns such as the Strategy pattern or the Mediator pattern. Those will def. show up in the model. In fact, these patterns will be most useful in the model. Applying them at design time might be too late.
>
>Markus