Tag Archives: OOP

How to handle objects with a life cycle

In C++ and other programming languages, constructors are paired with destructors. These help to close file handles, database connections and the like in case the object is destroyed. Handling these objects in clear life cycles is a good idea anyways, but the need to do it is reduced, because there is a clearly defined way to clean up states.

In Java, destructors are not provided. Whether this is good or bad is a matter of debate and personal taste. The provided fallback with a finalize() method is discouraged as described in “Effective Java”.

But, what can be done now? We create objects with a clear life cycle!

Creating a life cycle is first a matter of API design. It needs to be clear (and documented) how the object is instantiated, initialized, started, opened, closed, stopped, and destroyed. Sometimes, other statesĀ  might be needed. Not all states are needed in one object. In case, there are all of these present, the class’s design needs to be questioned. In most cases the life cycle is handled by methods with the same name like the life cycle state (or with a verb of the name).

As example, let’s take this:

The two object we need to take care of are the returned Response and the InputStream.

Rule 1: The creator handles the life cycle

In the case above, it is trivial. The objects are created and closed in the same method or code block.

In case the object is returned from the method, the caller gets the responsibility to close the object It was is original request and gets therefore the responsibility delegated.

What about the case above in which two objects need to be closed? The response object’s life cycle is bound to the InputStream and we need to handle the life cycle in case of an issue in the method:

Rule 2: Methods must not manage life cycle of parameters

The sample above shows another issue: The input stream may be used as parameter for another method (for instance a parser). In cases like that, the close() method must not be called by this method.

Exception for Rule 2: Decorators can manage the life cycle

An input stream which is put into a decorator can be closed by the decorator. This can be found in the implementation of several input stream decorators in Java.

Implementation of a complex Java Iterator

In a lot of situations it is better to handle data as streams to keep the memory profile low and to decrease latency. To access data in such an environment, it is often useful to use iterators which collect data out of a stream and group them into objects and let the application use the stream like a collection of objects.

There are situations where it is not easy to implement a Java iterator with keeping the contract. Imagine a situation where a complex XML file is coming in via an InputStream and only a part of the XML file is to be parsed and aggregated into a dedicated Object. In this case keeping the contract is not so easy, because keeping hasNext() and next() in sync is complicated…

For this situation, I use a simple design which is implemented in PureSol Technologies’ Streaming Library:

The main advantage is the fixed implementation of hasNext() and next(), which is not to be changed anymore. Additionally, the whole logic to check for the next enty and to created if present was moved into a single method, so that there is no mismatch anymore between hasNext() and next(),

Another advantage can be that, there is also now the possibility to peek for the next entry:

Or a little bit more restrictive: