UPGRADE YOUR SKILLS: Learn advanced Swift and SwiftUI on Hacking with Swift+! >>

Multi-output enums as generics...opinions sought.

Forums > Swift

Hi All,

I'm using Swift to develop an app, and am currently building the framework it'll use. I'm currently looking at the display functionality and am building a class of OutputObjects with multiple subclasses, each providing specific functionality.

The data the OutputObjects will represent is also multi-classed and subclassed.

I've implemented protocols on the data to allow OutputObjects to use generics, and that works really well.

However, I'm considering taking it a stage further, and implementing a) enums with multiple outputs (associated values), and b) generic enums.

I'm considering enums with associated as a replacement for static properties. So, for example, within my enum I might have values called image, colour, etc. These will be specific to each sub-class, that is, every time an OutputObject is created for a Bird, it will have (image: "GenericBird", colour: "Green"), for a Seagull it will have (image: "Seagull", colour: "Purple"), and so on. This would replicate static properties but would allow me to manage all such properties in a single place, without needing to recreate each time in each subclass. Is that a worthwhile approach or just wasted effort, or even too great an unnecessary burden at runtime?

I'm also toying with the idea of generic enums, that is, each enum conforming to a protocol. This would make it possible to use switch statements, for example, referencing items from disparate enums, or otherwise handling specific cases. So while it is possible, would it be worthwhile or otherwise, or indeed good or bad practice? I'm aware there could be pitfalls, eg, duplicated enum items in different lists, etc (I'm confident in my naming conventions that there wouldn't be) and the dreaded forgotten "if admin..." case, as well as further potential tight-coupling issues, but would be interested in hearing others.

Do these suggestions make for bad smells? Does the former negate the benefits of the latter, and would static properties on already protocol-conforming objects make both redundant?

I'd be interested to hear what people's opinions are.


It would help if you could post some example code because it's a little hard to understand what you're talking about from the description.


Hacking with Swift is sponsored by Essential Developer

SPONSORED Join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer! Hurry up because it'll be available only until April 28th.

Click to save your free spot now

Sponsor Hacking with Swift and reach the world's largest Swift community!

Reply to this topic…

You need to create an account or log in to reply.

All interactions here are governed by our code of conduct.

Unknown user

You are not logged in

Log in or create account

Link copied to your pasteboard.