Tuesday, June 29, 2010

Adapter Pattern

In computer programming, adapter/wrapper pattern is a design pattern that translates one interface or class into compatible interface. This pattern enables incompatible classes to work together by providing compatible interface of original class to its client, i.e. this pattern translate calls made by client to interface into a calls to the original class/interface. The adapter class is also responsible for converting data responded by original class/interface to be converted into form easily understandable by client. For example if interface evaluates a call into a Boolean which client expected it to be integer 1/0 then it is responsibility of adapter class to evaluate a call response into format that is understandable by client class.

There are two types of adapter pattern:

  • Object Adapter pattern: In this pattern, adapter class contain object of class it wraps, i.e., adapter class redirect calls from client class to the wrapped class.
    It uses Composition method for adapting Adaptee and this adaption can be extended to sub-class of Adaptee
    Object Adapter class delegates execution of behaviour to Adaptee class
  • Class Adapter pattern: In this pattern, multiple inheritance is used to address the issue. Interface of existing implementation as well as interface of expected implementation is inherited by the adapter class so that it behaves as an expected implementation. This type of implementation is used in situation where existing implementation provide some or all of the services expected but does not use expected interfaces.
    It uses Inheritance method for adapting Adaptee hence Adapter class doesn't requires to reimplement entire Adaptee class, but only needs to override the behaviour of Adaptee class that varies.

Flow of control in Adapter pattern

  • Client makes an request to Adapter class by invoking its method using Target interface.
  • Adapter object translate this request into single or series of method call to Adaptee object.
  • Client receive back the response, without knowing that translation is done by Adapter.

Object Adapter Pattern

Object Adapter Pattern class diagram

Class Adapter Pattern

Class Adapter Pattern class diagram

Note: Adapter pattern is never implemented when designing a new system but with the changing requirements we have deferring interfaces then adapter comes into picture.

Monday, June 21, 2010

Object Pool Pattern

Performance can be sometimes the key issue during the software development and the object creation (class instantiation) is a costly step. While the Prototype pattern helps in improving the performance by cloning the objects, the Object Pool pattern offers a mechanism to reuse objects that are expensive to create.

The Object Pool pattern offers mechanism to reuse/recycle objects that are expensive to create or are no longer need.

Object pool pattern is advisable to use in a situation where several client may need the same stateless object which is expensive to create.

Benefits of using Object Pool pattern are:

  • Pattern can improve performance of application as it help in reducing time for creation of expensive object.
  • Pattern helps in sharing unused object between multiple clients thereby improving memory usage and can result I overall reduction in memory footprint of application.
  • Additional memory management routine will not be required as resource user will acquire and release resource transparently.

The Consequences of this approach include:

  • In concurrent environment acquisition request for the resource needs t be synchronized in order to avoid race condition and possibility of corrupting associated state.
  • In case if resource users are involve in eager acquisition polling approach will fail.

Thursday, June 3, 2010

Eager Initialization Pattern

As name suggests Eager Initialization approach creates/initialize an object with anticipation, regardless of whether or not it will be required in program.

Definition: The Eager Initialization pattern describes how run-time acquisition and initialization of resources can be made predictable and fast by eagerly acquiring and initializing resources before their actual usage.

Eager initialization pattern at first glance seems an un-efficient pattern, but in situation where application is required to be reliable and predictable with no downtime this pattern comes handy. As and when an object/variable is declared or when the object in which it lives is created [declaration or constructor] object/variable is initialized.

Eager initialization approach should only be used

  • When initialization of the instance variable would consume large amount of time and downtime of application is not acceptable.
  • In pooling solution where it will require pre-acquire a number of resources in order to quickly serve first requests.
  • A Hamster application. Like hamster which acquires as many fruits as possible before eating them in its cave, Hamster application will acquires as many resources before it’s actually execute application.

The benefits of this approach include:

  • Increase in predictability of application as user requests for resource acquisition are intercepted and served instantly.
  • Application response time is very low as resources are pre acquired.
  • Assurance of the variables been initialized before they are used.

The Consequences of this approach include:

  • As all the resources are eagerly acquired at the start of the application, the start-up time for the application is longer.
  • Eager Initialization might initialize many objects upfront, which may not be required by system. This may introduce unnecessary exhaustion or overuse of memory resources.
  • Management of eagerly initialized object becomes an important aspect as not all the resources might require immediately in application.