'''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.