views:

111

answers:

1

Hey there!

We've been hit with a pretty "obvious" problem while designing a collections infrastructure: suppose you need to implement many (sub)types of collections. One of the aspects is storage-related: list, array etc, while the other is behavior-related: ordered, remove only, observable (the one that fires an event upon every change) etc.

Obviously (again), the requirement maps directly to the well-known Decorator design pattern (list, array), where the storage-related aspect will be decorated by multiple behavioral (ordered, observable etc).

It would be great to know about something similar that had been already implemented by someone. Hence, if possible - please recommend/refer to any well-maintained third-party library that would meet the requirements, mentioned above.

Thanks so far :)

+1  A: 

I think you misunderstood something:

Decorators are used to modify and add behaviour primarily at runtime. But the properties of collections that you cited need to be available at compile time. A decorator is completely unsuited to add more methods to an existing class.

While it is possible to decompose these traits of collections into interfaces (and indeed has been done 1)), this isn’t really what a decorator is about: a decorator wraps an existing class implementing the same interface. For collections, inheritance will make more sense (or may indeed be required) instead of composition.


1) A few years, I started developing my own such library, Containers.NET but since preliminary benchmarks showed just how much faster the native .NET containers were, even though Containers.NET did not have any added overhead, I stopped the project before it got very far.

Konrad Rudolph
http://stackoverflow.com/questions/3133176/collections-as-decorators-pseudo-code-implementation-proposal - Here I've asked more general question (hope it's okay). I read your point. Just wanted to take the Decorator idea one step further, i.e. enrich the behavior in runtime and interface both in compile-time and runtime. Why compile time? Because I want to instantiate an Observable, Ordered, ReadOnly, ThreadSafe List instance. And be able to call all the methods like "add/remove()", "sort() and "notifyChange()", for example.
BreakPhreak
@BreakPhreak: I’ve read your other question, that’s how I came here. I still think you’re basically operating on a misconception. Or otherwise, I don’t understand what exactly you are trying to achieve.
Konrad Rudolph
PS: maybe someone took your idea further or developed his/her own alternative. Would be interesting to know that such a product exists.
BreakPhreak
I'll try to rephrase. Term-less-wise, I'd like to use some collections framework, where aspects can be dynamically constructed into any possible combination (in contrary to OrderedReadOnlyThreadSafeList, for example, I would like to have Ordered, ReadOnly ThreadSafe and List implemented separately, but combineable in compile/run time). Does my goal sound better this time?
BreakPhreak