Cat Offshore Java Developer

Object Slicing and Component Design with Java.

Object-oriented systems are usually partitioned into layers of related responsibilities and only dependencies in one direction are allowed, from higher layers (more specific, less reusable) to lower ones (more general, more reusable). Classes in higher layers can extend or wrap classes in lower ones, but not the other way around. However, they can register themselves as event listeners with classes in lower levels through a generic interface. A component resides in a single layer, which can be itself divided in multiple levels of separate concerns. For example, a business component residing in the domain layer consists not only of business logic, but also of other types of functionalities, like database persistence, lifecycle callback methods or upper layer event notification. A level is created for each such type of functionality, and the component is divided into level specific classes, with those in higher levels enhancing some in the lower ones. If components live in a container of some sort, some levels will probably have to deal with container related services, and the classes in these levels may be generated. Ideally, the lower levels have to be oblivious of any enhancements in levels above them. One of the following three approaches is usually chosen to handle the layer/level dependencies:

1. Each layer/level of the system has its own types, and a conversion is needed when crossing boundaries. A lot of data copying is going on, and logic is duplicated. 2. A class in a higher layer/level enhances one in a layer/level below by using composition. If relationship maintenance is needed, it may have to be duplicated at the wrapper level. 3. A class in a higher layer/level enhances one in a layer/level below through extension. But upcasting does not prevent a user of objects of the base type to downcast them to the derived type and use the enhancements, so additional work is needed if true obliviousness of the enhancements is desired. Also, if the derived class overrides methods from the base class, the lower layer will get access to functionality or data representations that were designed for the above layer.

While each approach has its advantages and disadvantages, the third one seems to be the choice in a lot of JDO and EJB implementations. Most of the experts advocate using inheritance for enhancing business objects with persistence logic by using a two level domain design. However, this approach does not address the overridden methods issue (which in many cases could be acceptable). This is going to be

addressed by presenting a simple technique that achieves obliviousness to both kinds of enhancements allowed by inheritance: new and overridden methods. Object Slicing : Object slicing is defined as the conversion of an object into something with less information (typically a superclass). In C++ it occurs when an object is passed by value and copying the parameter value results in an upcast and it is considered a bad thing, as it may result in very subtle bugs. Object slicing throws away information. But in some situations this may be exactly what we want. In Java, objects are passed by reference, and all methods are virtual, so object slicing will not occur inadvertently. Even if you upcast an object, its real type is not forgotten, that's the definition of polymorphism. Let’s consider the simplest version of object slicing. Suppose class Derived extends class Base, and we have an object of type Derived. We want to "extract" the base part from it. This does not work, because the compiler will make sure you put a dot after super, followed by a valid identifier.

Also, it does not help to return a reference to this from the Base class (which is equivalent to an upcast), because this is polymorphic. Overridden methods will be invoked instead of those defined in the Base class, and any additional methods would also be available for invocation. That is exactly what we want to avoid. We want a proxy to the base type part of an object, not just to restrict the interface, and not just a copy of the data and behavior.

We could create a proxy to a base type of an object this way: for a subclass of that base type where a method is overridden, we also add a (final) method invoking the overridden method using super. Then we create a wrapper to forward the calls to the right methods. But this is not elegant, and it requires keeping track of too much information. The object oriented way of doing it is using inner classes. Also, we cannot use dynamic proxies to avoid implementing each method from the base class, because we cannot invoke a method with reflection on super. How to do Object Slicing in Java : Let's recall that a (non-static) inner class needs an instance of the enclosing class in order to be instantiated, and all members of the enclosing object (including those with private access) are accessible from the inner class.

Our idea is to exploit this feature and the fact that unlike this, super is not polymorphic. In the Derived class, extending Base, we define an inner class Slice, which also extends Base and overrides all the methods in Base by forwarding them to the base part of the enclosing object. The getBase() method in the Derived class returns an instance of Slice, which in a way is a proxy for the base part of the object. When thinking of object handles in Java, the analogy with a remote control (handle) for a TV set (object) quite helpful. With this terminology, we want to produce a second remote control that would work only with a part of the TV set, let’s say the sound.

The advantage of doing so is that, we can use composition instead of inheritance by making the Derived class hold a reference of type Base, which would be initialized in a constructor or assigned by using a setter method. This is not always a good idea. Imagine that we have a class Human that needs to be enhanced by the classes Male and Female. It does not make sense to require that Male and Female instances are built out of preexisting Human instances. We have a genuine IS-A relationship here, and the Male and Female classes should extend the Human class. And if we want to disallow discrimination based on type in one of our layers (i.e. we want to work only with Human types), we need to excise the extra information or behavior modifications introduced by the subclasses. What is usually done in order to accommodate this need is to copy the relevant data from a Male or Female object into a new object of type Human. A proliferation of layer specific types occurs when this is done, and a conversion is needed when crossing a layer boundary. Persistence Logic and Domain Design : The possible need for object slicing is very much when working with Domain and Data Access Objects. These contain the business and persistence logic, respectively. Although one could combine them in the same class as it is described in the Active Record pattern, or in many EJB books, in most cases it is not acceptable to do so. These are the most common ways of dealing with the relationship between the business logic and the persistence logic:

1. One class approach: put them in the same class 2. Service oriented or façade approach: put them in 2 different classes and pass one as an argument to a method of the other 3. Component oriented approach: put them in 3 classes

Each choice has its advantages and disadvantages. Of all there is an advantage for a persistent instance for each domain instance because it offers more options (for example we can use the persistent instance directly or drive it from a BMP EJB).

Final Remarks:

* In a way we are also using composition, as an inner class has a reference to its outer object. But the use of the inner class allows making a call to the super of the outer object in a very clean way. If you want to do this with a wrapper you would have to add methods to the wrapped class in which you would call the overridden methods (this is polymorphic, super is not). * We can use a variation of this idiom, where the proxy slice is initialized with the outer object's data (using a constructor, or an instance initializer, perhaps with reflection). This data can be used as temporary in-memory storage of changes, before committing them to the outer object. Or we can implement undo operations this way.