Writing more reusable presentation components with the Mediator Pattern
Break down gargantuan classes.
Have you ever ended up with a Controller/Presenter/ViewModel with 1000+ lines of code? That presentation component is complicated, difficult to test, and hard to reuse based on the size of the class.
Here’s a simple two-step guide to writing smaller, reusable presentation components:
- Decouple the big presentation components into smaller ones.
- Use the mediator pattern to coordinate communication between presentation components.
Let’s walk through an example with the Google Play Store App.
Breaking Up the Presentation Component
In this example, I will use the term Presenter but you can sub it in for any other similar component. Let’s assume we handled the presentation logic for this screen in one class, AppDetailPresenter. It is a big 1000+ lines-of-code class.
There are two approaches I would take to breaking up AppDetailPresenter
- Extract the most reusable presentation logic into its presentation class. Maintain good cohesion by including other logic that will change/update together.
- Once you have extracted all the most reusable logic, you can focus on extracting other pieces until you feel like your code is more manageable.
Extracting Extra Logic
Once we moved all the reusable logic out into their presentation components, we should examine the state of our original presenter. Is AppDetailPresenter in a more maintainable state? Is it easier to test? Is the class easy to understand from a glance?
This is what the final result may look like. We separated AppDetailPresener into a collection of smaller presenters.
Working with a Mediator
We haven’t officially defined what the mediator pattern is yet so let’s get that out of the way.
The mediator pattern defines how a collection of objects interact with each other.
In our Google Play store example, we’ll need a mediator when we want to update the app overview with the user’s review when the user adds their review. Instead of coupling the AppOverviewPresenter and the ReviewPresenter together, we can use the mediator.
The ReviewPresenter will tell the AppDetailMediator when the user adds/updates their review. The AppDetailMediator will communicate the update to AppOverviewPresenter. The AppOverviewPresenter will update the view based on the new information.
It’s as simple as that.
We started with a giant presentation component that had a bunch of responsibilities. It was unwieldy and messy. We traded that solution in with a better approach that highlights better qualities such as
- Follows Single Responsibility Principle
- Testability
- Modularity/Decoupled
- Maintainability
I encourage you to make your presentation components composable and reusable. The mediator pattern is the perfect solution that will help you connect the dots as the codebase becomes more decoupled and distributed.
