[Editor: Not really a book review, but it sounds intriguing. If anyone would like to obtain it and do an a book review, I'd be happy to post it.] This book is written by developers (actual developers and not semi-academics, no pun intended). On the book the editor describes it as: "The idea that lead to this book originated during the participation of a Java Architect training program taught at Logica Sverige AB Karlstad office. During the course the authors identified the lack of a quick-guide to the basic GoF design patterns. A book that could be used as a bare bone reference as well as a learning companion for understanding design patterns. In the book all patterns are exemplified using Java and UML2 notation. The book also focuses on benefits, drawbacks, applicability and indicates successful real life usage of the individual patterns." The book is published through several e-book publishers like spotbit.com, freetechbooks.com. But easiest is probably to get it via Scribd. At least Me Like! http://www.scribd.com/doc/9973578/Design-Patterns-Explained-With-Java-and-Uml2-2008

...During the course the authors identified the lack of a quick-guide to the basic GoF design patterns. A book that could be used as a bare bone reference as well as a learning companion for understanding design patterns.

There is an book by Bruce Eckel "Thinking in Patterns with Java" (2003) with the similar focus and did it pretty well in explaining GoF patterns in practice with Java. New book feels like notebook-reference distilling practical aspects of patterns, maybe, too concentrated.

Hi Benneth, your singleton implementation is the typical example of a badly implemented Singleton. It is not thread-safe. Please at least make the getFileLogger() method synchronized. BR, Robert

Yeah, you are right Robert of course we should mention that the example isn't thread safe in Java. It's still a Singleton though ;-) In next version we will either add the comment "not threadsafe" somewhere in the example or use the "less pedagogical but threadsafe alternative. public class Singleton { private static final Singleton s=new Singleton(); private Singleton() { } public static Singleton getSingleton() { return s; } }

Yeah, you are right Robert of course we should mention that the example isn't thread safe in Java. It's still a Singleton though ;-)

Benneth, making the method synchronized will make it thread-safe (although not fast). However, considering that in YOUR description of the Singleton pattern the where to use section contains the following: "When only one instance or a specific number of instances of a class is allowed." And the benefits section contains the following: "Controls access to unique instance" I would even say that your implementation is not a Singleton by your own definition. Can you tell me the specific number of instances this implementation will instantiate? No. It may create an indeterministic number of instances in race conditions. Does it control access to a unique instance? No. It can give back multiple different instances in race conditions. Best regards, Robert

Yeah, you are right Robert of course we should mention that the example isn't thread safe in Java. It's still a Singleton though ;-)

Benneth,

making the method synchronized will make it thread-safe (although not fast).

However, considering that in YOUR description of the Singleton pattern the where to use section contains the following:

"When only one instance or a specific number of instances of a class is allowed."

And the benefits section contains the following:

"Controls access to unique instance"

I would even say that your implementation is not a Singleton by your own definition.

Can you tell me the specific number of instances this implementation will instantiate? No. It may create an indeterministic number of instances in race conditions.

Does it control access to a unique instance? No. It can give back multiple different instances in race conditions.

Best regards,

Robert

And btw, it doesn't even have to be a tight race condition. Actually nothing in your posted code guarantees that the static member instance is published to other threads at all. Due to this, if you have a thread-pool with its threads started when the static member instance was not initialized, and all threads in the pool invoke getFileLogger() they all may receive different instances!!! Best regards, Robert

ok ok that sounds really bad. So suppose we limit ourself to Java SE 5 or later we could go with the transient approach http://en.wikipedia.org/wiki/Singleton_pattern#Java_5_solution But then we are still limiting us to one specific jvm. If we go beyond that we could end up like this http://www.theserverside.com/patterns/thread.tss?thread_id=20819 So in the interest of a barebone general summarized "s a bare bone reference as well as a learning companion for understanding design patterns." guide... I'll add the comment "not thread safe" and a short discussion of these discussed aspects regarding Singletons.

http://www.scribd.com/doc/9973578/Design-Patterns-Explained-With-Java-and-Uml2-2008 doesn't exist anymore. Could anybody give me a working one? Thanks!

Hi ca lifny. The book is under revision. I decided to close link in the meantime. It will soon be available in a new version. Sorry for any inconvenience this may cause.

The pagination is a key part in web system design both from perspective it makes ui friendly to user and performance perspective in server side.Thanks for sharing informative post.
Regards.

Sell Damaged Iphone