Monolithic software products (those with a multitude of highly coupled components) are often blamed on the use of procedural languages, but it's just as easy to produce overly interdependent classes in object-oriented languages. Stephen B. Morris shows how using the mediator design pattern can help reduce class interdependencies, aid componentization & ultimately help make classes service-oriented.
To read all comments associated with this story, please click here.
Member since:2005-06-29
This is very very true. So true that I spend most of my time rewritting my code and the code of others (more experienced than me sometime) to provide better reusabilty. And it's difficult to do, but it is possible. So if one spend time writting a good class using the correct pattern, why would he need a "mediator" in the first place? Furthermore there is chances that if the implementation is already wrong, the mediator won't make things more right.
2. Nowaday C++ is still evolving very fast and it's been some time that one major improvement have been around, and this improvement helps a lot to solve the problem tackled by the mediator: it is called a "concept". Typically "concept" are used with "templates". As in the exemple you want to allow a certain number of interaction with your class. Instead of writing a "mediator" that you have to maintain, you write your class using a template argument and define your template with a serie of concept. Those concept will garantie that requirement for your templates are met and it with template you gain genericity: which helps a lot in protability.
That is a completely naive proposition you make. There are times were you need to use such patterns or similar. In fact, this pattern is most commonly used when designing plug-in systems. You have an object, a mediator, that acts like a manager. Its sole purpose is to inform other objects of what is going on in the system. I prefer to use a signals system for communication. In a very well designed system, objects interact with themselves and the mediator only. This is essential to reduce coupling. The alternative is having objects in each others business and dangerously playing around with each others properties. Using a mediator is not bad practice. In fact it's one of the easiest ways to reduce coupling in systems. Almost all large scale systems use mediator-like patterns to allow objects to communicate with each other via an established protocol, plug-in systems especially.
Edit: Removed repeatition.
Edited 2006-05-22 17:11
Member since:2005-10-27
It's an interesting reply.
You bring a good point with "reducing coupling". However my feeling is that mediator is often too simple in implementation, an unecessary abstraction if you prefer, and it can be "removed" with templates: without the cost of "coupling the class to another".
However I disagree when you talk about plug-in. I think what you are refering to is a Facade and not a Mediator when it comes to plug-in. Facade because the plugin knows and interact with the application only through what is exposed in the Facade. I think that's what you meant with:
Almost all large scale systems use mediator-like patterns to allow objects to communicate with each other via an established protocol, plug-in systems especially.
That definitly looks like you are talkin about Facade http://en.wikipedia.org/wiki/Facade_pattern
Just browsing wikipedia I found a good critic about insufisant abstraction caused by the will to use design pattern, it goes further than my real opinion about it, but I kinda feel the same way as that guy: http://en.wikipedia.org/wiki/Software_design_pattern#Design_pattern...
Member since:
2005-10-27
Eugenia I noticed it's not the first time you are linking articles from Mr Morris. This time I took time to read the resume of Mr Morris, and he is definetly an experienced programmer.
I am a young programmer passioned about C++ (I take this languaged in high esteem, please no trolling on this) I would not encourage other programmer to read this article for 2 reason:
1. As the beginning of the article you can read:
In software, the area in which individual objects interact seems to present much difficulty. If we get the interaction patterns wrong, the possibility of successful reuse and componentization is also reduced.
This is very very true. So true that I spend most of my time rewritting my code and the code of others (more experienced than me sometime) to provide better reusabilty. And it's difficult to do, but it is possible. So if one spend time writting a good class using the correct pattern, why would he need a "mediator" in the first place? Furthermore there is chances that if the implementation is already wrong, the mediator won't make things more right.
2. Nowaday C++ is still evolving very fast and it's been some time that one major improvement have been around, and this improvement helps a lot to solve the problem tackled by the mediator: it is called a "concept". Typically "concept" are used with "templates". As in the exemple you want to allow a certain number of interaction with your class. Instead of writing a "mediator" that you have to maintain, you write your class using a template argument and define your template with a serie of concept. Those concept will garantie that requirement for your templates are met and it with template you gain genericity: which helps a lot in protability.
These technics are gather as a common name: meta-programing. There is wonderful books about combining design pattern and metaprograming, and the great effectiveness and portability of the code that results.
Reading this article will IMHO lead the programmer in the wrong direction, ie away from the power of metaprogramming, forcing him to add always more and more classes to its code, which in most of the case result in "complicated design".