''(Building on MichaelFeathers's dangerous realworld analogy in LawOfDemeter - be careful when you use those things around these parts)''

What to do when, sometimes, you'd like your dog to be able to defend its encapsulation, and other times you'd like it to lay down and let the vet commence slicing? The traditional solution is to provide multiple interfaces, some more privileged than others. But if your vet moonlights as a jewel thief this leaves you in a quandary. 

Dereferencing Michael's analogy, the issue might be about library combination. The first instance I'm thinking of is mixing and matching STLs - I'm playing with bits of the M$, SGI and ObjectSpace STLs, and the gross division of their contents by namespace is sometimes inconvenient. What's really wanted is the ability to use some interfaces in some circumstances, and others in others, and for the libraries themselves to weigh proposals for use against some larger context. In short, an InterfaceMarket.

An automatic solution for this requirement is not obvious, but an external market-mechanism could allow us to make the bones of interface-contention explicit and variable at run-time. The solution I'm playing with (and not in static-binding C++! :-) employs (of course) a StoneSociety to control the function of and access to methods of each object. This goes a step beyond even the encapsulation violence of reflective architectures: not only could each object's innards be swallowed and swizzled on the fly, but actually re-implemented on the fly. Not only could interfaces be combined to provide one level of access to one user and another to another, but the users could contend directly at runtime for access to privileged interfaces. 

Apart from resolving library contention, real applications of such techniques might include scheduling access to precious network resources, context-dependent thread prioritization, and optimization of memory usage. Of course there are other ways to do these things too ... this is very speculative work and YMMV. -- PeterMerel.

-----

It would be interesting to have an automated system which would pick the Simplest (cheapest?) implementation by default, and then, based on feedback from the tests, try more expensive ones to see if it can find one which Works.
Are static types degenerate (micro) unit tests?
-----
CategoryInterface CategoryOptimization