This weekend, I browsed around on Medium and found a post about “3 ways to pass data from model to controller”. Comments indicate that people like it because it talks about the important basics: how do you pass info around? It’s probably the most essential object-oriented programming question ever. How can you couple components?

The 3 ways mentioned are:

1. callbacks,
2. delegation,
3. and notifications.

These are indeed 3 different ways to couple any component. It’s important that you know about these techniques (among others) to write code.

Then it occurred to me that the post may be accidentally misleading new Swift developers, though, because the examples hardly show how to create a good model. Take the sample code for delegation:

class DataModel {
    weak var delegate: DataModelDelegate?
    func requestData() {
        // the data was received and parsed to String
        let data = “Data from wherever”
        delegate?.didRecieveDataUpdate(data: data)
    }
}

This is a network request with a delegate-based callback. Sure, it illustraties delegation. But it’s network controller code. It’s not model code. Do you see anything that represents an entity here? The only model-esque thing you’ll spot is data, actually. A model object is an object that essentially is something. What you see above is a service object that merely encapsulates a sequence. Apart from the delegate property, it’s stateless. It is itself hardly part of the state of the application.

In simple cases, it might not pay off to extract network request code from model code. But this will not scale. And if this example is among the first things you see as an uprising iOS or Mac developer, you’ll be mislead.

Say your code has model objects already and you want to apply the technique of delegation as outlined above. So you take this simplistic snippet, you see that you can just paste it in without any conflicts, and then you’re done. The successful application seems to be enough of a proof. But now your code got worse. Because your model object is now the network request gateway, too. It does two very important but very different things. Maybe the harm will show only in a couple of months from now – and if you maneuvered yourself into this situation with all the best intentions in the first place, you’re probably not aware of the source of the problem and won’t be able to fix it yourself.

When you read code-focused “X best ways to do Y”, figure out what kind of world-view or terms the author is (unknowingly) selling to you. Only with a critical distance can you take advice without blindly changing how you think. If you cannot find compelling reasons why the author does it the way she does, maybe she just did sloppy work and didn’t care much. You have to take responsibility for the quality of what you learn.

Authors can’t start at Genesis and explain how all of human history culminated in this super coding trick. When you write, you have to take some things for granted. The problem is: if you, the reader, don’t have your own opinion, the things you’ll see first will affect you the most. And if the things that are left unsaid are important concepts of your craft, it’s hard to notice what’s going on. You cannot collect code snippets without collecting a bit of the authors view on how to do things The Right Way&tm;. If the pieces in your collection conflict and you don’t notice it or don’t understand why, it’ll be hard to write cohesive code and apply any of these tips. Because in the end, nothing works in isolation; you, the human, are always part of the process, and your confusion will manifest in code.

For reference, here finally is the link to the post I talked about: https://medium.com/ios-os-x-development/ios-three-ways-to-pass-data-from-model-to-controller-b47cc72a4336