1)What is an analysis pattern?

An analysis pattern is a software pattern not related to a language or implementation problem, but to a business domain, such as accounting or health care. For example, in health care, the patient visit activity would be subject to a number of patterns.

There is a good overview from an OOPSLA '96 presentation at http://www.jeffsutherland.org/oopsla96/fowler.html

A good text would be:
Martin Fowler's Martin Analysis Patterns : Reusable Object Models, ISBN: 0201895420, published by Addison-Wesley.

In summary, analysis patterns are useful for discovering and capturing business processes.

2)What are the differences between analysis patterns and design patterns?

Analysis pattern are for domain architecture, and design pattern are for implementation mechanism for some aspect of the domain architecture. In brief, analysis pattern are more high level and more (end-user) functional oriented.

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

Extreme Programming has a large emphasis on the concept of refactoring: Writing code once 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.)

4)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?

5)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() {
    super();
  }


  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 construct.

Don't let this byte you! ;-)

6)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.

7)What are Process Patterns?

Basically process patterns define a collection of best practices, techniques, methods for developing object-oriented software.

A good reference site is by Scott Ambler. He also has two books on the topic plus a white paper on the subject you can download.

http://www.ambysoft.com/processPatternsPage.html.

8)How and where did the concept of design patterns get started?

Work on patterns has been influenced by the works of Christopher Alexander who published on topics related to urban planning and building architecture in the late 1970s. The history of patterns for software design began in the late 1980s and reached an important milestone with the publishing of the first book fully dedicated to this subject by the "Gang of Four", Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns - Elements of Reusable Object-Oriented Software). In conjunction, the emergence of object-oriented software development fostered the work on other topics related to design patterns such as application frameworks, analysis patterns, language idioms, and so on.

9)Where can I find good examples of the Prototype pattern?

The prototype pattern is actually quite simple to implement in Java.

Recall that the idea of prototype is that you are passed an object and use that object as a template to create a new object. Because you might not know the implementation details of the object, you cannot create a new instance of the object and copy all of its data. (Some of the data may not be accessible via methods). So you ask the object itself to give you a copy of itself.

Java provides a simple interface named Cloneable that provides an implementation of the Prototype pattern. If you have an object that is Cloneable, you can call its clone() method to create a new instance of the object with the same values.

The trick here is that you must override the clone() method to increase its visibility, and just call super.clone(). This is because the implementation of clone(), defined in java.lang.object, is protected. For example:

  public class CopyMe implements Cloneable {
    public Object clone() {
      return super.clone();
    }
  }

Note that Cloneable is an empty interface! It merely acts as a tag to state that you really want instance of the class to be cloned. If you don't implement Cloneable, the super.clone() implementation will throw a CloneNotSupportedException.

The Object implementation of clone() performs a shallow copy of the object in question. That is, it copies the values of the fields in the object, but not any actual objects that may be pointed to. In other words, the new object will point to the same objects the old object pointed to.

As an example of using the cloning:

  CopyMe thing = new Copyme();
  CopyMe anotherThing = 
    (Copyme)thing.clone();

This example is pretty trivial, but the real power comes when you don't know what you're actually cloning.

For example, suppose you define an interface that represents a customer:

  public interface Customer extends Cloneable {
    public Object clone(); // require making it public!
    public String getName();
    public void setName(String name);
    ...
  }

You might have several different implementations of this interface, possibly storing data in a file, database, or using EJB Entity beans. If a shallow copy of the data is sufficient to represent a copy of the object, Java's clone() method works great.

You might have a method that needs to make a copy of the data to store it in a Hashtable, for example:

  public void storeCustomer(Customer customer) {
    Customer copy = (Customer)customer.clone();
    dataStore.put(copy);
  }

Note that this method knows nothing about what type of customer we're getting. This pattern will work for any actual type of Customer, no matter how the data is stored. For example:

  FileBasedCustomer  c1 = new FileBasedCustomer(...);
  RDBMSBasedCustomer c2 = new RDBMSBasedCustomer(...);
  EJBBasedCustomer   c3 = new EJBBasedCustomer(...);
  
  manager.storeCustomer(c1);
  manager.storeCustomer(c2);
  manager.storeCustomer(c3);

10)What are Anti-Patterns?

There isn't really a "clean-cut" definition out there just yet, unlike Design Patterns. Basically, as Design Patterns (and more particularly, Process Patterns) try to codify a standard vocabulary for working solutions to problems that reappear frequently, Anti-Patterns represent an effort to define and classify reoccuring non-solutions, i.e., things that lots of projects do that fail to yield a solution, or actually prevent a project from working or being finished.

The most basic example I can think of is "The Hammer", inspired by the old addage, "If your only tool is a hammer, everything looks like a nail" (or the variation, "If your only tool is a hammer, everything looks like your left thumb." Hammer describes a regular, reoccuring problem in inexperienced engineers (particularly those who've only used one language for the bulk of their carreer so far), that of trying to force-feed all problems into the solutions they already know.

http://www.antipatterns.com/ has more information.