Thursday, 31 May 2012
It is common to accomodate multiple service providers while designing an API. Each service provider may implement a use-case that will be used by API client applications. For example, Java security has a number of providers SunJCE, BKS etc which provide security operations such as encryption. Two common patterns that come into play involve defining service provider interfaces, factory classes/methods to get the appropriate target object. Service provider interface is implemented by the service provider classes and there may be more than one type of class that provides a functionality like encryption. There are DESCipher, AESCipher etc all of which implement CipherSpi which is the service provider interface definition. Again the Cipher engine class encapsulates a CipherSpi and creates the appropriate cipher through its factory method getInstance(). The provider list is usually read from a configuration file. Here we use a simple example to demonstrate spis, spiImpls.
Suppose we want a logger. We can define the logger spi which has the functionalities that we want from a logger. We provide two implementations of this spi and annotate the classes with spiImpl. This annotation is not mandatory. The class name can be anything but, if name conventions are followed then, code becomes maintainable in addition to being simpler. The engine class can be Logger which takes a string parameter which specifies whether we need a File based logger or a Console logger. The Logger class acts like a factory for creating Logger classes and allows client apps to perform logging through it. Although this is a small example, it gets the idea across. SPI, SPIImpl classes are very frequently used in Java 2 Enterprise projects just like Facade pattern. The spi pattern allows us to add different types of providers and also implementations of the interface.
Here is the structure for the project packages.
The sample SPI
Spi Implementation example
Application using Logger
Posted by Harisankar at 09:04
Monday, 14 May 2012
Object oriented programming involves instances of classes i.e objects interacting with one another towards a common goal. This interaction can be for services, control or data. Objects perform a particular function in a software. When there are a lot of objects the code becomes cumbersome to maintain and use; every time in the same piece of software.
Facade pattern comes into action when you have a subsystem that performs a particular service for another subsystem or part of the code. A subsystem here in terms of software code means a group of objects interacting to get a job done. Facade pattern hides the objects underneath it and their interactions to object layers above the pattern. For example, information collected from the user interface in a java application may be used to create say, a user object, account object and the user interface may store this to the database by using an object that performs that database operation. Here a Facade object can expose an operation, i.e creating the objects from the data from UI and storing it to the database. This facade can be used by the UI without delving into the details of how it is done.
If the interaction of the objects in the facade changes, it is contained within the facade and no layer of code outside the facade is affected. This is the most important aspect of the facade pattern that makes it so useful in Java Enterprise where this pattern is more frequently seen in popular Java Enterprise IDE's ready-made-code.
For example, suppose there is a table in the database that stores the details of attendees in a conference. Java enterprise wraps this with an Entity say, Attendee entity which would be part of the JPA ready-made-code. This entity will expose the database operations on the table. A facade would be created namely a session facade which exposes operations that are utilised by controller layers to update information. The session facade will deal with the requests on the Attendee Entity.
Here is an example of the code structure for a Tomcat based application that gets information in a table. Called from a servlet. i.e servlet is the controller in Model-View-Controller Application model.
as you can see from this code, the facade is called to do the job. The code to get a job done becomes small as far a controller object is concerned. A lot of things may happen under the facade but, the higher layer object does not care about this. It is the Facade's responsibility. The code structure in eclipse web project is shown below. There are entity objects and Facade objects. Facade objects here share a common ancestor which declares common operations on entity-facades. In this example, entity objects simulate the JPA entity objects.
The abstract facade is not a must in the general facade pattern but, is used here as is further simplifies code with inheritance. A part of abstract facade is shown here
A subclass of this called Attendee Facade used in our example is here
A lot of object interactions and code is thus abstracted from a controller object / higher level object by using the Facade Pattern. It also makes the code more reusable, maintainable, predictable and beautiful.
Posted by Harisankar at 11:15