Re: Class Constants - pros and cons

Tom McGlynn wrote:


On another branch of this thread, I wrote some code that actually
compiles, that described a `BigList` that had an `ElementIO`. I'm going
to put it here again for your reference. Hope no one minds.

package comp.lang.java.programmer;

import java.nio.ByteBuffer;

public interface ElementIO<T> {
     public void write(ByteBuffer bytes, int index, T item);
     public T read(ByteBuffer bytes, int index);
     public int getRecordLength();
}

package comp.lang.java.programmer;

import java.nio.MappedByteBuffer;
import java.util.AbstractList;

public class BigList<T> extends AbstractList<T> {
     private final ElementIO<T> io;

     private final MappedByteBuffer bytes;

     private int size;

     public BigList(ElementIO<T> io, MappedByteBuffer bytes, int size) {
         this.io = io;
         this.bytes = bytes;
         this.size = size;
     }

     // result is not `==` to value `set` so only use element type that
     // defines `equals` (and `hashCode`).
     @Override
     public T get(int index) {
         return io.read(bytes, index * io.getRecordLength());
     }

     @Override
     public T set(int index, T item) {
         if (index < 0 || index >= size) {
             throw new IndexOutOfBoundsException();
         }
         T result = get(index);
         io.write(bytes, index * io.getRecordLength(), item);
         return result;
     }

     @Override
     public void add(int index, T element) {
         size++;
         // probably off by one, but you get the idea...
         for (int i = size - 2; i >= index; i--) {
             set(index + 1, get(index));
         }
         set(index, element);
     }

     // and `remove` and the like, but of course only `get`, `set`
     // and `add` to the very end can be counted on to be performant.

     @Override
     public int size() {
         return size;
     }
}

With these generics we could build an implementation of `StarIO`.

public class StarIO implements ElementIO<Star> {
     public void write(ByteBuffer bytes, int index, Star item) {
         bytes.putDouble(index, item.getPosition[0]);
         bytes.putDouble(index + (Double.SIZE / Byte.SIZE),
                         item.getPosition[0]);
     }

     public Star read(ByteBuffer bytes, int index) {
         double[] position = new double[] {
             bytes.getLong(index),
             bytes.getLong(index + (Double.SIZE / Byte.SIZE))
         };
         return new Star(position);
     }

     public int getRecordLength() {
         return (Double.SIZE / Byte.SIZE) * 2;
     }
}

Usage is then like one big list. When you write, you don't actually put
the `Star` in an array, you write out the values. When you read you
create a new `Star` read from the underlying `MappedByteBuffer`.

Therefore, to my mind, the `Star` is an Adaptor for the
`MappedByteBuffer` where the strategy for an Adaptor is to:

Convert the interface of a class into another interface clients expect.
Adaptor lets classes work together that couldn't otherwise because of
incompatible interfaces.

Whereas the Flyweight strategy is to:

Use sharing to support large numbers of fine grained objects efficiently.

The solution we are discussing address the problem of supporting large
numbers of fine grained efficiently, but not through sharing.

Thus, there's an opportunity to name a new pattern, if you'd like.

I am not arguing semantics, I don't think, but really trying to
understand what patterns are in play. The interesting concept that makes
one think of flyweight is that the Adaptor is short-lived, which is why,
when you say Flyweight, the name seems apropos, but I believe there's a
pattern here that needs its own name.

This is the pattern that is used by any of the ORM tools. Create a short
lived typed object around a string or binary data for the sake of the
client.

--
Alan Gutierrez - alan@blogometer.com - http://twitter.com/bigeasy