It's mediators all the way down.
-
I've been re-reading Arthur J. Riel's classic "Object-Oriented Design Heuristics." One thing that I've found striking on this re-reading is how much Riel emphasizes the use of the mediator design pattern (though he doesn't refer to it as such). Specifically, it's heuristic 4.14: "Objects which share lexical scope, should not have uses relationships between them." What this means, basically, is that objects that exist at the same level of abstraction shouldn't be communicating with each other. Rather, they should be communicating with an object at a higher level of abstract which in turn takes the appropriate action and communicates any necessary info to the other objects at the lower level of abstraction, in other words, the mediator pattern. (as an aside this heuristic conflicts somewhat with heuristic 4.13. Riel addresses this by suggesting the use of abstract classes, i.e. interfaces, as a means through which children communicate with their parents) There are at least a couple of reasons for this heuristic. One, it promotes decoupling and reuse. If the objects at the same level of abstraction don't know about each other, they're more likely to be reuseable. Two, it lowers complexity. Instead of a many-to-many relationship between objects, you have a one-to-many, i.e. the mediator has a one-to-many relationship with its child objects. One-to-many relationships are easier to reason about and understand. Following this heuristic, you can wind up with a layered approach in which each layer is made up of mediators. The child objects are in turn mediators to their child objects, and so on. I like this idea in that it seems to strike a balance between a hyper object oriented approach in which objects are tangled together in a complex many-to-many web of connections and a strictly procedural approach in which nothing is connected. I'd never thought of mediator in this light before.
-
I've been re-reading Arthur J. Riel's classic "Object-Oriented Design Heuristics." One thing that I've found striking on this re-reading is how much Riel emphasizes the use of the mediator design pattern (though he doesn't refer to it as such). Specifically, it's heuristic 4.14: "Objects which share lexical scope, should not have uses relationships between them." What this means, basically, is that objects that exist at the same level of abstraction shouldn't be communicating with each other. Rather, they should be communicating with an object at a higher level of abstract which in turn takes the appropriate action and communicates any necessary info to the other objects at the lower level of abstraction, in other words, the mediator pattern. (as an aside this heuristic conflicts somewhat with heuristic 4.13. Riel addresses this by suggesting the use of abstract classes, i.e. interfaces, as a means through which children communicate with their parents) There are at least a couple of reasons for this heuristic. One, it promotes decoupling and reuse. If the objects at the same level of abstraction don't know about each other, they're more likely to be reuseable. Two, it lowers complexity. Instead of a many-to-many relationship between objects, you have a one-to-many, i.e. the mediator has a one-to-many relationship with its child objects. One-to-many relationships are easier to reason about and understand. Following this heuristic, you can wind up with a layered approach in which each layer is made up of mediators. The child objects are in turn mediators to their child objects, and so on. I like this idea in that it seems to strike a balance between a hyper object oriented approach in which objects are tangled together in a complex many-to-many web of connections and a strictly procedural approach in which nothing is connected. I'd never thought of mediator in this light before.
The use of the Mediator is a common technique in MVVM to provide cross-communication between ViewModels without requiring complex communication infrastructure. It's a great way to keep them decoupled.
Forgive your enemies - it messes with their heads
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
-
I've been re-reading Arthur J. Riel's classic "Object-Oriented Design Heuristics." One thing that I've found striking on this re-reading is how much Riel emphasizes the use of the mediator design pattern (though he doesn't refer to it as such). Specifically, it's heuristic 4.14: "Objects which share lexical scope, should not have uses relationships between them." What this means, basically, is that objects that exist at the same level of abstraction shouldn't be communicating with each other. Rather, they should be communicating with an object at a higher level of abstract which in turn takes the appropriate action and communicates any necessary info to the other objects at the lower level of abstraction, in other words, the mediator pattern. (as an aside this heuristic conflicts somewhat with heuristic 4.13. Riel addresses this by suggesting the use of abstract classes, i.e. interfaces, as a means through which children communicate with their parents) There are at least a couple of reasons for this heuristic. One, it promotes decoupling and reuse. If the objects at the same level of abstraction don't know about each other, they're more likely to be reuseable. Two, it lowers complexity. Instead of a many-to-many relationship between objects, you have a one-to-many, i.e. the mediator has a one-to-many relationship with its child objects. One-to-many relationships are easier to reason about and understand. Following this heuristic, you can wind up with a layered approach in which each layer is made up of mediators. The child objects are in turn mediators to their child objects, and so on. I like this idea in that it seems to strike a balance between a hyper object oriented approach in which objects are tangled together in a complex many-to-many web of connections and a strictly procedural approach in which nothing is connected. I'd never thought of mediator in this light before.