wood burning stoves 2.0*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Best 10 design pattern every developer should be aware of Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Best 10 design pattern every developer should be aware of " Watch "Best 10 design pattern every developer should be aware of " New topic
Author

Best 10 design pattern every developer should be aware of

vijay jacob
Ranch Hand

Joined: Jul 02, 2013
Posts: 57


1. Singleton
2.Factory
3. decorator
4. builder
5. proxy
6. template
7. adapter
8. chainofresponsibility
9. stratergy
10.flyweight

Share your 10 best pattern.
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2273
    
  28

Singleton!!! Why did have to be singleton? Whenever I interview someone about design patterns, they say Singleton
vijay jacob
Ranch Hand

Joined: Jul 02, 2013
Posts: 57
Guess the person just started sailing in the ocean.only thing he can recognise confidently is that ...


Post what you think is the 10 best pattern.


Thanks
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60783
    
  65

There are no "best" patterns. There are just applicable ones.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
vijay jacob
Ranch Hand

Joined: Jul 02, 2013
Posts: 57


10 Common patterns for most common problems.
vijay jacob
Ranch Hand

Joined: Jul 02, 2013
Posts: 57
According to the site http://www.learningtree.com/courses/516/java-best-practices-and-design-patterns/

common design patterns

Observer
Iterator
Template method
Strategy
Factory
Singleton
Data Accessor Object
Data Transfer Object
Composite
ServiceLocator
Proxy
Factory
Maciej Opala
Ranch Hand

Joined: Jul 18, 2011
Posts: 38
Bear Bibeault wrote:There are no "best" patterns. There are just applicable ones.


That's the point!
T. Sharma
Author
Ranch Hand

Joined: Jul 30, 2013
Posts: 46
    
    5
Bear Bibeault wrote:There are no "best" patterns. There are just applicable ones.


Very well said. It is not the case that one pattern is "better" than other. It is the context where a pattern makes sense and other don't.


Tushar Sharma (Twitter: @Sharma__Tushar)
http://sharmatushar.blogspot.in/
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 510
    
    4

Damn, I guess I should start using more Singletons then! ;)


Oracle Certified Professional: Java SE 6 Programmer && Oracle Certified Expert: (JEE 6 Web Component Developer && JEE 6 EJB Developer)
Campbell Ritchie
Sheriff

Joined: Oct 13, 2005
Posts: 38025
    
  22
You should only use a Singleton once
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 510
    
    4

Rats, there goes my "Most usages of the most popular patterns" award :P
Muhammad Khojaye
Ranch Hand

Joined: Apr 12, 2009
Posts: 449

Dieter Quickfend wrote:Damn, I guess I should start using more Singletons then! ;)

Then also watch the downside as it sometimes infamous in object oriented systems . Why Singletons are Controversial also gives another good overview on the pitfalls.


http://muhammadkhojaye.blogspot.com/
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 510
    
    4

I checked those links and the problems mentioned seem to be generally linked to wrong assumptions about restrictions of a singleton. Any singleton is easily testable (as opposed to static classes) and if you need to synchronize getters you should probably not be using a singleton in that place. the 'Singleton' pattern is also not limited to some getInstance() method at all. But in a case where you need to concurrently change state of an object often, using a singleton is of course not a good idea. This doesn't mean a Singleton is evil, it just means it is used in the wrong place often.. Probably because it is (one of) the most famous patterns. Imagine if everyone would be using facades to be doing fine grained method calls and making transfer objects with the same properties as their entities. Doesn't mean these patterns are evil, it just means you're not doing it right.
Stephan van Hulst
Bartender

Joined: Sep 20, 2010
Posts: 3599
    
  14

My top 5 overused patterns:
Singleton
Singleton
Singleton
Inheritance
Singleton

Dieter,
Singletons are not easily testable. You can not create mock objects of them, there's no point in injecting them, and furthermore, your tests can not guarantee that they are in a valid state if they're not immutable.

What I don't understand is *why* people want to make their classes instance controlled. For non-essential features like Logging I understand, but business logic? Never. Just create the right amount of instances and inject them.
Muhammad Khojaye
Ranch Hand

Joined: Apr 12, 2009
Posts: 449

Dieter, I think you misunderstood. Its not about Singleton is bad but many times this has been used as a shortcut so that the designer doesn't need to think correctly about object visibility.
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 510
    
    4

I disagree. Testability of a singleton is completely dependent on the implementation. A Singleton's factory method is not necessarily implemented inside the singleton itself, and a singleton not necessarily prohibits inheritance.

Of course, the easiest example is using singleton injection in Spring. The class is just a POJO, testable and extensible, but it becomes a singleton only because the injection will always inject the same instance.

I will give a concrete example from a former project:

We had a certain huge XML sitemap file which was being read all through the application, which was causing numerous problems with performance, resource locking and uniformity. Noticing this while profiling, I decided to do a small test containing a change listener for the file, a builder that created a sitemap object hierarchy with all the relevant data loaded into memory, and implemented a provider object for the sitemap object. This was in the spring context, and would return the currently up-to-date sitemap object for any 'getSitemapInstance()' call.

After using this in all the instances that the XML file was used before, the performance of the application had increased factor 30.

So is your problem with this Singleton, that this is technically not a Singleton? Because it is, functionally...
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2273
    
  28

Spring's singleton is not a Singleton. In a Singleton pattern, there can be only one instance of the given class. Spring calls it singleton, but it's not an implementation of the Singleton pattern.
Dieter Quickfend
Bartender

Joined: Aug 06, 2010
Posts: 510
    
    4

I guess I disagree on that idea, simply because dependency injection is a solution for possible technical shortcomings of a singleton, but not the possible functional shortcomings.

To me, a pattern is never about technical implementation, but the idea behind. The idea behind a singleton is a class that only has one meaningful object in a certain application. The spring singleton in my example was the provider class, but that is a meaningless holder. The real singleton was the Sitemap class. And though it is just a POJO that can be instantiated by anyone, there is no other meaningful implementation of it possible in the application. That means in my opinion that it's a singleton.

After some googling for definitions of a singleton, along with running into the forced code implementations, I came up with two partial definitions:

"the singleton class has control over how it is created"
"there is only one singleton in a JVM"

In my example, it is the listener that has control over when it is created, the builder that controls how it is created. There is only ever one Sitemap instance linked to the provider, and the provider must be used to reach the sitemap. Any Provider instance instantiated by the developer will not contain a sitemap object. Thus the object is very much unique and -indirectly- has full control over its instantiation - that is, the developer does not govern the instantiation of the object. That makes it a singleton functionally - on a component level - though it is not a singleton implementation in the technical sense.

So I guess whether you can call it a Singleton object is completely dependent on your perception of what a singleton object actually is. Me, I tend not to restrict a pattern to any particular implementation, whether it be a static method or an enumeration type. If I shouldn't be using 'Singleton' for this pattern, maybe you're right. In that case, I guess there are many common patterns I say I'm using, but am not really using
Jayesh A Lalwani
Bartender

Joined: Jan 17, 2008
Posts: 2273
    
  28

When people talk about Singleton pattern, they talk about Singleton pattern the way GoF defined it, and GoF has a very precise definition of every pattern in the book. We all had this big meeting and we decided that GoF's definition of Singleton is the only definition of Singleton, and GoF's Singleton sucks. Didn't you get the memo? Seriously speaking, when people are talking about any pattern, the convention is to consider GoF Design pattern book to be the dictionary of design patterns. It doesn't matter what your definition of a pattern is. As a convinience, the industry has decided to use GoF's book as the dictionary.

Spring's implementation of singleton objects doesn't fit the SIngleton pattern as defined in the book. That doesn't mean that Spring's implementation is not useful. It just means that it's not a Singleton.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Best 10 design pattern every developer should be aware of
 
Similar Threads
OCMJD .URLyBIRD 1.1.2 Version
how many problems will be on the exam about patterns and structs?
Question about the SCJP exam
Best Design Pattern book
Difference between two design pattern books