FREE TRIAL: Accelerate your app development career with Hacking with Swift+! >>

How to break up structs and classes

Recorded – 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!

This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.

Listen on Apple Podcasts

Hacking with Swift is sponsored by Essential Developer

SPONSORED Join a FREE crash course for iOS devs who want to become complete senior developers — from October 18th to 24th. Learn how to apply iOS app architecture patterns through a series of lectures and practical coding sessions.

Learn more

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

BUY OUR BOOKS
Buy Pro Swift Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift (Vapor Edition) Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Server-Side Swift (Kitura Edition) Buy Beyond Code

Was this page useful? Let us know!

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.