Search your topic in Java2share
Home > FAQs
eXTReMe Tracker

Design Patterns FAQs

Untitled Document

Q13. How does "Extreme Programming" (XP) fit with patterns?

Extreme Programming has a large emphasis on the concept of refactoring: Writing codeonce and only once. Patterns, particularly the structural patterns mentioned by the Gang of Four, can give good pointers about how to acheive that goal.
(XP states when and where factoring should happen, patterns can show you how.)

Q14. What is the disadvantage of using the Singleton pattern? It is enticing to use this pattern for all the classes as it makes it easy to get the reference of the singleton object.

The intent of the Singleton pattern is to ensure a class has only one instance and to provide a global point of access to it. True, the second part about providing a global point of access is enticing, but the primary disadvantage of using the Singleton pattern for all classes is related to the first part of the intent; i.e., that it allows only one instance of the class. For most classes in an application, you will need to create multiple instances. What purpose would a Customer class serve if you could create only one Customer object?

Q15. How do you write a Thread-Safe Singleton?

I have written plenty of non-thread-safe Singletons but it wasn't until recently when I tracked it down that I realized that thread-safety could be a big problem.
The problem is that in the typical Singleton implementation (at least the ones I've seen) there is the ability to create multiple versions of the single instance...I know, "But How?". Well, in the getInstance() call the instance is checked for null, and then immediately constructed if it is null, and then the instance is returned.
The problem is that the thread (Ta) making the call could swap-out immediately after checking for a null. A subsequent thread (Tb) could then make a call to get the instance and construct an instance of the Singleton. When the original thread (Ta) is then swapped back in, it would construct and return a completely separate object. BAD KITTY!

The following code snippet shows an example of a thread-safe Singleton.
package com.jgk.patterns.singleton;
public class JGKSingleton {
/* Here is the instance of the Singleton */
private static JGKSingleton instance_;
/* Need the following object to synchronize */
/* a block */
private static Object syncObject_;
/* Prevent direct access to the constructor
private JGKSingleton() {
public static JGKSingleton getInstance() {
/* in a non-thread-safe version of a Singleton */
/* the following line could be executed, and the */
/* thread could be immediately swapped out */
if (instance_ == null) {
synchronized(syncObject_) {
if (instance_ == null) {
instance_ = new JGKSingleton();
return instance_;
NOTE: The 2nd check for if (instance_ == null) is needed to avoid making another unnecessary

Q16. What is the Reactor pattern?

The new book "Pattern-oriented Software Architecture Volume 2" ISBN 0471606952 has a chapter on the Reactor pattern. It falls under the general category of "Event Handling Patterns". To quote the leading bit of the chapter, "The Reactor architectural pattern allows event-driven applications to demultiplex and
dispatch service requests that are delivered to an application from one or more clients" It is used in a synchronous manner, so that if the callback you delegate the event to takes a while to complete you will run into problems with scalability.