[Workshop – 4] How to write clean code in a component architecture using Clean Swift

This article is part of an email series I wrote to my subscribers to teach them how to refactor existing legacy code. If you want to join us in the next workshop, make sure you subscribe.

  1. What is wrong with this viewDidLoad() method?
  2. Don’t waste time writing tests for untestable code
  3. Breaking up a method into shorter methods with single responsibilities
  4. How to write clean code in a component architecture using Clean Swift

Now that you’ve seen the importance of breaking up a large method into multiple shorter methods and the benefits. You’ve also seen what these shorter methods look like.

However, the coordinator methods are still somewhat hairy.

Today, you’re going to see how the VIP components in the Clean Swift architecture can work together to solve the coordinator methods problem.

A little analogy may help.

If you need to model a chessboard, you’ll use a two-dimensional array to model the grid. You can divide the chessboard up into rows and columns. On the other hand, with a one-dimensional array, you would have to calculate where it should break into the next row.

In the Clean Swift architecture, you can also divide your code up into components and methods.

In line with the two-dimensional array analogy, you can think [component, method].

Certainly, you can take the one-dimensional approach. You can refactor your business logic into many methods within your view controller. But the methods can invoke one another. It is very easy, convenient, and tempting to take shortcuts. It tastes like spaghetti.

However, you can take the two-dimensional approach, and separate the responsibilities into components then methods.

You can turn the coordinator methods, displayFollowerPosts() and updateFollowerPosts(), into single responsibility methods spread across the view controller, interactor, and presenter.

The Interactor handles your business logic. The Presenter handles your presentation logic. The View Controller handles your display logic.

Therefore, Clean Swift is a component architecture.

Here’s what the componentized version of the original massive viewDidLoad() method look like. Each method is doing ONE thing only.





You can find the Xcode project at GitHub here.

Now the code looks vastly different than the original massive viewDidLoad() method. Does it take a lot of effort to go from here to there? Is it worth it?

What if I tell you it takes less effort to write this better version than the original massive version?

How so? There is more code for sure.

Yes. More code. But, write faster. Think less. Higher productivity. More happiness.

If you follow the Clean Swift architecture from the beginning, you’ll be able to write small, single responsibility methods. Your code will naturally fall into the right place so that you don’t have to spend time to refactor it later. You’ll find joy in writing and testing code because it’s just intuitive. You’ll appreciate the simplicity a clean architecture can bring.

If you want to see how I apply Clean Swift to the same viewDidLoad() method starting from scratch, I’m running a free LIVE workshop next week. More details on the date & time plus an outline to come in my next email.

In the meantime, you can send in your question in advance now. Just hit reply. I’ll try my best to fit your question in the Q&A following the workshop.