commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Takuya Murata <tak...@manjiro.net>
Subject Re: [collections] Questions....
Date Thu, 21 Aug 2003 02:14:11 GMT

> I personally have a problem with the use of the class name Singleton.
> Singleton is a well known pattern for only having one instance of an 
> Object
> in an environment, this class does not achive this. I would think a 
> name
> likeSingleEntryIterator/TrivialIterator/MonoIterator or some such 
> would be a
> better descriptive name.

Good point. A term singleton is certainly misleading given design 
patterns have such presence now. I like SingleEntry. It sounds 
intuitive.

>> To me, this solution sounds good. There is no tricky choice whether
>> SingletonIterator or SingletonListIterator. And we can avoid a big
>> xxxUtil classes instead of small objects and classes, resembling
>> traditional imperative languages such as C.
>
> The whole point of Iterator is that it is collection type independent 
> - no
> matter what data structure in place iterator should supply you with 
> every
> Object in it - ordering appropriately if required.
>
> If it is being used for code expecting a ListIterator I would say that 
> that
> code needs to be made more agnostic of the underlying implementation 
> (given
> that you would be using this quick method of supplying just the one 
> value).
> Though in fairness making it return a ListItertor (but keep the 
> signature to
> Iterator) would be no big deal.

Not sure what you meant.

>> I am not sure if it is valid with the contract of interfaces to
>> implement both Set and List because ListIterator doesn't make sense
>> with listIterator but it doesn't look elegant to have two
>> SingletonList
>> and SingletonSet classes.
>
> Perhaps it would be better to create a class SingleEntryCollection 
> which
> extends collection and implements the iterator method as well as the 
> rest.
> The cost is one additional object for your siple use case but it may 
> provide
> a clearer picture of what is being performed...

Why do you think implementing Collection is better rather than List?

We can forget about Set because Collections.singleton returns it. Need 
of SortedSet is probably rare enough to be ignored. SingletonMap 
probably is useful when you need an iterator returning Map.Entry.

class SingleEntryMap {
   SingleEntryMap (Object key, Object value);
}

> If the Collection itself
> implements Iterator then it can just return itself in response to the
> method. I can't see a name clash except remove() and they are different
> signatures in both return type and parameters...

No, equality should be a problem as you pointed out. No? Besides, a 
class that is a collection as well as iterator might be confusing. The 
only way to avoid an additional object I think is use factory methods 
in xxxUtils. In that way, one class can implement collection and 
iterator without confusion.

> If I'm missing the point of what you're trying to do here let me know

My point is if we can more generalize this problem. I thought if we 
have a collection for solo object, while such class is useful, then we 
can get an iterator for it easily and more importantly in the way that 
is common and intuitive using iterator() and listIterator().

Having two classes for Iterator and ListIterator respectively is 
straightforward than SingletonListIterator for both.

Anyway, I like SingleEntryCollection too. It is more general than 
having classes for rather exceptionally rare use.

Takuya Murata


Mime
View raw message