Introduction of J2EE Design Pattern

J2EE Design patterns are just convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is simple, write down and catalog common interactions between objects that programmers have frequently found useful.

There are three categories of patterns available,

• Creational Pattern
• Structural Pattern
• Behavioral Pattern

Creational Pattern: All of the creational patterns deal with the best way to create instances of objects. This is important because your program should not depend on how objects are created and arranged.

Following are the design patterns comes under creational pattern category

• Factory Method: It provides a simple decision making class that returns one of several possible subclasses of an abstract base class depending on the data that are provided.
• Abstract Factory Method: It provides an interface to create and return one of several families of related objects.
• Builder Pattern: It separates the construction of a complex object from its representation, so that several different representations can be created depending on the needs of the program.Prototype Pattern
• Prototype Pattern: It starts with an initialized and instantiated class and copies or clones it to make new instances rather than creating new instances.
• Singleton Pattern: Its a class of which there can be no more thanone instance. It provides a single global point of access to that instance.

Structural Pattern: Structural patterns describe how classes and objects can be combined to form larger structures.

Following are the design patterns comes under structural pattern category

• Adapter Pattern: Its used to convert the programming interface of one class into that of another. We use adapters whenever we want unrelated classes to work together in a single program. The concept of an adapter is thus pretty simple; we write a class that has the desired interface and then make it communicate with the class that has a different interface. There are two ways to do this: by inheritance, and by object composition.
• Bridge Pattern: Its used to separate the interface of class from its implementation, so that either can be varied separately.The Bridge pattern is designed to separate a class’s interface from its implementation, so that you can vary or replace the implementation without changing the client code.
• Composite Pattern: Its designed to accommodate invidual object or collection of objects. You can use the Composite to build part-whole hierarchies or to construct data epresentations of trees. In summary, a composite is a collection of objects, any one of which may be either a composite, or just a primitive object.
• Decorator Pattern: It provides us with a way to modify the behavior of individual objects without having to create a new derived class.
• Facade Pattern: It allows you to simplify this complexity by providing a simplified interface to these subsystems. This simplification may in some cases reduce the flexibility of the underlying classes, but usually provides all the function needed for all but the most sophisticated users. These users can still, of course, access the underlying classes and methods.
• Flyweight Pattern: This pattern provides an approach for handling such classes. It refers to the instance’s intrinsic data that makes the instance unique, and the extrinsic data which is passed in as arguments. The Flyweight is appropriate for small, fine-grained classes like individual characters or icons on the screen.
• Proxy Pattern: This pattern is used when you need to represent a complex object by a simpler one. If creating an object is expensive in time or computer resources, Proxy allows you to postpone this creation until you need the actual object. A Proxy usually has the same methods as the object it represents, and once the object is loaded, it passes on the method calls from the Proxy to the actual object.

Behavioral Pattern: Behavioral patterns are those patterns that are most specifically concerned with communication between objects.

Following are the design patterns comes under behavioral pattern category

• Chain of responsibility: This pattern allows a number of classes to attempt to handle a request, without any of them knowing about the capabilities of the other classes. It provides a loose coupling between these classes; the only common link is the request that is passed between them. The request is passed along until one of the classes can handle it.
• Command Pattern: The Chain of Responsibility forwards requests along a chain of classes, but the Command pattern forwards a request only to a specific module. It encloses a request for a specific action inside an object and gives it a known public interface. It lets you give the client the ability to make requests without knowing anything about the actual action that will be performed, and allows you to change that action without affecting the client program in any way.
• Interpreter Pattern: The Interpreter pattern generally describes defining a grammar for that language and using that grammar to interpret statements in that language.
• Iterator Pattern: The Iterator is one of the simplest and most frequently used of the design patterns. The Iterator pattern allows you to move through a list or collection of data using a standard interface without having to know the details of the internal representations of that data. In addition you can also define special iterators that perform some special processing and return only specified elements of the data collection.
• Mediator Pattern: When a program is made up of a number of classes, the logic and computation is divided logically among these classes. However, as more of these isolated classes are developed in a program, the problem of communication between these classes become more complex. The more each class needs to know about the methods of another class, the more tangled the class structure can become. This makes the program harder to read and harder to maintain. Further, it can become difficult to change the program, since any change may affect code in several other classes. The Mediator pattern addresses this problem by promoting looser coupling between these classes. Mediators accomplish this by being the only class that has detailed knowledge of the methods of other classes. Classes send inform the mediator when changes occur and the Mediator passes them on to any other classes that need to be informed.
• Memonto Pattern: Suppose you would like to save the internal state of an object so you can restore it later. Ideally, it should be possible to save and restore this state without making the object itself take care of this task, and without violating encapsulation. This is the purpose of the Memento pattern.
• Observer Pattern: The Observer pattern assumes that the object containing the data is separate from the objects that display the data, and that these display objects observe changes in that data. When we implement the Observer pattern, we usually refer to the data as the Subject and each of the displays as Observers. Each of these observers registers its interest in the data by calling a public method in the Subject. Then, each observer has a known interface that the subject calls when the data change.
• State Pattern: The State pattern is used when you want to have an enclosing class switch between a number of related contained classes, and pass method calls on to the current contained class. Design Patterns suggests that the State pattern switches between internal classes in such a way that the enclosing object appears to change its class. In Java, at least, this is a bit of an exaggeration, but the actual purpose to which the classes are put can change significantly.
• Strategy Pattern: This pattern is much like the State pattern in outline, but a little different in intent. The Strategy pattern consists of a number of related algorithms encapsulated in a driver class called the Context. Your client program can select one of these differing algorithms or in some cases the Context might select the best one for you. The intent, like the State pattern, is to switch easily between algorithms without any monolithic conditional statements. The difference between State and Strategy is that the user generally chooses which of several strategies to apply and that only one strategy at a time is likely to be instantiated and active within the Context class.
• Template Pattern: Whenever you write a parent class where you leave one or more of the methods to be implemented by derived classes, you are in essence using the Template pattern. The Template pattern formalizes the idea of defining an algorithm in a class, but leaving some of the details to be implemented in subclasses. In other words, if your base class is an abstract class, as often happens in these design patterns, you are using a simple form of the Template pattern.
• Visitor Pattern: The Visitor pattern turns the tables on our object-oriented model and creates an external class to act on data in other classes. This is useful if there are a fair number of instances of a small number of classes and you want to perform some operation that involves all or most of them.