Up : SuckLine
As defined here : and http://schneider.blogspot.com/20040606schneiderarchive.html#108705336055598270 and discussed here :
Basically, it sounds like coupling should be through well defined, black-box, interface things.
(Increses potential coupling)
But at the same time, we should think about the design of those interface things so that if we opened them up, they'd also be easy to hack a lower-level connections. (Think about the assembly coupling)
"Dynamic Coupling" is when the assembly can occur at runtime. And be reconfigured as part of the negotiations of making the connection.
In the logical world (dynamic coupling) is quite easy. At the core, it means:
- We use policies to describe capabilities and interfaces.
- We publish the policies in a consistent manner.
- We perform protocol negotiation at runtime.
- We build components with high decoupling potential.
- We build components that were designed to connect to Dynamic Decoupling Devices.
- We quit hardcoding our assembly mechanisms.
- We mandate the use of Dynamic Decoupling in assembly.
See also :
- suddenly reminded of (WarpLink) DesignersDilemma which posits that design elements need to be assembled at runtime or rather by the user.
- Wilder associations : TopDownCausation and GrahamLally's EmergentNetworkProtocols
- Maybe this negotiation between broader compatibility and efficiency goes up and down the levels of scale. Which kind of reminds me of ConservationOfModularity