commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject [collections] Notifying/Observable design choices
Date Sat, 07 Jun 2003 17:07:15 GMT
Three possible designs (so far):

Proposal #1 (Heuer/MailingList)
--------------------------------
public boolean addAll(int index, Collection coll) {
  int oldSize = backingList.size();
  boolean returnVal = backingList.addAll(index, coll);
  int newSize = backingList.size();
  if (returnVal) {
    CollectionChangeEvent e = new
CollectionChangeEvent(this,oldSize,newSize,index,coll.size(),null,coll,true)
;
    support.fireElementsAdded(e);
  }
  return returnVal;
}
- One Event class.
- Event data chosen by us (so less flexible).
- Should handle all collections, but iterators will not be fail-fast.
- Should give reasonable performance.
- Relies on accurate result boolean.
- Relatively few classes


Proposal #2 (O'Toole):
-------------------------
public boolean addAll(int index, Collection c){
  this.throwIfIndexOutOfBoundsExclusive(index);
  ModifyingCollectionEvent event =
this.listEventFactory.createAddAllEvent(index, c);
  this.doFireVetoableEvent(event); // can throw a
CollectionModificationVetoedException
  boolean result = backingList.addAll(index, c);
  if (result){
   this.incrementModCount();
   this.doFirePostModificationEvent(event);
  }
  return result;
 }
- Event implementation class chosen by factory.
- Event data is theoretically flexible, but limited in practice. In
particular, the post-event cannot contain a copy of the state of the
collection, or the size before the change occurred (ie. you can't replicate
proposal #1)
- Unsuited to certain collections (eg. LazyList)
- Should give reasonable performance.
- Relies on accurate result boolean.
- Exception thrown from vetoed pre-events.
- Quite a lot of classes and concepts


Propsal #3 (Colebourne - merged from #1 and #2):
--------------------------
public boolean addAll(int index, Collection c){
  if (preAddAll(index, c)) {
    result = backingList.addAll(index, c);
    postAddAll(index, c, result);
  }
  return result;
 }
- Event implementation class chosen by subclass.
- Event data can be chosen by subclass.
- Should handle all collections, but iterators will not be fail-fast
(although subclass could include coding for that...).
- Will perform as per how you write the subclass. (Faster or slower)
- Subclass can choose whether to believe boolean result.
- Subclass can choose whether to use Listener pattern, or something else
(eg. call a static method)
- Choice of exception or ignore for vetoed pre-events.
- Relatively few classes, but subclasses may get have more classes


#3 explanation:
The class gets changed into an abstract one, with a real implementation or
two supplied in [collections]. Thus, AbstractNotifyingList would have the
method above, with NotifyingList as a subclass, managing event creation and
dispatch (using convenience methods from the abstract class.


Any comments, views or opinions on the three designs???
I guess I believe that #3 is the best compromise between #1 and #2 I can
think of (both #1 and #2 can be built using #3).

Stephen




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message