associating enum cases will class name

Question

Description

I have enums with case names that correspond to class names. I use the enum to populate sections/rows of a UITableView. When a user selects a row, I'd like to instantiate the corresponding class and instantiate an object of that class.

// example enum:
enum BodiceEnum: String, CaseIterable {
    case AddBraCups
    case AddOrRemoveBoning
    // other cases hidden
    }

// example classes:
class AddBraCups { // implementation hidden }
class AddOrRemoveBoning { // implementation hidden}

Additional Context

I made a lookup table to connect the "Section" enum cases to their corresponding detail enum cases:

var alterationsLookupTable: [(String,[Any])] = [
    ("Bodice",BodiceEnum.allCases),
    ("Neckline",NecklineEnum.allCases),
    ("Sides",SidesEnum.allCases),
    ("Sleeves or Straps",SleevesOrStrapsEnum.allCases),
    ("Back of Dress",BackOfDressEnum.allCases),
    ("Seams",SeamsEnum.allCases),
    ("Hem",HemEnum.allCases),
    ("Skirt",SkirtEnum.allCases),
    ("Veils",VeilsEnum.allCases),
    ("Prom - Straps",PromStrapsEnum.allCases),
    ("Prom - Take in/out",PromTakeInOrOutEnum.allCases),
    ("Prom - Hem",PromHemEnum.allCases),
    ("Tux",TuxEnum.allCases),
]

The current UITableView section corresponds to an index in this alterationsLookupTable array.

Once I get the correct section's type, I switch over the corresponding enum cases for that section. I'm switching over itemsTuple.0 and then using the current indexPath.row value as an index in itemsTuple.1

override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "Cell")!
        //var alterationDetailsArray: [String]()
        let section = indexPath.section
        var cellText: String = ""
        let itemTuple = alterationsLookupTable[section]
        switch itemTuple.0 {
        case "Bodice":
            let items = itemTuple.1 as! [BodiceEnum]
            cellText = items[indexPath.row].readable
        case "Neckline":
             let items = itemTuple.1 as! [NecklineEnum]
            cellText = items[indexPath.row].readable
        case "Sides":
            let items = itemTuple.1 as! [SidesEnum]
            cellText = items[indexPath.row].readable
        case "Sleeves or Straps":
            let items = itemTuple.1 as! [SleevesOrStrapsEnum]
            cellText = items[indexPath.row].readable
        case "Back of Dress":
            let items = itemTuple.1 as! [BackOfDressEnum]
            cellText = items[indexPath.row].readable
        case "Seams":
            let items = itemTuple.1 as! [SeamsEnum]
            cellText = items[indexPath.row].readable
        case "Hem":
            let items = itemTuple.1 as! [HemEnum]
            cellText = items[indexPath.row].readable
        case "Skirt":
            let items = itemTuple.1 as! [SkirtEnum]
            cellText = items[indexPath.row].readable
        case "Veils":
            let items = itemTuple.1 as! [VeilsEnum]
            cellText = items[indexPath.row].readable
        case "Prom - Straps":
            let items = itemTuple.1 as! [PromStrapsEnum]
            cellText = items[indexPath.row].readable
        case "Prom - Take in/out":
            let items = itemTuple.1 as! [PromTakeInOrOutEnum]
            cellText = items[indexPath.row].readable
        case "Prom - Hem":
            let items = itemTuple.1 as! [PromHemEnum]
            cellText = items[indexPath.row].readable
        case "Tux":
            let items = itemTuple.1 as! [TuxEnum]
            cellText = items[indexPath.row].readable
        default:
            cellText = "not valid cell text"
            
        }
        cell.textLabel?.text = cellText
        return cell
    }
}

I've been looking at this but I can't seem to make it work. My (little) understanding of the problem is Swift's type safety. I'm guessing there is Swifty (idiomatic) way to make this happen.

Update 2:

Here’s an example of one Alteration Section —> Hem and one of it’s subclasses —> AddHemLace

class Hem : Codable {
    var minCost: Float
    var maxCost: Float
    var actualCost: Float

    var name: String {
        let thisType = type(of: self)
        return String(describing: thisType)
    }

    init(minCost: Float, maxCost: Float, actualCost: Float) {
        self.minCost = minCost
        self.maxCost = maxCost
        self.actualCost = actualCost
    }

    convenience init() {
        self.init(minCost: -1, maxCost: -1, actualCost: -1)
    }
}

class AddHemLace : Hem {
    var costDetails: String?
    var costUnit: String?
    var units: Int = 1
    var secondaryCost: Float = 0.0
    var secondaryCostDetails: String?

    var totalCost : Float {
        return self.actualCost * Float(self.units) + self.secondaryCost
    }

    init() {
        let min: Float = 50.00
        let max: Float = 80.00
        let actual: Float = min
        super.init(minCost: min, maxCost: max, actualCost: actual)
    }

    required init(from decoder: Decoder) throws {
        fatalError("init(from:) has not been implemented")
    }
}

Problem: I couldn’t figure out how to populate the UITableView

I made related enumerations that had a parallel structure to my classes.

enum AlterationSectionsEnum: String, CaseIterable  {   
    case Hem
    // other cases
}

enum HemEnum: String, CaseIterable {
    case cutAndReplaceHem
    // other cases
}

I then used a big switch statement, a lookup table and some string parsing foo to fill the UITableView. Lots of code smell.

Question

As I attempt to understand this answer, I’m seeing now it would have been possible to use my classes directly to populate the UITableView.

I’m not sure where to start with this statement:

“For example, it should provide a method to populate an NSView or table cell. This way, each class can define its own kind of UI to present for its particular configurable parameters…”

See screenshot of UITableView

Answer 1

This sort of switching and force down casting into one of many possible types are a severe code smell, indicating a missed opportunity to apply object oriented design.

It seems to me that you would benefit greatly from a DressCustomization protocol, which your various customizations conform to. Then, make a set of classes that conform to this protocol. You need one DressCustomization class per "category" of customization. By "category", I mean a set of customizations that share similar configurable parameters, use cases and UI. For example

• A "ElongateCustomization" is one that just stores the name of some area of a dress, and a length by which to elongate it
• A "ColorCustomization" is one that stores the name of some area of a dress, and a color to use for it
• An "AddOnCustomization" is one that stores the name of a feature to add on

The DressCustomization protocol is a unifying protocol that lets you store/handle any one of these customizations in a uniform way. For example, it should provide a method to populate an NSView or table cell. This way, each class can define its own kind of UI to present for its particular configurable parameters. E.g. the views vended by ElongateCustomization presents a picker for a dress section, and a number input for the elongation length. The views vended by ColorCustomization presents a picker for a dress section, and a color palette for input.

These DressCustomization objects are also part of your data model. Your various table cells can store references to them (for every DressCustomization class, you'll have a corresponding subclass of UITableViewCell), and can act on them directly. No casting required.

Fundamentally, in almost any case where you find yourself branching on one of many values, and doing one thing out of many possible things, that's a strong indication that you can leverage polymorphism. This way, you can easily define new customizations, and not hunt around your code base adding in new switch cases, force casts and other such nonsense.

Answer 2

Problem: I couldn’t figure out how to populate the UITableView

Why don't you make a direct type representing the section-row hierarchy?

Prepare some protocol representing a row:

protocol AlterationType {
    var name: String {get}
    //... other common properties or methods
}

And define a struct representing a section:

struct AlterationSection {
    var sectionName: String
    var alterations: [AlterationType]
}

With these above, you can declare a data model of your table view as an Array of AlterationSection:

var alterationSections: [AlterationSection] = [
    //...
]

With this Array, you can write your tableView(_:cellForRowAt:) simply as:

    override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        //### `dequeueReusableCell(withIdentifier:)` may return nil,
        //### You should better use `dequeueReusableCell(withIdentifier:for:)` instead.
        //### (You need to register the identifier "Cell" in any of the available ways.)
        let cell = tableView.dequeueReusableCell(withIdentifier: "Cell", for: indexPath)
        let alterationSection = alterationSections[indexPath.section]
        cell.textLabel?.text = alterationSection.alterations[indexPath.row].name
        return cell
    }

You can initialize alterationSections as:

class Hem : Codable, AlterationType { //<-Add conformance to `AlterationType`
    //...
}

class AddHemLace : Hem {
    //...
}
var alterationSections: [AlterationSection] = [
    AlterationSection(sectionName: "Hem", alterations: [
        AddHemLace(),
        //...
    ]),
    AlterationSection(sectionName: "...", alterations: [
        //...
    ]),
    //...
]