How to break up structs and classes

Recorded April 9th 2020 – watch the full episode on YouTube.

Daniel Steinberg: Let me ask you a question. Do you have an opinion on extensions and how you break things up? And do you break things up for protocols? How do you break things up in your classes, or structs?

Paul Hudson: I think I've seen a few different ways of doing it. A lot of folks seem to stare at large view controllers, and then carve off bits of the view controller into extensions, logically grouped. This is the data source extension for my view controller. This is the delegate data. This is my action handler. This is my about screen, whatever it is for that single view controller. And I don't do that. You're just moving code around. I know it makes it easier to understand because part of our job is helping folks come to our code cold and make sense of it by reading through the code. And that's hard to do when you've got a very long view controller. So having some logical grouping does help you.

“I prefer to use extensions for types I don't control normally. So system types, or someone else's types I've imported from a framework, I can add things to them to make them easier to use.”

But I don't do that. I prefer to use extensions for types I don't control normally. So system types, or someone else's types I've imported from a framework, I can add things to them to make them easier to use. For the other case, I'd just tear out and make a new controller for my data source. That's how I do it.

Daniel Steinberg: I do a lot of extensions. Someone pushed back recently and say, and I do it because you can see this is the part that does that. This is the part that does that. And what he said was he comes to code and now he doesn't know this thing conforms to all these protocols. He has to go down and look to see, “oh, it's equatable. Oh, it’s...” And so he didn't like that. I'm torn as a book author when I'm writing the toy code for my books, it makes it nice because I can show you just this little piece. But that doesn't mean I would do it in and out. I don't know yet.

Paul Hudson: So what I have done when I'm conforming to protocols with extensions, I'd often put that in a file called something like MyType-Codable.swift. So you sort of see from a glance, this bit is MyType making it conform to Codable.

Yeah, it's challenging because there is no one magic perfect silver bullet. Otherwise, we would all be using that from years ago, right? We're all still trying to figure out and there are always pros and cons, you try one thing, and it works for a while and try something else and that works for a while. And that's the nature of the beast, really.

“SwiftUI views are super cheap and they can be crazily disposes many, many times with little or no performance impact.”

Daniel Steinberg: So I've started doing something that people hate and it's in SwiftUI, I've been taking the part that conforms to view and moving it to a separate extension.

Paul Hudson: Yes, I saw that.

Daniel Steinberg: But the reason I do it is because people would think, especially once you get to listing things, that these are very expensive. And it's nice to be able to show them the struct, that the only thing that's in memory is this, that the body is a computed property. And so it shows you that these things that you're creating are very lightweight in memory. And so that's why I started doing it was to emphasize these things are very cheap that we're building. And even if we're building a ton of them, this thing only holds an integer or it only holds a reference. It's a binding to a Double. And so even though body is very complex because it includes foreground color and all that other nonsense, that's a computed property. Who cares? But I understand the look on your face when I said it.

Paul Hudson: I wouldn't necessarily agree with that part. But encouraging folks to think about the size of things is important and I did write about that a few months ago. I was saying, listen, if you have a user view struct, which conforms the View protocol, and has three integers, or a string and two integers, whatever it is, and then a massive body with VStacks and Hstacks, whatever, the total size of that struct is an Int plus an Int plus a string. There's nothing else around. There's no magic strapped around it. There's no complexity strapped around it. We don't think twice about creating 10,000 integers because it's basically free.

It goes on the stack. Same for 100,000 if you had to. But people think, “oh, this view must be expensive." It's really not. SwiftUI views are super cheap and they can be crazily disposes many, many times with little or no performance impact.

Daniel Steinberg: Yep.

Paul Hudson: Now I should say that we just heard your dog bark.

Daniel Steinberg: You did.

Paul Hudson: Can we see the dog?

Daniel Steinberg: No, because I haven't cleaned up my house for company here.

Paul Hudson: This is why folks come to the livestream rather than listen to the podcast version. They want to see the dogs and the live backgrounds and stuff.

Daniel Steinberg: I'll post a picture on Twitter later.

Paul Hudson: What's the dog's name?

Daniel Steinberg: It's Annabel.

Paul Hudson: Hi Annabel from listeners of Swiftly Speaking!

Sponsor Hacking with Swift and reach the world's largest Swift community!