A Flexible Validation Handling In Swift

Protocol composition for better scalable and testable code

My challenge was how to implement a reusable input data validation, that can be called from (n) screens. For example an email validation, that I should to use in signup, login, restore password and in change user details screens. A simple input validation that doesn’t include any transforming formatted data or any business logic.
According to MVC, it can be implemented in ViewController. But if I use this validation from several ViewControllers I will end up with duplicated code.
Also In order to avoid Massive View Controllers, in general, my approach is to remove from ViewController knowledge about the UI, validations, logic, networking…

The key was the amazing Mixins and Traits in Swift 2.0 article by @mhollemans.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

My example will be for email and password validations.

Implementation

Let’s start with trivial email validation protocol.

ValidateEmail protocol defines a validation function in case it’s failed the appropriate error will be returned to the person.
In the protocol extension, there is a default implementation for the isEmailValid method.
The ValidatePassword protocol has the same structure, it’s code available on GitHub.
Both validation protocols throw an error that implemented in ValidationError enum, the enum with associated values. ValidationError accessed to validation error enum types and know to return a specific error description. Because the ValidationError is talking on a quite different subject, it’s code also available on GitHub and I will go throw it in the next post.

Here is coming an interesting part. How to use our protocols?

The problematic way:

Obviously. We can conform to protocols directly in class definition.

This implementation will cause a mess in a class definition. Especially when we talking about of group of protocols, that can growth to (n) protocols.

A better way, is to use Protocol Composition.

But this implementation will writes all default protocol functions into the class in compilation time. And access to the function become less obvious.

An alternative way:

In the ideal world I would love, any ViewController to be able to access only the validations it needs, through the object that captures them.

To do so let’s compose all protocols in the certain struct. This struct gets conform to it’s inner typealias and then we can create a new instance of it in our ViewController it will allow to us access to all protocols default validation functions.

To start using new LoginValidator let’s create a new instance of it in the VC or we can also inject it in a constructor.

The validator. variable will show the list of all validation functions. The function call validator.isEmailValid(…) becomes clearer and more readable. Each new struct wrapper object defines exactly what it needs and it also make maintenance cost lower.

This definition allows convenient use of independent Unit Tests and use of dependency injection.

Thats it.

You are awesome! Thank you for reading till the end:)

Cheers!