9

To keep classes decoupled I'm using the Mediator Pattern like so:

class Mediator { constructor(canvas, selectionBox, undoManager) { this.canvas = canvas this.selectionBox = selectionBox this.undoManager = undoManager } addText(text) { this.canvas.addText(text) this.undoManager.captureUndo() this.selectionBox.update() } addImage(image) { this.canvas.addImage(image) this.undoManager.captureUndo() this.selectionBox.update() } // ... etc }

as more and more methods are added on the Mediator class, isn't it going to become a God Object?

If that's the case how do I resolve this? Perhaps create sub-mediators that group actions together and use a parent mediator to coordinate them?

(*) For the record I just started using this pattern and I'm not sure I'm doing this correctly.

Improve this question
6
  • Possible duplicate of How to apply the single responsibility principle if the program should do a lot of things? Commented Apr 20, 2018 at 9:33
  • 12
    @gnat You're really trigger happy with the close votes. I'm also (and most importantly) asking how to prevent it from becoming a god object. I appreciate you pointing me to another resource (which did help) but your overzealous attempts at moderation are making me think twice if I would ever get help asking questions in this site. Commented Apr 20, 2018 at 9:43
  • Your problem is related to too broad name of the class. It should be more specific to narrow number of functions inside. Of course it is a balance between number of classes vs number of methods. I really recommend try to use convention noun + verbal noun (e.g. ImageResizer, ImageTextUpdater). The level of granulation depends on your particular case. Commented Apr 20, 2018 at 10:11
  • @kadiii Which class? The mediator? Commented Apr 20, 2018 at 10:12
  • Yes, the mediator. The mediator class role is to hide complex logic of some operation which require many dependencies. They can be aggregated in logical groups to prevent putting everything into one class. Commented Apr 20, 2018 at 10:22

2 Answers 2

Reset to default
6

The role of the Mediator Pattern is to encapsulate communication logic between objects, reducing dependencies between them (reducing coupling).

However, like with any encapsulation if you put everything into one bag you can end up with so called God Object.

Solution for this is to use Single Responsibility Principle and split mediator objects, creating groups around the same behaviour. Practical tip can be to use convention - noun + verbal noun (e.g. ImageResizer, ImageTextUpdater).

It is not an issue of mediator pattern itself but incorrect (too broad) encapsulation in one class.

Improve this answer
1

No, your Mediator class does not look like it is becoming a God Object. A class is not a God Object because it has many methods, but because it can interact with nearly all other objects in your system. That is not the case for your Mediator class.

On a side node, the Mediator class looks more like the implementation of the Facade design pattern.
In a correct implementation of the Mediator pattern, the Mediator class would assist in updating the selectionBox when the canvas changes and vice versa. It would typically not be triggered by classes outside the Mediator pattern.

Improve this answer
8
  • It can lead to God Object as it is when object knows too much or does too much. So if the number of methods grows they need to be split. And definitely generic names like Mediator lead to such a situation. So your sentence "A class is not a God Object because it has many methods, but because it can interact with nearly all other objects" is wrong. Commented Apr 20, 2018 at 10:41
  • In a correct implementation of the Mediator pattern, the Mediator class would assist in updating the selectionBox, err isn't that the Observer Pattern? Commented Apr 20, 2018 at 13:45
  • @NicholasKyriakides Yes. However a class can participate in multiple patterns. Mediator (rather a bad name) observes both the canvas and the selection, and mediates the interaction Commented Apr 20, 2018 at 13:56
  • @Caleth I think you're wrong. A Mediator simply encapsulates how a set of objects interact. There's no mention of observing it's member etc in any definitions of this pattern, at least not any I've read. Commented Apr 20, 2018 at 16:12
  • @NicholasKyriakides the answer is suggesting this class (named Mediator because we lack context to suggest a better name) do those things Commented Apr 20, 2018 at 16:21

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.