Thinking SOLID for iOS — Single Responsibility

I start by quoting -

Don’t follow an architecture, but the principle.

Most of you reading this — I suppose you are an iOS engineer and searching for that missing piece in your recipe for creating your world class application. The scope of this article is limited to Single Responsibility principle only. I’ll talk more about the rest of the principles, test-driven development, and evolution of architectures in my upcoming posts.

Ok so just to revise, S.O.L.I.D principles are -

S stands for Single Responsibility
 O stands for Open/Closed
 L stands for Liskov’ssubstitution
 I stands for Interface segregation
 D stands for Dependency Inversion

If you are a Developer, you got one job to do. Not many, not few, just one. So if you were asked to play a BA or a QA role, most of us would fail to do justice with it. For those who do manage to juggle these responsibilities — do remember that you are always juggling; you are on your toes, one mistake and the show will fall apart.

Now let’s move the context to the UIViewController. How many responsibilities it has to handle? Hint: Click here and scroll till the bottom, and don’t forget that it also owns your view and hence the IBActions. Why on earth would you give a ViewController any other responsibility.! Duh!! Not fair.

So if we were to think rationally, what would NOT be a ViewController’s responsibility?

  • Should it be a DataSource or Delegate for your TableView or CollectionView? I would argue NO. It may decide who would be the DataSource and Delegate, but it need not be the one. In most of the situations we have simple arrays with no complications, so naturally, we give this responsibility to ViewController. This, in fact, is ok to do, but what is important is to know that the data source could have been complicated (imagine a list which is sortable, composite, or lazily fetched), in which case you should not assume that it is ViewController’s responsibility to do all of this. Remember when your parents would teach you high school maths but not college level?
  • Should it make web requests? No. It shouldn’t know how or where the data is coming from. Or if there is any data at all!
  • Should it know about the business model, at least? No. View Controller might be interested in knowing what to show on the view (because it has the IBOutlet) but it shouldn’t need to know about how to translate a business model object to a view object. If you are still confused — all I’m saying is a view controller needs to know the text it has to show on the view. For e.g. the date. But it shouldn’t worry about which date format to use. That’s an additional effort. Someone should do that for the view controller.

One last example if you are still trying to figure out the borderline. Imagine you are a view controller and your house is your view. If Gas, paper, water, electricity is your data source. Would you want to control where it comes from? Yes Sure. Would you like to do tell the gas company or newspaper boy how to do their job? or purify water on your own? or rotate a turbine to produce electricity? No. While you do want to make sure everything is in order. You may not want to know the details of their functioning.

Now depending on the use case of your application, you will have more variety of components but I’m sure you will have it sorted.
 I’ll close here leaving a few questions open for you. If not the ViewController then -

Who would make API calls? Who would translate the business model into view model? Who would be the source of data and be a delegate to the view?

Awaken the architect inside you. Think about it and do write in the comments.

Originally published at on May 18, 2018.