More concrete plan in Decoupling Massive View Controllers

Harry Ng
Harry Ng
Oct 30, 2016 · 3 min read

Here are the steps I am going to execute in decoupling the Massive View Controllers I have in hand. To provide some backgrounds, this is my current scenario:

  • Several View Controllers
  • Displaying content from the same Model type
  • Logic on each View Controller is slightly different

Here are the steps I am going to refactor the code:

  1. Group shared code into Protocol Extensions
  2. Separate Out Data Source and Other Protocols
  3. Use Generics to control code path in each listing mode
  4. Creating View Models
  5. Apply Reactive Functional Programming

Reference Articles

The workflow is based on a bunch of studies, levels of complexity, and potential impacts to our production application. Each of these has some reference readings.

Share code base

The top-most priority of the refactor is to share code base used in multiple View Controllers. In the era of Swift, protocol-oriented programming (POP) is highly advocated. In fact, we can organize code as protocol extensions. When each View Controller implements the protocol, they automatically get the methods from protocol extension and make it available within View Controller. This is pretty nice.

Reduce Source Code in View Controllers

After moving the code to custom protocols, some protocols are provided by system frameworks, such as Data Source and Delegate of Collection View. Depending on the situation, I can either extend them into another protocol and provide the protocol extension implementations. Or, I could implement that as a class, where I can use Generics as well.

Use Generics to Control Code Path

As I have slightly different logic in each View Controller, I need a way to differentiate between each one. Choosing Generics allow me to start the definition right at the intialization point. Also, compiler will help to check the type inference. This means I just need to set once at the View Controller initialization point, and all the related classes can run based on the Generics type provided.

Separating code into View Model

This part is more a design pattern switch from MVC to MVVM. This will help me to pull out data model related code into its own class View Model. View Controller will remain as view-related only. Yet, this is just half of the story. It is best to work with a data observing mechanism, so the View Controller is noticed when the underlying data changes.

Apply Reactive Functional Programming

No matter it’s KVO, Notification or RFP libraries like ReactiveCocoa, RxSwift or Intersteller. This provides a mechanism to trigger view updates from View Model. This is an even bigger topic that deserves its own set of articles. Also, this is something we are not familiar enough. Thus, this is kept as the very last part of the refactor.


macOS App Development

Stories and technical tips about building apps for macOS (previously OS X)

Harry Ng

Written by

Harry Ng

Father, Entrepreneur, Developer

macOS App Development

Stories and technical tips about building apps for macOS (previously OS X)

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade