How are factory constructors supposed to be done in Swift? - swift

Question

The Swift developers seem to be saying that polymorphism should be accomplished via protocols, not class inheritance. For example, let's say you have an array of Shapes and the Shapes have different draw methods, Shape should be a protocol not a superclass.
protocol Shape {
func draw()
}
class Circle: Shape {
func draw() { print("Drawing a circle") }
}
class Triangle: Shape {
func draw() { print("Drawing a triangle") }
}
var shapes = [Shape]()
func fillShapes() {
//... Add circles and triangles to shapes ...
}
// run
fillShapes()
for shape in shapes {
shape.draw()
}
Now say you want to build Shapes based on user input which produces Strings. How would you write a Shape constructor that accepts String as input, in the most Swift-y way?
Cristik in this question suggests a global function like this:
func buildShape(kind: String) -> Shape? {
switch kind {
case "Circle": return Circle()
case "Triangle": return Triangle()
default: return nil // Error - bad Shape
}
}
This seems messy to me. I would rather the constructor was incorporated into Shape.
So my first attempt was
extension Shape {
static func build(kind: String) -> Shape? {
switch kind {
case "Circle": return Circle()
case "Triangle": return Triangle()
default: return nil // Error - bad Shape
}
}
}
But calling Shape.build("Circle")! produces error: static member 'build' cannot be used on instance of type 'Shape.Protocol'
I also tried
extension Shape {
class Factory {
func build(string: String) -> Shape? {
switch kind {
case "Circle": return Circle()
case "Triangle": return Triangle()
default: return nil
}
}
}
static let factory = Factory()
}
shapes.append(Shape.factory.build("Circle")!)
But it says Factory cannot be defined inside a protocol extension.
How does Swift want us to make flexible constructors?

Answer 1

You are overthinking the problem. There is nothing cleaner than a "global" function.
The problem with global functions in some languages is that they are polluting the global namespace which leads to name conflicts.
However, every Swift project has its own namespace and every framework it imports has also its own namespace, so there is no problem with name conflicts, thus, there is nothing wrong with global functions.
There is no need to wrap simple functions into Factory classes just to create an illusion of a namespace (this would be the correct solution in Java because you cannot create a global function in Java).
Function accessed as Shape.Factory.build(...) is not any better than a function accessed using buildShape(...).
If you really want to have a namespace, you can just wrap your functions into a struct:
struct Shapes {
static func buildShape(kind: String) -> Shape? {
switch kind {
case "Circle": return Circle()
case "Triangle": return Triangle()
default: return nil // Error - bad Shape
}
}
}
and call it as Shapes.buildShape(...) but there is not real need for it.

Answer 2

The protocol cannot (and in my personal opinion, should not) be used as a "factory".
A protocol is a set of rules that a construct follows, not a concrete construct itself. A factory should be a concrete type, not a "set of rules". The solution is to have a separate ShapeFactory construct (be it a class, struct or enum), with static/non-static build functions.
As for the "messy" part; I agree. It is kind of messy. Swift doesn't isn't capable of things like struct Shape.Factory { }. There's no real way to get around it without making a compromise / rewriting the compiler, the latter of which can actually be achieved with some good constructive criticism at the swift-evolution mailing list.

Answer 3

I wouldn't do for a Factory method on Shape, neither a protocol nor a super class should know details about implementations or derived classes. I'd rather go for a ShapeBuilding protocol and a factory class.
protocol Shape {
func draw()
}
protocol ShapeBuilding {
static func build(kind:String) -> Shape?
}
struct ShapeBuilder: ShapeBuilding {
static func build(kind: String) -> Shape? {
switch kind {
case "Circle": return Circle()
case "Triangle": return Triangle()
default: return nil // Error - bad Shape
}
}
}
let circle = ShapeBuilder.build("Circle")
Motto: Just because Swift offers extensions we don't have to force everything into extension.

Answer 4

All three of you have given me good insight into this question. I now see that it is a much deeper question than I first imagined.
Here is my consolidated answer.
The Swift message is Avoid Building Abstract Class Hierarchy. Protocols are glue (or grease maybe?) not abstract superclasses.
In Swift, a protocol like Shape is not an abstract superclass of Circle and Triangle in the Java sense. Don't try to put factory constructors (constructors that can return more than one type) into protocols.
The previous version of this post suggested that shapes could hold the differentiated construction code. But I have changed my mind. shapes shouldn't know about circles and triangles either. shapes is polymorphic and that's what polymorphic means. Therefore I have substantially changed this post. If there was strike-through I would use it but I don't see it.
I now think a global function like this is the right way.
func buildShapeFrom(userInput: String) -> Shape? {
switch userInput {
case "Circle": return Circle()
case "Triangle": return Triangle()
default: return nil // Error - bad input
}
}
If there's an appropriate structure on the user input side, perhaps it could go there. The user cares whether it is a circle or a triangle, but Shape shouldn't and neither should shapes.
Comments welcome.