Patterns, in general

[Jeff]

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!

[chris martin]

Re: Patterns, in general

> I'm just getting up to speed on OOP patterns (e.g, MVC) and I'm[color=blue]
> 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!
>[/color]

Design patterns followed in the "real world"? That's funny.

Seriously though. A design pattern is like a shared vocabulary. You should
try to make your code understandable to other devs as much as possible. Of
course, that's pretty tough to do all the time. I would say to deviate only
if necessary. But, necessary is so relative....ahh . screw it. It's Friday.

I'm going to the drag strip... :) ::rock::

[Peter Bromberg [C# MVP]]

RE: Patterns, in general

Patterns are good because they help you solve problems in an elegant way
that's extensible (provided other developers you work with "buy in" to the
concept).

I think MVC is probably a bit advanced for starters. But any of the 20 or so
"basic" patterns such as Abstract Factory, Singleton, Decorator, Facade,
Flyweight, Mediator etc. are good to study and start to "work into" your
overall approach to solving "real world" business problems with code.

My 2 cents.

Peter
--
Co-founder, Eggheadcafe.com developer portal:

http://www.eggheadcafe.com

UnBlog:

http://petesbloggerama.blogspot.com

"Jeff" wrote:
[color=blue]
> 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!
>
>
>[/color]

[C.C. \(aka Me\)]

Re: Patterns, in general

I dont know if you can really say if people "follow" them or "generally" use
them because they are more outlines of how certain things should be
organized but not really implemented (language specific that is.) Now, if
you are asking if people actually use them in the real world then that is a
different story. I would think that more and more people and companies are
moving toward some sort of pattern system when they develop new
applications. Patterns and reusability go great together when done correctly
and companies should want to have code that can be reused as much as
possible.

--
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~
Charles Cox
VC/VB/C# Developer
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~

"Jeff" <A@B.COM> wrote in message
news:uPrhJY5IGH A.1192@TK2MSFTN GP11.phx.gbl...[color=blue]
> 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!
>[/color]

[Jeff Louie]

Re: Patterns, in general

At the minimum I think you should strive to separate out the application
logic
(Model) from the presentation/event handling.. What I have called M-VC
or what
Unix people call INTERFACE-ENGINE.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Ant]

RE: Patterns, in general

Hi,
Where can I find information about patterns? Any good books anyone can
recomend? Cheers.

Ant

"Peter Bromberg [C# MVP]" wrote:
[color=blue]
> Patterns are good because they help you solve problems in an elegant way
> that's extensible (provided other developers you work with "buy in" to the
> concept).
>
> I think MVC is probably a bit advanced for starters. But any of the 20 or so
> "basic" patterns such as Abstract Factory, Singleton, Decorator, Facade,
> Flyweight, Mediator etc. are good to study and start to "work into" your
> overall approach to solving "real world" business problems with code.
>
> My 2 cents.
>
> Peter
> --
> Co-founder, Eggheadcafe.com developer portal:
> http://www.eggheadcafe.com
> UnBlog:
> http://petesbloggerama.blogspot.com
>
>
>
>
> "Jeff" wrote:
>[color=green]
> > 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!
> >
> >
> >[/color][/color]

[Mark Carew]

Re: Patterns, in general


Hi Ant,

"Design Patterns in C# by Steven John Metsker, Addison Wesley" covers 23
of the most prevalent patterns in detail.
There is a brief discussion of the useage of some of them in "Dissecting
a C# Application - Inside SharpDevelop, Apress".

HTH
Mark

[Ant]

Re: Patterns, in general

Thank you Mark,
Ant

"Mark Carew" wrote:
[color=blue]
>
> Hi Ant,
>
> "Design Patterns in C# by Steven John Metsker, Addison Wesley" covers 23
> of the most prevalent patterns in detail.
> There is a brief discussion of the useage of some of them in "Dissecting
> a C# Application - Inside SharpDevelop, Apress".
>
> HTH
> Mark
>
>
>[/color]

[Peter Rilling]

Re: Patterns, in general

http://www.dofactory.com/Patterns/Patterns.aspx

"Ant" <Ant@discussion s.microsoft.com > wrote in message
news:09E390B4-1A4C-419B-848C-665E86838E89@mi crosoft.com...[color=blue]
> Hi,
> Where can I find information about patterns? Any good books anyone can
> recomend? Cheers.
>
> Ant
>
> "Peter Bromberg [C# MVP]" wrote:
>[color=green]
>> Patterns are good because they help you solve problems in an elegant way
>> that's extensible (provided other developers you work with "buy in" to
>> the
>> concept).
>>
>> I think MVC is probably a bit advanced for starters. But any of the 20 or
>> so
>> "basic" patterns such as Abstract Factory, Singleton, Decorator, Facade,
>> Flyweight, Mediator etc. are good to study and start to "work into" your
>> overall approach to solving "real world" business problems with code.
>>
>> My 2 cents.
>>
>> Peter
>> --
>> Co-founder, Eggheadcafe.com developer portal:
>> http://www.eggheadcafe.com
>> UnBlog:
>> http://petesbloggerama.blogspot.com
>>
>>
>>
>>
>> "Jeff" wrote:
>>[color=darkred]
>> > 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!
>> >
>> >
>> >[/color][/color][/color]

[Fred Mellender]

Re: Patterns, in general

Examples of some patterns built around search algorithms (with free C# code)
can be found at http://www.frontiernet.net/~fredm/dps/Contents.htm .
However, you should probably start with the more basic patterns as discussed
in this thread.

"Jeff" <A@B.COM> wrote in message
news:uPrhJY5IGH A.1192@TK2MSFTN GP11.phx.gbl...[color=blue]
> 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!
>[/color]

[Nick Hounsome]

Re: Patterns, in general

"Jeff" <A@B.COM> wrote in message
news:uPrhJY5IGH A.1192@TK2MSFTN GP11.phx.gbl...[color=blue]
> 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![/color]

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]

[Michael S]

Re: Patterns, in general

I think Nick spoke well below but just wanted to add 2 cents...

Don't overdo it!

I've seing coders being so hooked on patterns that they think they must be
used everywhere and everytime. Coders that just have to have a abstract
factory that returns some factory that gives you a adapter that maps to 10
classes in some MVC-style system.

While all that was required was a Console.WriteLi ne("Hello World!")

I would also recommend reading about antipatterns.

If you're going to know about the Factory-, Listener-, Front-Controller- and
the Monitor-pattern, I think you should read some about Lava Flow, The Blob,
Poltergeists and Spaghetti Code as well.

More info here:

http://www.serve.com/hibc/briefing/index.htm

Happy Coding
- Michael S


"Nick Hounsome" <nh002@nickhoun some.me.uk> wrote in message
news:DYHCf.2882 3$mu.13724@fe1. news.blueyonder .co.uk...[color=blue]
> "Jeff" <A@B.COM> wrote in message
> news:uPrhJY5IGH A.1192@TK2MSFTN GP11.phx.gbl...[color=green]
>> 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![/color]
>
> 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]
>
>[/color]

[Jeff]

Re: Patterns, in general

Awesome! Thanks guys! (everybody who responded)





"Michael S" <no@mail.com> wrote in message
news:uMQwQ9CJGH A.424@TK2MSFTNG P12.phx.gbl...[color=blue]
>I think Nick spoke well below but just wanted to add 2 cents...
>
> Don't overdo it!
>
> I've seing coders being so hooked on patterns that they think they must be
> used everywhere and everytime. Coders that just have to have a abstract
> factory that returns some factory that gives you a adapter that maps to 10
> classes in some MVC-style system.
>
> While all that was required was a Console.WriteLi ne("Hello World!")
>
> I would also recommend reading about antipatterns.
>
> If you're going to know about the Factory-, Listener-, Front-Controller-
> and the Monitor-pattern, I think you should read some about Lava Flow, The
> Blob, Poltergeists and Spaghetti Code as well.
>
> More info here:
>
> http://www.serve.com/hibc/briefing/index.htm
>
> Happy Coding
> - Michael S
>
>
> "Nick Hounsome" <nh002@nickhoun some.me.uk> wrote in message
> news:DYHCf.2882 3$mu.13724@fe1. news.blueyonder .co.uk...[color=green]
>> "Jeff" <A@B.COM> wrote in message
>> news:uPrhJY5IGH A.1192@TK2MSFTN GP11.phx.gbl...[color=darkred]
>>> 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![/color]
>>
>> 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]
>>
>>[/color]
>
>[/color]