"Jeff" <A@B.COM> wrote in message
news:uP**************@TK2MSFTNGP11.phx.gbl...
I'm just getting up to speed on OOP patterns (e.g, MVC) and I'm wondering
how closely they are followed out in the real world. Do those of you who
use them try to follow them as closely as possible and deviate only as
necessary? Or do you only generally follow them; mix-n-match as necessary?
Just wondering what I should be looking to accomplish with OOP patterns in
general.
Thanks!
Jeff the terminology can get a bit overloaded here:
There are good design principles (Try to minimize coupling between the model
and its presentation) and patterns which represents common ways of
implementing those design principles (MVC)
Often the pattern becomes synonymous with the principle because there may
only be one pattern that supports the principle well or simply because a
pattern name is shorter than a description of the principle that it
embodies.
The problem is that you may well focus on the pattern rather than the
principle and have no understanding of why you are using it.
Some design principles are supported by several patterns and some patterns
support several principles.
Good pattern books always explain why the pattern is used (often called the
motivation) and when and when not to use it.
I find a lot of people these days seem to just throw patterns at a problem
without sufficient thought or any consideration of possible alternatives.
A good thing to remember is the thinking of the "founder" of the idea of
design patterns (who was actualy an architect) - The design patterns that we
use in the solution are the complement, inverse or mirror image of patterns
in the problem - there is a duality. This shows both the strengths and teh
weakness of patterns - A problem can be solved by a bunch of familiar, well
known design patterns ONLY if it is a familiar, well known problem. Since
all interesting programs solve new problems it follows that no interseting
program can rely solely on patterns.
Finally, The main value of patterns is in having a shared vocabulary and
frankly there are way too many patterns and dialects for that to work as
well as we would wish. If you want to be universally understood then stick
to the bible ("Design Patterns" by Gamma et al). [This doesn't mean that you
shouldn't read other books - just don't expect everyone else to know the
pattern names]