Application-Scoped Object and Singleton Classes

I l @ ve RuBoard

Application-Scoped Object and Singleton Classes

As you design your application, you're going to find that most of the Beans that you use are session-scoped. You might find the occasional use for a request-scoped Bean, one that stays around only as long as the current request, but they're usually few and far between.

If you find yourself using application-scoped Beans, you might want to consider using a singleton class to map the object into the local session. A singleton has the advantage that only one copy can ever exist in a virtual machine, even if you accidentally throw away the reference to it. In contrast, you can create multiple instances of a class at the application level if you inadvertently use different ID names for the useBean . Singletons or application-level Beans are best for objects that are needed to share a common data set among many sessions or to provide a common computational function across many sessions.

A CASE STUDY WITH SINGLETONS

One example of using a singleton class is to have a separate class to do totals and subtotals on a shopping cart rather than put those methods in the cart themselves , which is a technique that I've used on an e-commerce project. I implemented an interface for a generic shopping cart and wrote a calculation engine that had a number of methods to do various subtotals, all of which took that interface as an argument. Then I had the folks developing the actual shopping cart class implement the interface for their class.

By doing this, we ended up with a calculation engine that was independent of the implementation of the cart itself. This meant that, theoretically, we could reuse the calculation engine in other projects, even if they implemented a different shopping cart.

Because we needed only one calculation engine for the application, we implemented it as a singleton class that could be called at will to get the one instance. We never had to worry about leaving copies lying around somewhere in memory or be careful the overhead of creating a new instance each time we needed it because only one was ever created; all subsequent calls to the factory simply returned the same object.

The only caution with this approach is that it is not thread-safe. In the case of the calculation engine, no state is associated with the object, so there is no danger that two threads could change some attribute of the single object at the same time. However, this might not always be the case. If there is the potential for mayhem if two threads are changing state in the class at the same time, you must either define the methods as synchronized or use multiple instances.

I l @ ve RuBoard


MySQL and JSP Web Applications. Data-Driven Programming Using Tomcat and MySQL
MySQL and JSP Web Applications: Data-Driven Programming Using Tomcat and MySQL
ISBN: 0672323095
EAN: 2147483647
Year: 2002
Pages: 203
Authors: James Turner

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net