Structural Patterns contd. - Bridge, Facade, Flyweight, Proxy
If you have directly reached to this article then you may like to first go through the first article on structural design patterns which covers what they are all about and discusses Adapter, Decorator, and Composite design patterns in particular.
Bridge Design Pattern
This design pattern is used to achieve the very basic purpose of Object Oriented Programming, which is to separate the interface of a class from its implementation. This approach has the obvious advantage of achieving the flexibility of being able to alter the implementation any time one wants to without affecting the client code using the class. Sounds similar to the Adapter Design Pattern? Well... it's actually similar to that, but the intent is quite different. The Adapter Design Pattern is used to enable the interfaces of one or more classes to look like and be compatible to the interface of a particular class whereas in case Bridge Design Pattern the class is designed in such a way that the interface is fixed and separate from the implementation. Here we don't have one or more classes to make compatible with the interface of some other class instead we separate the interface of a class from its implementation so that we can have the liberty of distributing the interface to be used by clients without being tightly tied to a particular implementation. Any future changes in the implementation won't affect the client code and this requirement can be really crucial in some cases. For example: if the class is being used to display some data then in future the revised implementation may be used provide additional details/graphs. This will only require to replace the older implementation with the newer one.
How can we implement this design pattern? Very simple... by just having an interface and subsequently implementing the interface in one or more classes. We of course need to have a fixed interface otherwise the very purpose of this design pattern to provide the flexibility of having a loosely coupled implementation won't be achieved.
Facade Design Pattern
This design pattern is primarily used to achieve simplicity. The pattern provides a simpler interface with no or little details of the underlying subsystems so that the normal users can simply use them in their client code easily. The advanced users can of course go to the subsystem level to achieve access to more detailed information.
Another obvious advantage of Facade Design Pattern is that it makes the normal client code independent of the particular implementations of the subsystems as the normal client uses the higher level interface having no details of subsystems. This facilitates any combination of the subsystems to work well for such a client without requiring any client code changes.
How to implement this design pattern? Just think of the higher level interface and extend that interface for different subsystems. Now you are free to have any implementation for the subsystems without being worried about the clients which used the higher level interface.
Flyweight Design Pattern
This design pattern is used in the cases where we have multiple instances with only little lighter (in terms of storage required) differences. In such a case we can have save externally that part (which is typically heavier) of the object state which is similar across the instances and make it shared so that all the instances can point to that. This will help us having only that data in an instance which is prone to change from one instance to another. Such an approach may allow the instances to offload the heavier part of their payload to one shared place in the memory and in turn we'll end up saving the space and the time to create that heavy part redundantly for every instance. Such an approach can be really helpful in the cases where the number of instances are quite high.
How to implement this design pattern? You can create a separate singleton class for the non-changing heavier part and in the actual class you can have a reference to that singleton instance. Not sure how to implement a singleton class? You may like to go through this article - Singleton Implementation in Java >>
Proxy Design Pattern
This design pattern is used to have a simpler object (often called the Proxy object) in place of the more complex object which actually serves the client requests. The simpler object passes the calls to the actual object, maybe after doing some manipulation or transformation. The simpler object makes the life of the client developer easy and s/he doesn't bother about the transformation and other low-level details which the Proxy object handles for them.
The stub and skeleton in RMI do a similar stuff. The client and the server only need to send the raw details to them and they take care of marshalling and unmarshalling.
How to implement this design pattern? Have a simpler higher level class (you can again use the Bridge pattern to design this class) and the method definitions of this class should actually do the required transformation and once the actual parameters are ready then they should call the corresponding methods of the lower level more detailed class which actually does the required stuff.
Liked the article? You may like to Subscribe to this blog for regular updates. You may also like to follow the blog to manage the bookmark easily and to tell the world that you enjoy GeekExplains. You can find the 'Followers' widget in the rightmost sidebar.
 |
RSS Feed (xml)
5 comments:
hi,geek
first of all thanks for your article of design pattern its very
nice.
i have problem to achieve pagination in java for display the search result.plz help me with example
Hi Ranvijay,
I'm afraid there isn't a standard way of implementing pagination. Different situations may demand different strategies to be followed. If you don't have huge data (result set) for a query you're not very much concerned about the scalability and memory (which is very unusual in a typical web applications) then you may like to read the entire data into a bean in the middle ware and from that bean you can build the different pages. You just need to iterate through the master bean to get he data for a particular page depending upon its page number and maybe you can either populate a temp page bean with that data or you may directly populate the view fields. This approach has the obvious advantage of minimizing the DB trips. Now, it's quite easy to understand that even if you've sufficient memory but if you have huge data then the first query will take too much time to get all the data back which may be frustrating for the end-users. So as already said this approach should be considered only in the cases where you're sure that a query won't result into too much of data to be returned.
If the query returns (or may return) huge data and if you're concerned about the scalability and memory requirements then you'll probably need to make more than one DB calls (which will eventually slow down the overall performance). You need to pass-on either the page number directly or some other computed data so that you can pick only those many records which you need for that page - maybe by putting appropriate values in the ORDER BY clause of the DB query. I hope this makes some sense :-)
To implement the view of the pagination you will probably need to associate all the page numbers with some servlet accepting a parameter identifying which page number it was called from. For example: you may associate page 1 with 1. How to find how many page numbers to display at he bottom/top? Well... first fire a query which returns you the count of the records and then based on this count you can easily calculate the page numbers. This approach has another advantage of mixing the above two approaches based on what he count is. That means if the count is low (which can be accommodated in 4-5 pages) then you'll probably prefer to get all the data in one DB trip only otherwise get data in chunks and prepare the pages from those chunks.
You would probably like to create separate temp beans in the middle tier for at least few pages (for many pages is again a situation dependent thing) so that if somebody clicks on already visited page then you have a chance of getting the already populated temp bean (instead of creating that every time that link is clicked). This will ensure the end users get a faster display of already visited pages.
If you're using Hibernate then you may like to have a look at the Criterion and Query interfaces.
Hope the above info helps you in finding a solution to your problem.
Thanks,
Geek
this is very helpfull to me
good works keep going
thanks
i have a problem in Ajax
can u help me
not call javaScript function through Ajax response
when i call a page test.jsp through
Ajax , then all the response is displayed , but java script function is not executed
Hi Amarjeet,
With AJAX you've got two ways of executing JavaScript functions - One, by using DOM to read the script and set it into the header and Two, by using eval() function.
Using eval() is quite easier (few people claim that it makes the processing little slower which you can check yourself how it behaves in your case). Just have the script code in some variable say 'innerHTML' and use 'eval' to execute it. Find below a sample code snippet:-
function sampleFun(divisionId, innerHTML){
var division = document.getElementById(divisionId);
division.innerHTML = innerHTML;
var scriptEle = div.getElementsByTagName("script");
for(var i=0;i<scriptEle.length;i++)
{
eval(scriptEle[i].text);
}
}
var innerHTML = "<script language=javascript> ... </script>"
sampleFun();
...
Hope this helps you rectifying the problem in your code. As already mentioned you can use the DOM approach as well to solve the problem.
Thanks,
Geek
Post a Comment