Keep your views separate
When we have two similar looking views we often think of creating a reusable view like
“ I will create a UIView and then use that UIView in both of my controllers problem solved”
and you may pat on your back for thinking about re-usability here coz why not. (object-oriented vibes)
This may work for few cases but I hate to break it for you “It’s not a wise move my friend”
By reusing the same view at two places we may have solved the issue for now, but sooner or later if client adds a new feature saying
Hey you remember these two same views, now I want one of them to have a button that says coffee and coffee will have it’s own workflow
Great, now to many developers this may look like a small change and the very first instinct to solve this is
we can add the button by adding an if conditions and will make it visible if the user is on a specific view controller, we’ll do some constraint management and we should be good to go this requirement is no problem
Perfect now you delivered what the client wants, but you know how requirements are never at all frozen and the change requirements just keep on coming 🙄
Now again the client comes few days back and says
Hey you remember that view where we had the coffee button, yeah so I want to change the header color of it and show some discount coupons on it if the user is close to any of my coffee vendors.
So now we are thinking how to do this, well we already did that small constraint management for the button let’s do the same for the header color.
so we decide to add some if statements and make the change, add UI elements for the discount coupons add constraint management for them as well, perfect strategy we still in the re-usability club folks coz we love re-usability and being object oriented.
Now again the client comes after few days and says
Hey you remember that view where we had the coffee button and made the header color change, well now I want to add two text fields with user name and user email and store them in our backend
Now if you are still thinking that of adding a if condition and then doing some constraint management magic here then my friend we are heading in the wrong direction.
We can clearly see how volatile this screen is and how frequent the client is asking to make changes on it.
It’s a wise move to have one UIView and use them at multiple places
when the view is not changing at all and remains as is and when I say as is what I mean is there are NO ui or any business logic changes period.
If the change is to change the color or make the button radius more rounded sure no need to create a separate views for those, but do ask the client that
“hey the same changes will be visible on wherever we are using this screen, do you still want to continue with these new changes?”
When client introduces a change to any one of the similar looking views that should ring multiple sirens in your head indicating that now’s the time you should create a separate UIView for it because that screen has the potential to change.
After reading the above you may think like
“Ahh what is this guy talking about, a small constraint management and if condition never hurts anyone after all we are premium members of the club reusability of the object oriented town”
Well small changes like these leads to major problems to begin with, if you are letting go of these small changes soon you will let go of bigger uglier code changes as well.
And then after 6–12 months when you re-visit the code base you will be like who the hell writes code like this and would feel proud seeing your name on the git history (been there done that)
And if a similar looking screen was asked to change by the client then it has potential to change and few of those changes may introduce new business logic from the one you had in the past.
So rather than writing multiple if statements , or writing code for constraint management or any other creative work it’s a wise move to separate them out.
Separation of concern came out way long back, and it’s a pretty cool concept and must be know to every programmer who wishes to improve.
I hope this article was helpful, tell me how you managed such requirements would love to hear from you.
