This week's book giveaways are in the Jython/Python and Object-Oriented programming forums.
We're giving away four copies each of Machine Learning for Business: Using Amazon SageMaker and Jupyter and Object Design Style Guide and have the authors on-line!
See this thread and this one for details.
Win a copy of Machine Learning for Business: Using Amazon SageMaker and JupyterE this week in the Jython/Python forum
or Object Design Style Guide in the Object-Oriented programming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

design patterns - why to use and how to select them

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1.Why do we go for Design Patterns?
2.So many patterns are available. how to match the pattern with the problem?
[ January 18, 2006: Message edited by: Ilja Preuss ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Patterns represent common solutions found in multiple places. They have to be found and harvested, not just made up, so you know that several people have worked their ways to the same answer. That gives us some confidence that they are pretty good solutions.

When to use them is a big question. Too many people have found something cool in a pattern book and then looked for a place they could use it. This can lead to a poor fit just to get some pattern on your resume or product brochure.

The members on this board talk more often about coding along and realizing that the code is starting to feel like some pattern. Then we can go to the book and see if it really matches, and if the book has some good ideas or warnings we might have forgotten about. If it's really a good match, we can rename classes and methods to match the book so future readers can recognize it more quickly. We might also comment "This is like the X pattern, but we diverge here for this reason ..."

You have to have a pretty good pattern catalog in your head to recognize them when they start to emerge from your code.

Note that this is most appropriate when talking about finer grained design patterns like those in the GoF book. Big architectural patterns might come much earlier in the design, perhaps even as constraints imposed by enterprise architects.
 
Ranch Hand
Posts: 138
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One pattern is related to other. So in order to use them we must have a fair theoritical knowledge of many patterns.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
To add to what Stan said, there is a very good book about the topic: http://www.industriallogic.com/xp/refactoring/
 
Ranch Hand
Posts: 8943
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a question - Are there any patterns apart from GoF patterns ?
 
Ranch Hand
Posts: 1140
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Pradip Bhat:
I have a question - Are there any patterns apart from GoF patterns ?



There are many. One of the well known patterns - DAO pattern is not a part of GOF pattern, for example.
Null Object, which is used quite frequently isn't a GoF pattern either.
 
Pradeep bhatt
Ranch Hand
Posts: 8943
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Mani Ram:


There are many. One of the well known patterns - DAO pattern is not a part of GOF pattern, for example.
Null Object, which is used quite frequently isn't a GoF pattern either.



I feel that J2EE patterns are based on GoF patterns.DAO pattern makes uses of Abstract factory pattern from GoF.
 
Pradeep bhatt
Ranch Hand
Posts: 8943
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
http://www.cs.oberlin.edu/~jwalker/nullObjPattern/

This link about NullObject pattern says that NullObject pattern is a special case of Strategy pattern.
 
Mani Ram
Ranch Hand
Posts: 1140
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ofcourse, many patterns looks very similar to each other or uses other patterns. Whant makes patterns different from each other is not their structure, but their intent.

This similarity can be found even among the GoF patterns. For example, the Abstract Factory pattern (one of the GoF patterns), is a special case of Strategy pattern (another GoF pattern). Same case with Template Method & Factory Method.

So, eventhough you can relate DAO to Abstract Factory & Null Object to Strategy, their intents are totally different and I would consider them as completly different patterns.
 
Trailboss
Posts: 23083
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think patterns started off as generally recognized best solutions for common problems.

But now that they have been around for a while and we have experienced applications being made ten times more complicated than they need to be because people try to cram in all they patterns that they have read about ("my application is well architected, because it is loaded to the gills with patterns.") my impression of the value of the pattern has shifted a bit.

I now think that the primary purpose of patterns is to expand our vocabulary. I can say "singleton" and we all know what that means. There may be a dozen different ways to implement a singleton - it doesn't have to be done exactly like the GoF book or some web page.

I think that any pattern being used in an application could/should(/must!) be trumped by "the simplest thing that could possibly work."

And one last thing ... puh-leeze, let's not get suckered by some putz who creates his own web page declaring a pattern. It's only a pattern when it is generally recognized by the greater minds of computer science. And let's add to that there are a lot of intern engineers working for big companies that we trust that have the ability to post content ("IBM Department of Uber Genius Types Declare 'The Squeaky Duck Pattern'"). And there are some books that print some of this garbage too.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Re other patterns: This Post has links to three good sources: Sun's J2EE Patterns, Enterprise Integration Patterns and Patterns of Enterprise Architecture
[ January 19, 2006: Message edited by: Stan James ]
 
paul wheaton
Trailboss
Posts: 23083
IntelliJ IDE Firefox Browser Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Stan James:
Re other patterns: This Post has links to three good sources: Sun's J2EE Patterns, Enterprise Integration Patterns and Patterns of Enterprise Architecture

[ January 19, 2006: Message edited by: Stan James ]



I generally trust anything Martin Fowler says/writes. I think he is probably the premier author in computer science today. I have read is book "Patterns of Enterprise Application Architecture" and find it to be first rate. Mr. Fowler appreciates what a pattern really is and that it must be generally accepted before calling it a pattern.

Your link "Enterprise Integration Patterns" is interesting. Thanks!

Your first link ... (cough) (cough) (cough) (choke) - oh (cough) sorry ... (cough) I seem to have something (cough) stuck in my throat .... (cough)(cough)(cough) .....
 
Ranch Hand
Posts: 73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Uma Mahi:
1.Why do we go for Design Patterns?
2.So many patterns are available. how to match the pattern with the problem?

[ January 18, 2006: Message edited by: Ilja Preuss ]



I had the same question when I started learning Java and OOP. I thought that design patterns were a "neat idea" but not very practical for real applications. Reading several books about Java, I started to see similarities in code and patterns. In other words, the same types of problems were being solved in a similar manner with design patterns. After learning more about patterns, I realize how beneficial they really are.

Eric
 
Pradeep bhatt
Ranch Hand
Posts: 8943
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Mani Ram:
Ofcourse, many patterns looks very similar to each other or uses other patterns. Whant makes patterns different from each other is not their structure, but their intent.

This similarity can be found even among the GoF patterns. For example, the Abstract Factory pattern (one of the GoF patterns), is a special case of Strategy pattern (another GoF pattern). Same case with Template Method & Factory Method.

So, eventhough you can relate DAO to Abstract Factory & Null Object to Strategy, their intents are totally different and I would consider them as completly different patterns.



They are either alterations (special cases)or built over the GoF. Are there patterns which are different from the ones mentioned in GoF book?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Pradip Bhat:

They are either alterations (special cases)or built over the GoF. Are there patterns which are different from the ones mentioned in GoF book?



I'm with Mani here. It's not just the structure that defines a design pattern, but also the context and the intentions. I'd say that Null Object very much qualifies as a "different" design pattern.

Another one that comes to mind instantly is Monostate.

Or Just Create One.
 
this llama doesn't want your drama, he just wants this tiny ad for his mama
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!