🔴 S.O.L.I.D Architecture With Swift From an Ex-Meta Engineer
Vložit
- čas přidán 11. 07. 2024
- Building high level apps requires high level knowledge.
Here at AppStuff, we make the difficult stuff look easy.
In this video we cover SOLID Architecture with Swift, and give you detailed examples of each principle so you can implement them with ease in your own apps.
🔴 Become a member to access Exclusive Content & Pro Courses :
www.stephancodes.com/plans-pr...
🔴 Intermediate & Advanced Fundamentals Course:
appstuff.teachable.com/p/intermediate-advanced-fundamentals-with-swift
🔴 AppStuff Pro Courses:
www.stephancodes.com/videos
🔴 Beginner Fundamentals with Swift:
• Learn How To Code | Pr...
Social Media:
Instagram - @stephan.dowless
🖥️ ONLINE COURSES & APPS
👉 FREE UBER SwiftUI Course
• 🔴 Let's Build UBER wit...
👉 iOS App Templates:
www.stephancodes.com/shop
👉 FREE Twitter SwiftUI Course
• 🔴 Let's Build Twitter ...
📖 Chapters
0:00 - Intro
1:32 - Single Responsibility Principle
11:08 - Open/Closed
17:04 - Liskov Substitution
19:38 - Interface Segregation
22:53 - Dependency Inversion - Věda a technologie
For the SRP part, I would say its a bad idea to create dependencies inside a method (at least do a method injection instead), for example how would you test your Invoice implementation? You can't mock InvoicePrinter nor the InvoicePresitence, yes you can test them separately but there is no way to test Invoice in integration with InvoicePrinter and InvoicePresistence so you should use preferably constructor injection here, also another thing Invoice is a model, it should cointain only data not some kind of functionality of printing or saving. You could have some kind of InvoiceManager which depends on InvoicePrinter and InvoicePersistence and therefore you could test everything easily and also those dependencies depending on the case should be protocols not concrete implementations, but overall nice explanation about separating into different classes/structs and so on
Everything is very clear, thanks!
I appreciate your gratitude. As always, your course provides excellent clarity in explanations.
Wow! I would say the best explanation for SOLID!
Excellent explanation, thanks!
thank you bro. After watching this its easier to understand the Networking Masterclass course i just purchased
Excellent video!
great video stephan, thanks. can you make video on important design patterns as well .
Absolutely love your videos. Please make more
Make sure to check out our premium content! Links in description of all videos
Thanks dude, really helpful content all around. "Liskov Substitution Principle" sounds like something out of a 1960s sci-fi novel related to time travel heh
Sounds so scary, but is actually so simple lol
Thank you man, appreciate your dedication for the last months. Love how you are taking a deeper look into those more advanced things that every iOS Developer at some point has to face. Btw what do you personally think about VIPER aka clean architecture? Do you like it or is it more over engineering for you?
I’m making a full swift architecture course! Going to do all of the different patterns. Personally, I think VIPER is definitely over engineering. It’s like killing a fly with a bazooka 😂
thanks!
i was waiting ......great
Thank you!
Clean and very relevant to the iOS domain, it is better to explain with real world examples not Animal etc. classes. Thank you :D
like before watching!
Theres a presentation by Bruno Rocha in the SwiftConf about controlling your app size, where he talk about how structs are "expensive" for the compiler to handle. (probably a will improve over time, but at this moment it's suboptimal.)
By your examples looks like you favor a well fragmented approach in your code, do you feel any impact in your apps size? Been working on any big App recently that can be affected by it?
Great video! But this is all really cool if you're working on your own project or maybe at a company with their own product. Cause at an agency where I work atm, I have no time to think about & implement all this. Explaining to a client why something "simple" took so much time is also close to impossible. 😫
Welcome to the professional world lol. You gotta prioritize getting things done over having clean code. Which is why most companies code bases are trash 🗑️🗑️
From the Open/Closes Principle, Kindly how do we implement the save(invoice: Invoice) with different function signatures ? i.e. save() function defined in DatabasePersistence is async while save() function defined in CoreDataPersistence is not async. Yet both must conform to
protocol InvoicePersisableProtocol {
func save(invoice: Invoice)
}
Do you have a discord or one on one sessions. I have a project of my own with a couple of bugs that I can’t seem to fix.
Contact me on my website! Link is in my CZcams profile
i am seeing this for the second time for practicing , but still i have a doubt in implementing in our reallife project in our company , so can you do a video of solid architecture in a small project , i think project based learning is more effective
As stated in the video, check out the Swift Networking Masterclass on our website
Hello. I buy this subscription but don’t have an access to couses. Can you help me please?
Hey! Just contact us on the website and we can help you out
When should we follow the SOLID principle? Should we do during updates or adding new features?
Ideally you would follow it at all times. It shouldn’t have limitations on when it’s implemented
So in a real implementation, would you have to create all these structures in one file if the functions are related or in different files?
Different files for sure!
Hello Stephan, in the first principle you were talking about classes but in your examples, you just spoke about structs and not classes, but learnt from your other tutorials that they are not the same. Can you please clarify for me?
I didn't really understand the point of Liskov Substitution Principle.. When is that ever not true? Wouldn't a derived or child class always be passable as parent in these cases? That's like.. the point of heritance..? At least for objects with pointers. Are we talking about how structs can be sliced, or what is the point of the principle? Showing what's NOT correct for each principle would help a lot, I think.
Also, couldn't the protocols at 21:40 be optional instead of split, for such a consise scenario?
Ok, something all tutorialists need to learn. Dont show the bad way to do something when you’re trying to teach someone the proper way.
Bro shut your dumb ass mouth. Don’t tell people how to do their job, if you aren’t doing it better with proof to show it. You’re just a fucking clown with a meaningless opinion. On top of that, an opinion that’s ultimately negative and does nobody any good. Meanwhile creators like myself are out here busting our ass to bring quality content to people for FREE. Fuck way off you dork.
@@appstuff5778 I worked for Ray Wenderlich / Kodeco as an iOS editor. I think you leftist tech bros are losers.
@@appstuff5778 This is my job. Are you going to delete my comments again?
I worked at Meta. As an actual engineer, not an editor. Kodeco is also trash. Why you’re trying to bring politics into the equation makes zero sense, much like your comments. We can go blow for blow dawg, I’m smarter than you and I make a lot more money than you do. So maybe just shut the fuck up and keep editing other peoples code? Or try building something yourself to gain some actual credibility.
I already built my own app in the apple store, so I quit working there. I also wrote my own encryption library. Have fun with UI's and being a little bitch who crumbles under an ounce of criticism from someone who knows how to teach.
I think a lot of people are going to get confused by your example of not using an actual Class data type to first represent the single responsibility rule. When you create a struct it doesn't matter when or where youre calling your objects, theyre going to be created new every time. thats why you can create more complex things in structs that you shouldnt do with a Class type. Your idea of extracting functions into their own struct actually creates more net objects, they need to create 3 new item objects instead of just the one you'd initially call , for example. On top of that, that's not how you'd refactor a struct, to make it more readable you'd easier just create an extension. why would you create more structs?????
also sometimes are absolutely unnecessary, atleast in my app, for that simple task. I think if you'd want to show something that would required added functionality, you'd show a protocol with an enum not with a struct, that, again, IS MADE FOR ADDED FUNCTIONALITY.
Im watching this with the same energy that you made this with where you're essentially saying that people are bad coders unless they do it your way and so hence, your code or atleast examples, seem more predatory than edifying and meant more to get people to purchase your masterclass after your example was just... idk.
Go ahead and make your own video explaining it your way then 🫡
Great video!
I appreciate that!