Swift factory method design pattern

Factory method is just a non-static method

Let’s face it, this pattern is just a method usually backed by simple protocols & classes. Start with a really simple example: imagine a class that can create a base URL for your service endpoint. Let’s call it service factory. 😅

class ServiceFactory {
    func createProductionUrl() -> URL {
        return URL(string: "
    }
}
let factory = ServiceFactory()
factory.createProductionUrl()

You might think, that hey, this is not even close to a factory method pattern, but wait for it… let’s make things a little bit complicated by creating a protocol for the service class and a protocol for returning the URL as well. Now we can implement our base production URL protocol as a separate class and return that specific instance from a production service factory class. Just check the code you’ll get it:

protocol ServiceFactory {
    func create() -> Service
}

protocol Service {
    var url: URL { get }
}

class ProductionService: Service {
    var url: URL { return URL(string: " }
}

class ProductionServiceFactory: ServiceFactory {
    func create() -> Service {
        return ProductionService()
    }
}

let factory = ProductionServiceFactory()
let request = factory.create()

Why did we separated all the logic into two classes and protocols? Please believe me decoupling is a good thing. From now on you could easily write a mocked service with a dummy URL to play around with. Obviously that’d need a matching factory class.

Those mock instances would also implement the service protocols so you could add new types in a relatively painless way without changing the original codebase. The factory method solves one specific problem of a simple factory pattern. If the list – inside the switch-case – becomes too long, maintaining new objects will be hell with just one factory. Factory method solves this by introducing multiple factory objects.