Re: Immutable object returned by methid

opalpa opalpa@gmail.com http://opalpa.info wrote:

Thanks again for the response.


This is essentially the same idea as the immutable History
object -- whether implemented with the "immutable" keyword
which I want but doesn't exist, a subclass which throws an
exception when one of the setters is called, etc. I like
the idea -- especially if it's a subclass, since a
TermTypeHistorySnapshot isa TermTypeHistory and therefore
either can be sent to methods that require a TermTypeHistory.


The context here is that we're rewriting a legacy data entry
application, and we're keeping the same database tier & schema.
We're also keeping the same general look & feel of the existing
app. The schema stores the information, and the application
presents the information, in the manner I describe in my previous
post. So while I agree that there's no requirement for the
domain classes to represent the data in the same way, I don't
think varying from that representation would be a good idea.


This is just a standard concurrency issue, and exists whatever
we do on this tier. We're handling concurrency at the database
level, so in practice this won't be an issue.


The problem with that is that different types of history have
different numbers of elements that can be updated. A TitleHistory
needs one update method, since a title is a single property.
A UnitsHistory actually represents two properties -- min units and
max units, so it needs two methods. A CourseNameHistory actually
needs four -- prefix, numberPrefix, number and suffix (don't ask...).
So there's no common interface, even when you abstract the params
to the common base class (History, or as you wrote, Object).

The obvious response to that is to encapsulate the individual elements
into a single class, and pass an instance of this class to the update
method. But that's exactly what we're talking about with a Snapshot,
isn't it?

So in addition to having:

public class History {
  // Same as in previous post
}

public class UnitsHistory extends History {
  // Same as in previous post
}

I'd also have:

public Interface Snapshot {
  // I don't think I need any implementation here....
}

public class UnitsSnapshot extends UnitsHistory implements Snapshot {
  // Overrides getters from UnitsHistory and throws
  // an Exception in every one. Also overrides the
  // update method (see below) and throws an Exception.
}

Now my ContinuousHistory class can look like:

public class ContinuousHistory<T extends History> {
  // Mostly the same implementation as before

  // Same getter as before, but this time it returns a Snapshot,
  // which by definition is immutable.
  public T get(Term includedTerm) { . . . }

  // Generic update method. Since this is implemented in the
  // manager, and not the business object, it can ensure the data
  // are maintained according to all the rules. It also doesn't
  // care whether it receives an actual History object or a
  // Snapshot, since in either case it just reads from it.
  public void update(Term includedTerm, T newValue) {
     int index = findIndexWithTerm(includedTerm);

     historyData.get(index).update(newValue);

     fixDataAccordingToBusinessRules();
  }

Then every History subclass would get an update method, for example:

public class UnitsHistory extends History {
  // Same as before, with the addition of:

  public void update(UnitsHistory newValue) {
    setBeginTerm(newValue.getBeginTerm());
    setEndTerm(newValue.getEndTerm());
    setMinUnits(newValue.getMinUnits());
    setMaxUnits(newValue.getMaxUnits());
  }
}

So now, once a History is given to a ContinuousHistory to be managed,
there's no way to get a reference to the actual managed History object,
and therefore no way to change one without going through the
ContinuousHistory. The ContinuousHistory only returns snapshots, which
are immutable. Clients can send either History or Snapshot objects to
the ContinuousHistory. To change the actual data (which varies from
subclass to subclass of History), clients create either a History
subclass or a Snapshot implementation (doesn't matter which) and call
the update method in the ContinuousHistory. The update method finds
the History object being updated, and sends the input object on to its
update method. That class' update method knows how to get the class-
specific information out of the incoming object, and uses that info
to update itself. When the update returns back to the calling
ContinuousHistory.update method, any needed changes are made on the
Collection to enforce business rules.

Does this sound like it will work?

Thanks again for the replies -- it's always great to be able to bounce
ideas off someone....