The factory method design pattern is a dedicated non-static method for hiding the creation logic of an object. Let's make it in Swift!


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. 😅

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:

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.


External sources