Hiya Nancy -----
Random thoughts from an unkempt mind..... :-D
>
>1. Does one look at problem through design patterns or look at design patterns
>through a problem? IOW, do I sit down and describe/define the problem/situation first and then look at patterns for guidance in designing the solution/automation?
>
Of course you look at the problem first but you need to do that formally to be able to "see" patterns emerge from the situation. CRC, use case, and other types of analysis come to mind.
>2. Can one become lost in an analogy that is too broad and essentially results in a shrug and "it depends." For example, I'm thinking still of the study group idea and would it make sense to put it in the context of designing an actual solution. Such as: I want you to give me an application that will describe Albuquerque's metropolitan transportation system so that, as a city planner, I can evaluate different ride-sharing programs, winter pollution alerts, highway projects.
>
Oh absolutely. I know some great developers who spin their wheels trying to bring too much theory to bear on a situation. Again, I think the way you perform your analysis from OOAD to OOSE to OOP counts for a lot.
------------------------------------------------
John Koziol, ex-MVP, ex-MS, ex-FoxTeam. Just call me "X"
"When the going gets weird, the weird turn pro" - Hunter Thompson (Gonzo) RIP 2/19/05