UPGRADE YOUR SKILLS: Learn advanced Swift and SwiftUI on Hacking with Swift+! >>

SOLVED: Day 52: Cupcake Corner data structure

Forums > 100 Days of SwiftUI

Happy Monday everyone!

I just finished Day 52 (and all the challenges), and I was ready to move on to Day 53.

But right off the bat, I read the quote "write stupid code that uses smart objects", and felt a slight sense of guilt. So I went back to Day 52 to take a closer look at what we did in terms of data structure and objects.

We implemented the same solution using two different data structures,

#1. Paul's original solution: 1 class, multiple @Published properties per class object and no struct.

#2. Challenge solution: 1 class, 1 @Published struct, and multiple properties inside struct.

I know that classes are reference types and structs are value types, meaning whenever you modify a class property, Swift changes the original object. When you modify a struct, Swift creates a new struct, which I believe is exactly what we did for the Day 47: Habit-tracking app challenge where we had to copy the existing activity and add 1 to its completion count (because activity was a struct.)

However, for Cupcake Corner, the only "obvious" difference (at least to me) was how convenient it was to use Codable for Solution #2 as I only had to take care of one published struct, as opposed to solution #1.

I'm sure there are MANY other factors to consider when you decide on something like #1 vs. #2, but I just couldn't come up with a practical scenario. Does anyone have some real-world examples of when it would be better to use #1 over #2, and vice versa?

2      

Lulu seeks advice with data modeling:

Does anyone have some real-world examples of when it would be better to use #1 over #2, and vice versa?
But right off the bat, I read the quote "write stupid code that uses smart objects",
and felt a slight sense of guilt.

  1. Paul's original solution: 1 class, multiple @Published properties per class object and no struct.
  2. Challenge solution: 1 class, 1 @Published struct, and multiple properties inside struct.

If you get 5 developers in a room to solve a problem, you could end up with 7 possible solutions, or more!

While there certainly are best practices among developers, sometimes the choice between two solutions is a matter of personal preference.

But I think, over time, you'll come to better appreciate code that comes in well defined packages, and does one or two things very well. You should also strive to write your code this way. It's hard to see in the 100 Days lessons, because much of what you learn is trivial, or has a singular purpose. You write code, but rarely use it again. For example, did you reuse any of the astronaut code, or the expenses code? or any of the coffee code in later projects?

When you start using code from others, or integrate a company's standard account codes into an application you're writing, you'll very much appreciate containerized code. This is the part from above, "write stupid code that uses smart objects."

From your question above, I think that solution #2 multiple properties in one published struct seems more like a "smart object."

2      

Thank you! I guess I was confused because I was still thinking there must be one single correct solution, but I do realize that the more "real-world" the proejct is, the more diverse the solutions will be. Thanks for the words of wisdom as always!

2      

Hacking with Swift is sponsored by RevenueCat

SPONSORED Take the pain out of configuring and testing your paywalls. RevenueCat's Paywalls allow you to remotely configure your entire paywall view without any code changes or app updates.

Learn more here

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

Archived topic

This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.

All interactions here are governed by our code of conduct.

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.