#Swift downcast software#

Protocol UITableViewDataSource : NSObjectProtocol Currently, UITableView has an optional dataSource property. LetвЂ™s start with the existing protocol implementation. Imagine Apple has hired you to rewrite UITableView in pure Swift. If you donвЂ™t implement the methods to reorder the table view, it doesnвЂ™t show the reordering controls (for example). By having optional components of their contract, table views behave differently.

The methods are optional because the creators of UITableView wanted the behaviour to be opt-in (hey, just like our Food example!). The datasource protocol alone has eleven methods, all but two of which are optional. The table view delegate/datasource protocols have always mystified me вЂ“ no one has ever given me a satisfactory rule dividing what is a datasource method from what is a delegate method. So letвЂ™s take a break from Cat and Food and look at table views. He even later pointed out that was the case. I can see that being really useful for table views, for example. That way all the foods that donвЂ™t have any moisture donвЂ™t have to bother implementing those part of the protocol. Since I believe this difference is fundamental enough to different foods, IвЂ™d like to expand my protocol to have an optional amount of moisture. (ThatвЂ™s why kitties often have problems with urinary tract infections вЂ“ theyвЂ™re dehydrated.) Some foods, like canned cat food, have moisture. Cats вЂ“ turns out вЂ“ have not evolved to eat kibble they rely on moisture from their food to hydrate themselves. LetвЂ™s revisit our example of the cat and the food. It turns out that this is really really hard. HereвЂ™s the problem I ran into: in a pure Swift environment, I want to have optional methods in my protocol so that objects that conform to it may opt-in to certain functionality. (I know that this is fundamental stuff that you probably already know, but itвЂ™s important to make sure weвЂ™re on the same page before we continue.) Note that weвЂ™re using pure Swift types вЂ“ none of that Objective-C cruft. Let catFood = Kibble ( ) var dave = Cat ( )ДЄwesome. Instead, we can use the following Food protocol. We can have each animal type be aware of all the different food types, but that would tightly couple the types together.

Say we want to model some animals and food. LetвЂ™s look at a concrete, incredibly pedagogical example. Revisiting our earlier problem of the two types that want to talk to each other, we can use protocols so that they remain blissfully unaware of one another. If a type conforms to a protocol, it has essentially signed a contract to implement the methods specified in that protocol. As a high level concept, protocols are like contracts. In Objective-C - and indeed, in Swift - we call them protocols. Most modern languages have a way to deal with this problem.

#Swift downcast software#

If you directly reference the type of one from within the other, youвЂ™ve just tightly coupled the two types together - and any software engineer worth their salt knows that Coupling is Bad. HereвЂ™s the problem: you have two types that want to talk to each other. It is too specific for the general case, so I thought IвЂ™d dig deeper to see if I could figure out something better. So, hooray I guess? But something about the answer seemed unsatisfactory to me. I shared my actual question and with help from other developers, I found an answer for my specific case. Most were confused by my necessarily terse question (it may have been better to post a longer, more detailed question on a medium that provides more than 140 characters). I heard back from a lot of different people with a lot of different opinions.