Protocols and Swift
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 functi onality. It turns out that this is really really hard.
[…]
I’m not saying that this is necessarily how I would actually write things – it’s only supposed to show you how dividing areas of concern into separate protocols makes things a lot more clear.
[…]
Sure, you’ll probably have only one object that conforms to all the protocols you need (and be honest – it’s probably a view controller, isn’t it?). But the power of this technique is not that we can divide the various data sources into different objects. Instead, the advantage is that we don’t have additional semantic coupling between functions in the protocol. Of course
canMoveRowAtIndexPathcan only be called ifmoveRowAtIndexPathis also implemented – they’re in the same protocol.
Update (2015-02-02): David Owens II:
It’s just another way of thinking about the problem. Swift seems to be a language that values immutability and composition over mutability and if we start to think about solving problems that way, I think we end up with more solutions like I presented where it’s really just about how we manipulate the data in composable ways.
