'''Definition:''' A tee adapter splits a datastream. Works like the Unix tee command to allow splitting of a datastream. This is a "copy" style split i.e. it is not the same as a MuxAdapter . '''Uses:''' Used for contingency streams, monitoring streams, debugging streams etc. '''Variations:''' An intelligent tee filters the stream or looks for specific patterns in the stream e.g. a Password snooper on a network. '''Example implementations:''' This may be composed of a simple tee object plus a filtering object. The filter may be wrapped around the tee, or may be imported using a plug-in style visitor pattern. There is an overhead of a dependent object but this design has all the advantages of OO. A custom monolithic intelligent tee runs the filter logic inline, avoiding the method calling overhead. Functional languages can combine the approaches, synthesizing filters by one-time specification. I'm sure there are other possibilities, but they all perform the same microarchitectural function, physically replicating a [filtered] stream of data transparently. ---- '''Honorable Feedback:''' One might want to split up the intelligent tee filter into a tee adapter and a filter. This probably leads to a design which is easier to understand and reuse. But an intelligent tee may be much faster and more efficient at execution time than reusable components. Thanks for the feedback :). You're right. I am trying to remain very slightly abstract from the implementation details i.e. this describes a physical function, but shouldn't (I hope) be overly prescriptive on its implementation. My intention is that these objects will be the target of a generator. Logical OO may well be sacrificed in optimization, though they will certainly tend to start as a bunch of objects as you describe. I've adjusted the definition accordingly.