Proxy « Class « Java Articles

When software developers perform object-oriented analysis and design (OOAD), they strive to identify appropriate abstractions within a problem domain. Additionally, they label these abstractions with a specific name and usually provide some additional text to further clarify it. In the software construction and implementation phase, developers utilize Java to transform these abstractions into Java interfaces, classes, and methods. These constructs let you advertise an abstraction's purpose and functionality.

Overall, implementing a dynamic proxy is fairly simple. However, behind that simplicity is great power. That great power is derived from the fact that your dynamic proxy can implement any interface or interface group. I'll explore that concept in the next section.

This month's column expands on the ideas presented in July's column, "Building user interfaces for object-oriented systems, Part 1," by actually implementing a simple system for doing forms-based I/O. The main principle that I'm demonstrating here is organizational: I'll show you how to organize your code in such a way that arbitrary forms can be constructed automatically, minimizing the coupling relationships between the GUI subsystem and the underlying logical model (the "business" objects, if you will).

Programming with plain-old Java objects (POJOs) is rather popular these days. When we program with POJOs, we can apply object-oriented programming (OOP) pretty easily. But sometimes implementing cross-cutting aspects throughout an application using OOP proves difficult. For example, generally implementing logging or security in our POJO business objects throughout an application is difficult to achieve with OOP. Dynamic proxies, which were introduced in J2SE 1.3, offer an easier solution.

One of the challenges faced by the designers of the Web was dealing with the differences between operating systems. These differences can cause problems with URLs: for example, some operating systems allow spaces in filenames; some don't. Most operating systems won't complain about a # sign in a filename; but in a URL, a # sign indicates that the filename has ended, and a fragment identifier follows. Other special characters, nonalphanumeric characters, and so on, all of which may have a special meaning inside a URL or on another operating system, present similar problems. To solve these problems, characters used in URLs must come from a fixed subset of ASCII, specifically:

Here, Foo is the interface whose method calls are to be memoized, and FooImpl is the concrete implementation of Foo. The foo variable is an instance of the Foo interface; it behaves just like FooImpl, except that return values are cached. The beauty of the single Memoizer class is that adding memoization to any class is trivial: define an interface that comprises the methods to be memoized, then just call memoize with an implementation of the interface.

As part of this call therefore, I require you to authenticate and require that the communication have full object integrity. This way I know that the verifier I get back is, in fact, the verifier you intended to send. As a result of that call, then, I have a verifier object I know I can trust. I know I got the verifier object from you, and I know I got it intact. Now I can pass the suspect proxy object to the verifier and ask, "Verifier, do you trust this proxy object?"

Dynamic proxies provide an alternate, dynamic mechanism for implementing many common design patterns, including the Facade, Bridge, Interceptor, Decorator, Proxy (including remote and virtual proxies), and Adapter patterns. While all of these patterns can be easily implemented using ordinary classes instead of dynamic proxies, in many cases the dynamic proxy approach is more convenient and compact and can eliminate a lot of handwritten or generated classes.

All Swing components are JavaBeans components. They have a series of setter and getter methods that look like void setXXX(Type name) and Type getXXX(). There is nothing remarkable about the methods, and, as expected, they follow the JavaBeans naming conventions for properties. One aspect of JavaBeans components, which sets the stage for our discussion, is a pair of listener methods, addXXXListener (XXXListener name) and removeXXXListener (XXXListener name). The XXXListener referenced here is a listener object, extending the EventListener interface, that waits for various events to happen within the component associated with the listener. When that event happens, all registered listeners are notified of the event (in no particular order). Through the magic of a little reflection and the new java.beans.EventHandler class, you can attach a listener to a bean without directly implementing the listener interface or creating those annoying little anonymous inner classes.

Tivoli Directory Server and other LDAP directories are often used as back-end authentication services in multi-tier environments. For instance many single sign-on (SSO) software applications, such as IBM Tivoli Access Manager WebSEAL, can use LDAP systems to validate user credentials and to retrieve user profiles. Then they use this data to generate an authentication and authorization token that the user can present to access the Web applications.