0% found this document useful (0 votes)
143 views

Java Design Patterns

The Design Patterns document discusses several design patterns including Creational, Structural, and Behavioral patterns. Creational patterns like Singleton and Factory Method describe how to create objects in a way that is suitable for the situation and promotes flexibility. Structural patterns like Composite and Builder define how classes and objects are composed to form larger structures. Behavioral patterns like Observer and Command define communication between objects to distribute functionality between them.

Uploaded by

subhjit
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
143 views

Java Design Patterns

The Design Patterns document discusses several design patterns including Creational, Structural, and Behavioral patterns. Creational patterns like Singleton and Factory Method describe how to create objects in a way that is suitable for the situation and promotes flexibility. Structural patterns like Composite and Builder define how classes and objects are composed to form larger structures. Behavioral patterns like Observer and Command define communication between objects to distribute functionality between them.

Uploaded by

subhjit
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 6

Design Patterns

What are Design Patterns?


The core of solutions to common problems All patterns have: name, the problem they solve (in context), solution, consequences Types of patterns:
o o o

Creational - abstraction of instantiation process Structural - composition of classes and objects in formation of larger structures Behavioral - abstraction of algorithms and assignment of responsibility between objects

Creational Design Patterns:

Singleton - Ensure that only one instance of a class is created and Provide a global access point to the object.
The singleton pattern is one of the simplest design patterns: it involves only one class which is responsible to instantiate itself, to make sure it creates not more than one instance; in the same time it provides a global point of access to that instance. In this case the same instance can be used from everywhere, being impossible to invoke directly the constructor each time. Sometimes it's important to have only one instance for a class. For example, in a system there should be only one window manager (or only a file system or only a print spooler).

Example 1 - Logger Classes


The Singleton pattern is used in the design of logger classes. This classes are ussualy implemented as a singletons, and provides a global logging access point in all the application components without being necessary to create an object each time a logging operations is performed.

Example 2 - Configuration Classes


The Singleton pattern is used to design the classes which provides the configuration settings for an application. By implementing configuration classes as Singleton not only that we provide a global access point, but we also keep the instance we use as a cache object. When the class is instantiated( or when a value is read ) the singleton will keep the values in its internal structure. If the values are read from the database or from files this avoids the reloading the values each time the configuration parameters are used.

Specific problems and implementation

Factory Pattern
Intent

creates objects without exposing the instantiation logic to the client. refers to the newly created object through a common interface

Factory pattern should be used when: - a framework delegate the creation of objects derived from a common superclass to the factory - we need flexibility in adding new types of objects that must be created by the class The implementation is really simple The client needs a product, but instead of creating it directly using the new operator, it asks the factory object for a new product, providing the information about the type of object it needs. The factory instantiates a new concrete product and then returns to the client the newly created product(casted to abstract product class). The client uses the products as abstract products without being aware about their concrete implementation.

In the above flow diagram i have explained how to get the desired object based on the input (bus or train ) user has provided. for ex: www.makemytrip.com is the official site , where that site allow us to book train ticket as

well bus tickets and flight ticket also. In this case user can click either bus ticket link or train ticket link or flight ticket link.

we can not make the static binding with one class with one Travel Object , So there should be a intermediate class which takes travel type parameter then according to the parameter it will instantiate the desired object. The classes which i have used MyTravel : is the client class which take the travel type like : Bus or Train or Flight GetObject : is a generic class which will instantiate the Bus or Train and it returns the generic object. BusTravel : is POJO with the passenger name, Origin, destination parameters TrainTravel : is the POJO with the passenger name, Origin , destination parameters. Factory Method - Defines an interface for creating objects, but let subclasses to decide which class to instantiate and Refers to the newly created object through a common interface. Factory Method pattern should be used when: - a framework delegate the creation of objects derived from a common superclass to the factory - the base factory class does not know what concrete classes will be required to create - delegates to its

subclasses the creation of concrete objects - factory subclasses subclasses are aware of the concrete classes that must be instantiated Factory method pattern, compared to Factory pattern replace the factory with an abstract class and a set of concrete factories subclasses. The subclasses are responsible for creating concrete product objects; for factory method is possible adding new product classes without changing the abstract factory. The same result can be achieved for simplified factory pattern if reflection is used. Example : A class implementing factory design pattern works as bridge between multiple classes. Consider an example of using multiple database servers like SQL Server and Oracle. If you are developing an application using SQL Server database as backend, but in future need to change backend database to oracle, you will need to modify all your code, if you havent written your code following factory design pattern. In factory design pattern you need to do very little work to achieve this. A class implementing factory design pattern takes care for you and lessen your burden. Switching from database server wont bother you at all. You just need to make some small changes in your configuration file. What is Observer design pattern in Java? When do you use Observer pattern in Java? Observer - Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Applicability & Examples


The observer pattern is used when: the change of a state in one object must be reflected in another object without keeping the objects tight coupled. the framework we are writing needs to be enhanced in future with new observers with minimal changes. Some Classical Examples: Model View Controller Pattern - The observer pattern is used in the model view controller (MVC) architectural pattern. In MVC the this pattern is used to decouple the model from the view. View represents the Observer and the model is the Observable object. Ex: Let's assume we have a stock system which provides data for several types of client. We want to have a client implemented as a web based application but in near future we need to add clients for mobile devices, Palm or Pocket PC, or to have a system to notify the users with sms alerts. Now it's simple to see what we need from the observer pattern: we need to separate the subject(stocks server) from it's observers(client applications) in such a way that adding new observer will be transparent for the server.

Builder: Defines an instance for creating an object but letting subclasses decide which class to instantiate and
Allows a finer control over the construction process.

Defines an instance for creating an object but letting subclasses decide which class to instantiate Refers to the newly created object through a common interface

Example:

Example 1 - Students Exams.


If we have an application that can be used by the students of a University to provide them with the list of their grades for their exams, this application needs to run in different ways depending on the user that is using it, user that has to log in. This means that, for example, the admin needs to have some buttons enabled, buttons that needs to be disabled for the student, the common user. The Builder provides the interface for building form depending on the login information. The ConcreteBuilders are the specific forms for each type of user. The Product is the final form that the application will use in the given case and the Director is the application that, based on the login information, needs a specific form. Example 2: Different authentication mode in I4V: 1. Admin 2.Submission Manger 3:Reviewer

4:R estricted Reviewier

Composite:

The intent of this pattern is to compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

Example - Graphics Drawing Editor.


In graphics editors a shape can be basic or complex. An example of a simple shape is a line, where a complex shape is a rectangle which is made of four line objects

Command:
Intent
- encapsulate a request in an object - allows the parameterization of clients with different requests - allows saving the requests in a queue

You might also like