Coordinator pattern is the latest “buzz word” that’s been going around in the iOS world although this pattern was already there from 2015 but recently it has caught the attention of many iOS devs and today we will try to find out how much value does this pattern provides in our application.
The scope of this article is not to explain what the coordinator pattern is and how we can implement it, but it is to determine the worth of adding this pattern in our projects.
If you know the Hindi language then do check out my YouTube channel where I have explained what this pattern is along with how we can implement clean coordinators in a 3 part video. The 3rd part is where I present how we can implement clean coordinators with protocol-driven programming.
Coordinator pattern is a fancy term for the delegate protocol pattern.
This delegate pattern isolates the navigation controller from the view controller and takes over the navigation responsibility.
Using the coordinator pattern we don’t have to use the segues for navigation, also we don’t need to write all that navigation code inside the view controller.
So this means using this pattern we decouple the navigation related task from the view controller and delegate the navigation responsibilities to the coordinator class.
Mission accomplished, no more coupling between the view controller and navigation. Plus now a single class is managing the navigation so SRP (Single responsibility principle)
But wait, every pattern has a trade-off and we must understand what those trade-offs are before we start celebrating and implementing this pattern in our client projects.
The very first thing is the need for the pattern, if one simply implements a pattern for no reason then it’s an abuse of the pattern.
So my first question to the folks who implement this pattern is
What’s the problem with the default navigation process in your application that made you implement this pattern? What problem does this pattern solve in your application? Was there even a problem to begin with?
It’s the responsibility of the UIViewController to handle UI related events including navigation, so if something is already the responsibility of the view controller what’s the point of separating it?
The coordinator pattern highly increases the code complexity because from creating the navigation to maintaining it, everything now becomes manual and the developer is responsible for handling every minor detail of navigation including memory management.
If the framework handles something for you, you must not try to recreate the same management because if you do, you will end up over-engineering it or what some say reinventing the wheel
Some of the downside of the coordinator pattern are
A. Strong references
One of the biggest gotchas of this pattern is to use weak keyword while declaring a delegate coordinator so that the strong references can be avoided.
Even the most experienced developer forgets to write weak self in closure so forgetting to write weak while declaring a coordinator is possible thus ending up creating strong reference.
So if somehow you end up using this pattern kindly have this check while you are reviewing the code.
B. Maintaining child coordinator
This pattern introduces child coordinators where a single child coordinator handles the navigation of a single view controller. The child coordinator will talk to the main coordinator for all its operations
If the developer forgets to remove child coordinator from the main coordinator after its work is done or removes the child coordinator way too early then this becomes a problem because you may end up with an object living in the memory OR it may result in hours & hours of debugging.
C. Tight coupling
This pattern causes tight coupling where one child coordinator knows abut other child coordinators
in the above image, one of the child coordinators creates another child coordinator and performs the navigation. This leads to something called as the coupled coordinators.
One of the reasons why developers implement this pattern is to remove need of adding references to other view controllers in the same controller in the prepare for segue function, since now we are using coordinator pattern we have done that but sadly now we have introduced coupled coordinators.
To solve coupled coordinators we can use a creational pattern like Factory, the coordinator pattern already increases the code complexity for a simple task, and now by adding Factory pattern we are just adding to the code complexity.
D. Code complexity
This pattern increases the code complexity, for doing a simple task which is navigation and it feels like there’s just too much delegation going on and strong references can easily sneak in.
We can decouple the navigation from the view controller but the cost of implementation and maintenance is very high.
Every pattern has tradeoffs and eventually, we live with those tradeoffs but just to remove few lines of code, if one has to add such complexity then truly it adds zero value to the project
Maybe 1 in 1000 scenarios this pattern could prove to be useful but simply adding this pattern will just cause coupled coordinators and an increase in code complexity.
So we are solving one problem but then we are giving rise to few more.
Asking yourself what problems you are trying to solve with this pattern and how is adding this pattern in your application beneficial as compared to the default navigation process can surely help you in making a decision while selecting this pattern.
Many developers tend to avoid using this pattern just because of the complexity it adds to the code and prefer using the default navigation and keeping things simple.
I think what’s happening these days is everyone is trying to implement patterns to make their code more robust and testable which I agree and support, but using a sword in the place of a needle is a bad approach.
One must first analyze the need for the pattern than just adding it for namesake, just because they read somewhere in the blog or their favorite YouTuber made a video on it.
I hope this post was helpful. Let me know in the comments what you think about it and do share the blog with your iOS group.
Thank you for your time in reading the article.
