Well Designed and Maintainable View Code

Scott Franks

Feb 2013

Rage ATM

SOLID Design Principles

These are class level design principles. They allow you to minimize coupling and dependencies. The result is code that is easy to read and refactor.

 

  • Single Responsibility Principle (SRP)

  • Open/Closed Principle (OCP)

  • Liskov Substitution Principle (LSP)

  • Interface Segregation Principle (ISP)

  • Dependency Inversion Principle (DIP)

SOLID (SRP)

A class should have only one reason to change and when making that change it should only effect the class.

 

  • Every class should only have a single responsibility.

  • The single responsibility should be entirely encapsulated by its class. 

SOLID (Open/Closed)

Software entities should be open for extension,

but closed for modification.

 

You should be able to add new features to and existing system without modifying preexisting code.

 

The concepts for "extension" are language specific, for example subclasses, extension methods, or categories.

SOLID (Liskov Substitution Principle)

Functions that use pointers or references to base

classes must be able to use objects of derived

classes without knowing it.

SOLID (Dependency Inversion Principle)

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.


B. Abstractions should not depend upon details. Details should depend upon abstractions.

Software Design Patterns

A design pattern is a general reusable solution to a commonly occurring problem within software design. It is a description or template for how to solve a problem that can be used in many different situations.

 

  • Helps developers reuse successful designs by basing new designs on prior experience.

  • Improves understandability for developers familiar with the pattern.

  • Identifies participating classes and instances, their roles and collaborators, and the distribution of responsibilities. This helps ensure adherence to Design Principles.

Software Design Patterns

Creational

  • Factory
  • Builder
  • Singleton

Structural

  • Adapter
  • Decorator
  • Facade

Behavioral

  • Command
  • Observer
  • Iterator

Creation of objects for you rather than instantiating objects directly

Composition of classes and objects to obtain new functionality

Communication and interaction between objects

Coupling and Cohesion

Coupling is a measure of how closely connected two modules are.

Cohesion is a measure of how strongly related each piece of functionality within a module is.

Coupling and Cohesion have an inverse relationship

With tightly coupled systems:

  1. A change in one module forces changes in others
  2. Modules are harder to reuse
  3. Modules are harder to test

With low cohesion systems:

  1. Modules are complex with more operations
  2. Modules are less maintainable and harder to work with

Applying this to View Controllers

Step 1:

Make sure that you pull all code not related to presenting the user interface out of the View Controllers. MVC does not stand for Massive View Controller

 

Step 2: 

Abstract common transformations and groupings into separate components or make them reusable though base classes.

Adding a Service Layer

As part of our login process we have to handle 4 possibilities: a successful login, MFA is required, the user has no eligible accounts, or an error code was returned.

 

The code required to do all the service calls and perform the logic to arrive at these possibilities is about 200 lines. Originally this was in our LoginVC be was pulled out into the eApiLoginBS. 

 

Lets look at a few examples:

  1. eApiLoginBS
  2. PollingBS

Reusing View Related Code

CashTapp uses custom buttons, text fields, and typography. Instead of recreating these components each time they are used we extended the base UIKit classes.

 

Lets take a look a few components:

  1. IconTextField
  2. CcwButton
  3. Typography Builder

 

And leverage inheritance for code reuse:

  1. CcwViewController

Isolating Complicated View Code

There are some UI aspects that we decided to abstract out of the View Controller despite them only occurring once. These UI components were usually very complicated (200 LOC+).

 

Examples:

  1. Custom Animations 
  2. The Circular Slider

L&L Maintainable View Code

By Scott Franks

Made with Slides.com

L&L Maintainable View Code

  • 782

More from Scott Franks