Re: Immutable object returned by methid

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


Thanks for the reply. Removing the setter isn't really an option.
I knew I was going to lose some important facts by abstracting the
problem down to a simple representation (Manager & Something). Let
me describe my actual problem domain more thorougly.

These classes represent university courses (class Course). A course
has a number of properties (prefix, number, title, minimum units,
maximum units, transferability, etc., etc., etc., each of which can
change independently from Term to Term. We have to keep track of
the entire history of a course. I have a base class History that
looks something like:

public class History {
  private Term beginTerm;
  private Term endTerm;

  // Getters, setters and convenience methods -- startsBefore(History),
  // endsAfter(History), etc.
}

Each property of a course has a class which extends History. Here
are two examples:

public class TitleHistory extends History {
  private String title;

  // Getters, setters, etc.
}

public class UnitsHistory extends History {
  private float minUnits;
  private float maxUnits;

  // Getters, setters, etc.
}

The idea is that class Course maintains Lists of these classes:

public class Course {
  // Not the final version of this class....
  private Term beginTerm, endTerm;
  private List<TitleHistory> titles;
  private List<UnitsHistory> units;
  // etc.
}

When it comes to these collections of history there are business
rules that must be followed:

-- The oldest history item must begin when the course begins.
-- The newest history item must end when the course ends.
-- There must be a value for every Term from beginTerm to endTerm
   with no gaps and no overlaps.
-- Two consecutive equal items should be merged into one. For
   example, if the title was "Integral Calculus" from Fall 2000
   to Fall 2003, and also "Integral Calculus" from Fall 2003 to
   Fall 2006, then this should become "Integral Calculus" from
   Fall 2000 to Fall 2006.

So I wrote a class to manage these business rules, and I want any
client to use the manager to manipulate the history. The manager
is actually called ContinuousHistory:

public class ContinuousHistory<T extends History> {
  private Term rangeBegin, rangeEnd;
  private List<T> historyData;

  // Clients use these methods to manipulate the data, which ensures
  // the business rules are applied.
  public void addHistory<T history> { . . . }
  public void removeHistory<T history> { . . . }
  public void changeRangeBegin(Term term) { . . . }
  // etc., etc., etc.

  // Here's where I start running into a problem. I need to expose
  // a Getter, so things like a data entry application can actually
  // see the values...
  public History getHistory(Term includedTerm) { . . .}

  // etc., etc., etc.
}

So my Course class actually looks like this:

public class Course {
  // Not the final version of this class....
  private Term beginTerm, endTerm;
  private ContinuousHistory<TitleHistory> titles;
  private ContinuousHistory<UnitsHistory> units;
  // etc.
}

and to get the title, min units and max units for some Term:

String title = titles.getHistory(term).getTitle();
float minUnits = units.getHistory(term).getMinUnits();
float maxUnits = units.getHistory(term).getMaxUnits();

Let's suppose we have title history for a course that looks like this:

   Fall 2000 - Fall 2003 Integral Calculus
   Fall 2003 - (null) Calculus II

Suppose the user discovers the date of the title change was wrong, and
it
really should be Spring 2002, not Fall 2003. Note that there are two
values that need to change. The ContinuousHistory does the work:

// Assume fall03 & spring02 are of class Term and are set appropriately.
titles.changeHistoryBegin(fall03, spring02);

By working through the manager, both values get changed, and the history
ends up in a consistent state:

   Fall 2000 - Spring 2002 Integral Calculus
   Spring 2002 - (null) Calculus II

This is all well and good [except a second question is how can I provide
a mutator method in the ContinuousHistory to change the actual title or
min units or max units values?]. If the client works throgh the
manager,
then everything stays consistent.

But since I exposed a getter, clients can do this:

titles.getHistory(fall03).setBeginDate(spring02);

Since I bypassed the manager, the data are now in an invalid state
(there is now an overlap):

   Fall 2000 - Fall 2003 Integral Calculus
   Spring 2002 - (null) Calculus II

Note that all these History subclasses are persistent business objects
that need setters for other reasons, so just removing the setters isn't
an option.

So now that I've given the long-winded explanation of what I want, does
it suggest a best way of implementing this? Your idea of the getter
returning a subclass that throws an Exception in the getters sounds
promising.

And now that I've covered that, let me ask the question I mentioned
above. Sorry for combining different questions into one post, but I
don't waat to repeat the long-winded explanation.

I want the ContinuousHistory to maintain mutator methods for the
business data. So if the <T extends History> is a TitleHistory, I
want to have a method:

public void changeTitle(Term includedTerm, String newTitle) { . . .}

but if it's a UnitsHistory, then I want:

public void changeMinUnits(Term includedTerm, float newValue) { . . .}
public void changeMaxUnits(Term includedTerm, float newValue) { . . .}

and if it's a CourseNameHistory then I want:

public void changePrefix(Term includedTerm, String newPrefix) { . . .}
public void changeNumber(Term includedTerm, int newNumber) { . . .}

etc.

I can't think of a good design to use here. Obviously since
ContinuousHistory works on instances of <T extends History>, I can only
add mutators for properties declared in the base class.

The one idea I had was to change ContinuousHistory so that it's no
longer generic, and instead is a base class for ContinuousNameHistory,
ContinuousTermTypeHistory, etc. But then I'd have to implement one of
those for every business class....and this is the kind of problem
generics were meant to solve. Am I missing an easier way to get what
I want?

Thanks again.