Contexts are useful for any architecture that needs an “abstract awareness” of its current state/scope.
A good example is generic macros. A macro may be given parameters, but it might also need to obtain information about the context that it’s running in. Also, the macro can store values that the next macro can obtain, etc.
Patterns:
- Dependency Injection
https://en.wikipedia.org/wiki/Dependency_injection
IContext and some of its implementations were originally written to be dependencies for macros.
- Bridge
https://en.wikipedia.org/wiki/Bridge_pattern
IContext is an abstraction that is completely separated from its implementations. But it provides a common way (a bridge) to use them.
- Collection/Container
http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/container.html
TContexts contains references to multiple instances of IContext.
- Composite
https://en.wikipedia.org/wiki/Composite_pattern
When interacting with a TContexts instance, you’re actually accessing any number of IContext instances as though they are one IContext instance.
- Chain of Responsibility
https://en.wikipedia.org/wiki/Chain-of-responsibility_pattern
TContexts passes a method call from one IContext instance to another until the call has been dealt with.