Hi Markus ---

Yes, I see we are complete agreement. Well said.


>> 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.
>
>Well, that's what I said. There are patterns for all kinds of situation. Some are design patterns, some are other patterns. I personally know more design patterns than maintenance patterns, to be honest... ;) but I agree with your statement.
>
>The name "Design Patterns" already guides us into the right direction. So do "Implementation Patterns" and others. I don't really think it's a question of how people see things. Or in other words: I can hardly imagine somebody would see a design pattern as being best used for maintenance, or vice versa. There are well defined boundaries for those things.
>
>Part of the problem simply is that the term "pattern" is way overused. Often, people ask me whether it is wrong not to use a certain pattern. And I think that we (in the VFP community) may have pushed into the wrong direction with all these patterns. Patterns are supposed to provide standard solutions for typical problem scenarios. They are not meant to make everybody who's not using them feel bad. Proper object oriented development doesn't require that the modeler/programmer knows or uses patterns. It just may make it a little easier for him to come up with good designs and it will def. make it much easier to talk about it.
>
>I personally like using patterns a lot, especially during modeling. It allows to just drop a number of objects I have identified in my use cases into a model, and then apply a pattern to make them work together (such as the Mediator, for instance).
>
>Markus