471,321 Members | 1,900 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,321 software developers and data experts.

Patterns, in general

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!
Jan 27 '06 #1
12 1739
> 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!


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::
Jan 27 '06 #2
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:
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!

Jan 27 '06 #3
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: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!

Jan 28 '06 #4
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 ***
Jan 28 '06 #5
Ant
Hi,
Where can I find information about patterns? Any good books anyone can
recomend? Cheers.

Ant

"Peter Bromberg [C# MVP]" wrote:
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:
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!

Jan 28 '06 #6

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
Jan 28 '06 #7
Ant
Thank you Mark,
Ant

"Mark Carew" wrote:

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

Jan 28 '06 #8
http://www.dofactory.com/Patterns/Patterns.aspx

"Ant" <An*@discussions.microsoft.com> wrote in message
news:09**********************************@microsof t.com...
Hi,
Where can I find information about patterns? Any good books anyone can
recomend? Cheers.

Ant

"Peter Bromberg [C# MVP]" wrote:
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:
> 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!
>
>
>

Jan 28 '06 #9
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: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!

Jan 28 '06 #10
"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]
Jan 28 '06 #11
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.WriteLine("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" <nh***@nickhounsome.me.uk> wrote in message
news:DY******************@fe1.news.blueyonder.co.u k...
"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]

Jan 28 '06 #12
Awesome! Thanks guys! (everybody who responded)

"Michael S" <no@mail.com> wrote in message
news:uM*************@TK2MSFTNGP12.phx.gbl...
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.WriteLine("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" <nh***@nickhounsome.me.uk> wrote in message
news:DY******************@fe1.news.blueyonder.co.u k...
"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]


Jan 28 '06 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by lawrence | last post: by
2 posts views Thread by Design Pattern Catalog | last post: by
1 post views Thread by Takayasu Kenduma | last post: by
13 posts views Thread by John Salerno | last post: by
3 posts views Thread by yb | last post: by
8 posts views Thread by kk_oop | last post: by
24 posts views Thread by John Salerno | last post: by
7 posts views Thread by =?Utf-8?B?bWF2cmlja18xMDE=?= | last post: by
2 posts views Thread by LarryTheSoftwareGuy | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.