XML Resource Management

Using Oracle XML DB

OCA Resource Management

OCA

OCA Notes, RR-Date-Format-Element , Date and TimeStamp, OCA Preparation

Singleton Pattern

With the Singleton design pattern you can:

1. Ensure that only one instance of a class is created
2. Provide a global point of access to the object
3. Allow multiple instances in the future without affecting a singleton class's clients

The figure below illustrates the Singleton design pattern class diagram



Singletons maintain a static reference to the sole singleton instance and return a reference to that instance from a static instance() method.

Condider the following design implementation

Example 1. The classic singleton

public class ClassicSingleton {
private static ClassicSingleton instance = null;
protected ClassicSingleton() {
// Exists only to defeat instantiation.
}
public static ClassicSingleton getInstance() {
if(instance == null) {
instance = new ClassicSingleton();
}
return instance;
}
}

The ClassicSingleton class maintains a static reference to the lone singleton instance and returns that reference from the static getInstance() method.

There are several interesting points concerning the ClassicSingleton class.

First, ClassicSingleton employs a technique known as lazy instantiation to create the singleton; as a result, the singleton instance is not created until the getInstance() method is called for the first time. This technique ensures that singleton instances are created only when needed.

Second, notice that ClassicSingleton implements a protected constructor so clients cannot instantiate ClassicSingleton instances; however, you may be surprised to discover that the following code is perfectly legal:

public class SingletonInstantiator {
public SingletonInstantiator() {
ClassicSingleton instance = ClassicSingleton.getInstance();
ClassicSingleton anotherInstance =
new ClassicSingleton();
...
}
}

How can the class in the preceding code fragment—which does not extend ClassicSingleton—create a ClassicSingleton instance if the ClassicSingleton constructor is protected? The answer is that protected constructors can be called by subclasses and by other classes in the same package. Because ClassicSingleton and SingletonInstantiator are in the same package (the default package), SingletonInstantiator() methods can create ClassicSingleton instances. This dilemma has two solutions: You can make the ClassicSingleton constructor private so that only ClassicSingleton() methods call it; however, that means ClassicSingleton cannot be subclassed. Sometimes, that is a desirable solution; if so, it's a good idea to declare your singleton class final, which makes that intention explicit and allows the compiler to apply performance optimizations. The other solution is to put your singleton class in an explicit package, so classes in other packages (including the default package) cannot instantiate singleton instances.

A third interesting point about ClassicSingleton: it's possible to have multiple singleton instances if classes loaded by different classloaders access a singleton. That scenario is not so far-fetched; for example, some servlet containers use distinct classloaders for each servlet, so if two servlets access a singleton, they will each have their own instance.

Fourth, if ClassicSingleton implements the java.io.Serializable interface, the class's instances can be serialized and deserialized. However, if you serialize a singleton object and subsequently deserialize that object more than once, you will have multiple singleton instances.

Finally, and perhaps most important, Example 1's ClassicSingleton class is not thread-safe. If two threads—we'll call them Thread 1 and Thread 2—call ClassicSingleton.getInstance() at the same time, two ClassicSingleton instances can be created if Thread 1 is preempted just after it enters the if block and control is subsequently given to Thread 2.

Design Patterns

Observer Pattern ,
Inversion of Control Pattern ,
Singleton Pattern-1,
Singleton Pattern-2,
MVC Model-1 & Model-2,
IOCBeginners

Design Patterns

Design patterns are an extremely powerful tool for a developer or architect actively engaged in any development project. Design patterns ensure that common problems are addressed via well-known and accepted solutions. The fundamental strength of patterns rests with the fact that most problems have likely been encountered and solved by other individuals or development teams. As such, patterns provide a mechanism to share workable solutions between developers and organizations. This ensures that correct code is developed more rapidly and reduces the chance that a mistake will occur in design or implementation.

Just as object-oriented programming encourages code reuse, design patterns encourage design reuse.

In order to properly use a design pattern in your design, you must uphold three criteria

Understand your problem
Understand the pattern
Understand how the pattern solves your problem