why create two classes?

Question

so we access the two classes via:

let dictionary = try PlistConverter.dictionaryFromFile("VendingInventory", ofType: "plist")
let inventory = try InventoryUnarchiver.vendingInventoryFromDictionary(dictionary)

// helper classes
class PlistConverter {
  class func dictionaryFromFile(resource: String, ofType type:String) throws -> [String: AnyObject] {
    guard let path = NSBundle.mainBundle().pathForResource(resource, ofType: type) else {
      throw InventoryError.InvalidResource
    }

    guard let dictionary = NSDictionary(contentsOfFile: path), let castDictionary = dictionary as? [String: AnyObject] else {
      throw InventoryError.ConversionError
    }

    return castDictionary
  }
}

class InventoryUnarchiver {
  class func vendingInventoryFromDictionary(dictionary: [String: AnyObject]) throws -> [VendingSelection: ItemType] {
    var inventory: [VendingSelection: ItemType] = [:]

    for (key, val) in dictionary {
      if let itemDict = val as? [String: Double], let price = itemDict["price"], let quantity = itemDict["quantity"] {
        let item = VendingItem(price: price, quantity: quantity)

        guard let key = VendingSelection(rawValue: key) else {
          throw InventoryError.InvalidKey
        }

        inventory.updateValue(item, forKey: key)
      }
    }

    return inventory
  }
}

why wouldn't it be better to access both class methods from the same class?

let dictionary = try VendingData.dictionaryFromPlist()
let inventory = try VendingData.vendingInventoryFromDictionary()

Answer 1 · 2016-03-18T00:39:40Z

March 18, 2016 12:39am

Hi Ethan,

My guess is you were wondering why you wouldn't want to implement all the methods under the same class.

It's just a good practice to have independent concepts implemented separately as different classes, structs, in different source files or even frameworks. Not just for reusing codes, but also to mentally compartmentalize units that build up your app. For example, reading and converting a plist file into a dictionary is not specific to InventoryUnarchiver, it could easily be part of FoobarUnarchiver. By separating the implementation of reading a plist from creating an inventory, it also helps you write better code that is easier to read and more testable.

With that said, the errors being thrown by the PListConverter would've been even better if they were of separate ErrorType instead, e.g. PListConverterError instead of InventoryError.

Welcome to the Treehouse Community

Looking to learn something new?

Ethan Neff

Ethan Neff

why create two classes?

1 Answer

John W

John W