Alexander Catchpole

SOLID for the everyday developer.

Sun, 28 Jul 2019 21:36:03 GMT

The S.O.L.I.D principles are the cornerstone of writing kick-ass OOP. When you implement them you’re on the right track for writing clean, easy to maintain code.

SOLID stands for:

Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle

Now those might come across as a bit intimidating but when we break them down, they’re pretty simple at their core.

Single Responsibility Principle

A class should only have one reason to change - it should only have one responsibility.

So what’s a responsibility?

When you think about any part of your system - you’ll start to see that each part of your code has a responsibility for a task to make the system work as a whole.

This could be:

Authentication
Sending a welcome email
Creating a user

Each of these are examples of responsibilities, as a class gets more responsibilities it becomes harder to enact any changes on the class as the handling of responsibilities become tightly coupled and any change to one responsibility might require changes to other.

Easier to keep them apart if you ask me.

So time for a code example, in PHP to shake things up.

class Calculator {
    private $result;
    
    public function add($firstNumber, $secondNumber) {
        $this->result = $firstNumber + $secondNumber;
    }
    
    public function divide($firstNumber, $secondNumber) {
        $this->result = $firstNumber / $secondNumber;
    }
    
    public function subtract($firstNumber, $secondNumber) {
        $this->result = $firstNumber - $secondNumber;
    }
    
    
    public function multiply($firstNumber, $secondNumber) {
        $this->result = $firstNumber * $secondNumber;
    }
    
    public function output() {
        return 'The result is: '.$this->result;
    }
}

So we have a calculator class, it’s main responsibility should be for calculating values, but in the above example it’s also responsible for outputting the results. That’s two responsibilities and breaks the Single Responsibility Rule.

What if the requirements changed and rather than outputting as a string, we’re now required to output as JSON? We’d be up shit creek without a paddle.

So how do we fix it?

The most sensible solution would be to create a CalculatorOutputter class, this classes’ sole responsibility is to output the results of the calculator like so:

$calculator = new Calculator();
// Returns result as plain integer
$result = $calculator->add(10, 20)->output();

$outputter = new CalculatorOutputter($result);
echo $outputter->toJSON();
echo $outputter->toHTML();

That’s solved our issue.

The calculator’s job is to calculate values and the calculator outputter’s responsibility is to output that value in multiple ways.

Open-Closed Principle

Objects or entities should be open for extension, but closed for modification.

This means that we should be able to extend a class to add new functionality without having to modify it directly.

Let’s say we want to carry on with our calculator example and add the ability to do more cool maths that I don’t understand.

Rather than modifying the base Calculator class which goes against the open-closed principle, we can extend it to add our required functionality.

class FancyCalculator extends Calculator {
    public function cosine($radians) {
        return cos($radians);
    }
    
    public function tan($radians) {
        return tan($radians);
    }
    
    public function sine($radians) {
        return sin($radians);
    }
}

Liskov Substitution Principle

Let Φ(x) be a property provable about objects x of type T. Then Φ(y) should be true for objects y of type S where S is a subtype of T.

That’s very scientific and might be useful for some people but not for the average day to day software dev.

Let’s make this simple.

You should be able to use a subclass in place of it’s parent class.

That’s it - so moving over to code how does this look? with animals you say?

class Dog {
    public function woof() {
        return 'woof';
    }
}

class BigDog extends Dog {
    public function woof() {
        return 'WOOF';
    }
}

BigDog can be used anywhere that Dog can be used and this adheres to the Liskov Substitution Principle.

But there is a catch.

class Hotdog extends Dog implements Edible {
  public function woof() {
    throw new NotImplementedException('I do not woof.');
  }
  
  public function eat() {
    return 'Bit undercooked.';
  }
}

Although this technically would work, it’s a violation of the principle because code that would work perfectly with Dog & BigDog no longer behaves as it should.

A picture is worth a 1000 words so here you go.

It is still a bird though, maybe not a duck.

Interface segregation principle

A client should never be forced to implement an interface that it doesn’t use or clients shouldn’t be forced to depend on methods they do not use.

Let’s follow the Animal example and start off with a rather contrived example that violates the principle.

interface Animal {
    function getType();
    function getSwimSpeed();
    function getRunSpeed();
}

class GoldFish implements Animal {
    public function getType() {
        return 'Fish';
    }
    
    public function getSwimSpeed() {
        return 'Slow';
    }
    
    public function getRunSpeed() { }
}

class Tiger implements Animal {
    public function getType() {
        return 'Big cat';
    }
    
    public function getSwimSpeed() { }
    
    public function getRunSpeed() {
        return 'Pretty quick';
    }
}

The above example breaks the principle because both GoldFish and Tiger are forced to implement a method they don’t use.

Lets change it to the following:

interface Animal {
    function getType();
}

interface Swims {
    function getSwimSpeed();
}

interface Runs {
    function getRunSpeed();
}

class GoldFish implements Animal, Swims {
    public function getType() {
        return 'Fish';
    }
    
    public function getSwimSpeed() {
        return 'Slow';
    }
}

class Tiger implements Animal, Runs {
    public function getType() {
        return 'Big cat';
    }
    
    public function getRunSpeed() {
        return 'Pretty quick';
    }
}

There we go that’s better - now both our GoldFish & Tiger models aren’t forced to implement methods they don’t use.

Dependency Inversion Principle

High level modules should not depend on low level modules; both should depend on abstractions. Abstractions should not depend on details. Details should depend upon abstractions.

Correctly implementing this is the key to writing great loosely coupled code.

The best way to visualise this is with an example.

class UI {
    private $service;

    constructor() {
        $this->service = new ServiceClass();
    }
    
    public function handleClick() {
        $this->service->doWork();
    }
}

class ServiceClass {
    private $database;
    
     constructor() {
        $this->database = new DatabaseConnector();
     }
     
     public function doWork() {
        $connection = $this->database->connect();
        $connection->doWork();
     }
}

class DatabaseConnector {
    //stub
}

You can see that at every layer there is reliance on the module below it. This breaks the principle because higher level modules are relying on the lower ones, this is mostly occurring because of the direct instantiation at each level.

For most languages remembering the phrase ‘new is glue’ will get you far.

So how do we fix it?

Interfaces are our friend here, rather than having the high level modules interact with the lower level modules directly, we can have them interact with interfaces - giving us a superb abstraction layer and removing some of that glue. It means we no longer rely on concrete instances but abstractions of those instances.

Following on from the example above - I’ll throw some better code your way.

interface IService {
    function doWork();
}

interface IDatabaseConnector {
    function connect();
}

class UI {
    private $service;

    constructor(IService $service) {
        $this->service = $service;
    }
    
    public function handleClick() {
        $this->service->doWork();
    }
}

class ServiceClass implements IService {
    private $database;
    
     constructor(IDatabaseConnector $database) {
        $this->database = $database;
     }
     
     public function doWork() {
        $connection = $this->database->connect();
        $connection->doWork();
     }
}

class DatabaseConnector implements IDatabaseConnector {
    //stub
}

Now the code above relies on abstractions and not on concrete types - if we need to swap out our service class - we don’t have to edit the UI class directly and it’s the same with DatabaseConnector. If we need to change our database connector from MYSQL to MongoDB we don’t have to manually update the ServiceClass

Strong Retain Cycles in Swift: Why They Happen & how to Avoid Them.

Sat, 27 Jul 2019 21:36:03 GMT

Strong retain cycles are one of the easiest memory leaks to accidentally introduce into your app.

99% of the time they’re harmless but they’re still a memory leak and can lead to your app being killed by the OS if you end up taking up too much memory.

Let’s get started by diving into why they happen.

Automatic Reference Counting (ARC)

The general idea of ARC is that the OS keeps track of the number of strong references to an object instance there are, if the reference count is greater than 0 the object can’t be deallocated. If it’s equal to 0 than the object can & will be deallocated.

// A strong reference to an instance will increase the reference count by 1

// Strong reference
var hello: String?

// A weak reference will not increase the reference count

// Weak reference
weak var hello: String?

Variables by default are strong unless defined as weak with the weak keyword.

In the above example, the view controller has 3 strong references to the same instance of the report service class through the 3 variables, although this isn’t going to happen in the real world - this is how the code would pan out.

// Creates an instance and is a strong reference to said instance.
var reportService: ReportService? = ReportService()

var reportService2 = reportService // Second strong ref
var reportService3 = reportService // Third strong ref

reportService = nil // Strong refs to report service is now 2

print(reportService) // nil
print(reportService2) // not nil
print(reportService3) // not nil

The instance declared in the first variable hasn’t been deallocated because there are still two strong references to it in the last two variables.

How Retain Cycles Occur

Now we have a basic understanding of how ARC works, retain cycles come about when two instances hold strong references to each other meaning the reference count of both can never be 0 so both can never be deallocated. This essentially means you’re using memory for objects you don’t need anymore. If this happens too much your app will be killed by the OS for using too much memory.

The above diagram is a classic example of a retain cycle - the view controller as a strong reference to the table view manager and the table view manager has a strong reference to the view controller.

Because of this the reference counter for both instances can never be 0 and these instances will live on indefinitely for the life cycle of the app, even when you don’t need them.

So how do we fix it?

Simply declare one of the variables to be weak.

// TableViewManager.swift
class TableViewManager {
    weak var viewController: ReportsViewController?
    
    init(viewController: ReportsViewController) {
        self.viewController = viewController
    }
}

// ReportsViewController.swift
class ReportsViewController: UIViewController {
    var tableViewManager: TableViewManager?
    
    viewDidLoad() {
        self.tableViewManager = TableViewManager(viewController: self) 
    }
}

by declaring the viewController variable as weak in the TableViewManager class we avoid a retain cycle because the reference counter for the ReportsViewController instance hasn’t been incremented by 1 as it’s a weak reference so when it disappears off the screen, the reference counter for it goes to 0 and the view controller is deallocated.

When the view controller is deallocated the reference count for the TableViewManager instance also goes to 0 as it’s only strong reference doesn’t exist anymore and it too is deallocated.

Closures

Closures can cause retain cycles because they have a strong reference to the object that uses them.

class ClosureExample {
    private var hello = "Hello"
    private var closure : (() -> ()) = { }
    
    init() {
        closure = {
            self.hello = "Hello World"
            print(self.hello)
        }
    }
    
    func callClosure() {
        closure()
    }
    
}

ClosureExample has a strong reference to the closure and because we used self inside of the closure, the closure has a strong reference to ClosureExample, hence the retain cycle.

The easiest way to fix this by the use of [weak self]

class ClosureExample {
    private var hello = "Hello"
    private var closure : (() -> ()) = { }
    
    init() {
        closure = { [weak self]
            self?.hello = "Hello World"
            print(self?.hello)
        }
    }
    
    func callClosure() {
        closure()
    }
    
}

The closure now has a weak reference to self and not a strong one - avoiding the retain cycle.

You can also use [unowned self] but if self is nil when you try to access it, your app will crash so it’s better to use weak.

Delegates

Delegates are one big place where retain cycles are easy to add unintentionally, take the following example.

// DelegateProtocol.swift
protocol DelegateProtocol: class {
    var report: Reportable! {get set}
    func printName()
}

//DelegateProtocolImpl.swift
class DelegateProtocolImpl: DelegateProtocol {
    var report: Reportable!
    
    func printName() {
        print(report.getName())
    }
}

//Reportable.swift
protocol Reportable {
    func getName() -> String
}

// Report.swift
class Report: Reportable {
    var delegate: DelegateProtocol!
    
    init() {
        delegate = DelegateProtocolImpl()
        delegate.report = self
        delegate.printName()
    }
    
    func getName() -> String {
        return "Report Name"
    }
}

Can you see the retain cycle here? Report has a strong reference to DelegateProtocolImpl and DelegateProtocolImpl has a strong reference to Report.

This is very much the same as the TableViewManager example but with a delegate thrown into the mix.

The simple solution is to simply mark the delegate variable as weak like so.

// Report.swift
class Report: Reportable {
    weak var delegate: DelegateProtocol?
    
    init() {
        delegate = DelegateProtocolImpl()
        delegate?.report = self
        delegate?.printName()
    }
    
    func getName() -> String {
        return "Report Name"
    }
}

Hopefully now you have a better understanding of ARC, retain cycles & how to avoid them - it’s pretty easy once you know how and what to look out for!

Welcome to my new site!

Mon, 29 Apr 2019 21:36:03 GMT

Welcome to my new site - it’s written from the ground up with Gatsby & Emotion using the Remark plugin for rendering out posts. It’s completely static and absolutely rapid.

Hosted on the amazing Netlify platform which is free & takes 30 seconds to deploy, if you have a static site that needs hosting I’d fully recommend them.

In my job I develop across a huge number of stacks so I look forward to writing about problems I encounter in my day and how I solve them.

Look forward to posts about the following!

Laravel
React
React Native
Swift
Kotlin
C#

If you need to contact me about anything, you can use the contact button in the top right. I’m open to a tiny bit of freelance work when my schedule allows.

Pintrest Collection View Layout

Sun, 29 Apr 2018 21:36:03 GMT

I recently had a need in a project of mine to handle a collection view with two columns, each column would have varying heights & each section would require a header.

Something like the following.

So how do we go about creating a layout like that? Well first we’ll need a custom UICollectionViewLayout