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

I appreciate your gratitude. As always, your course provides excellent clarity in explanations.

Everything is very clear, thanks!

thank you bro. After watching this its easier to understand the Networking Masterclass course i just purchased

Excellent explanation, thanks!

Excellent video!

Wow! I would say the best explanation for SOLID!

Absolutely love your videos. Please make more

great video stephan, thanks. can you make video on important design patterns as well .

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

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?

Clean and very relevant to the iOS domain, it is better to explain with real world examples not Animal etc. classes. Thank you :D

thanks!

i was waiting ......great

like before watching!

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. 😫

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?

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

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.

When should we follow the SOLID principle? Should we do during updates or adding new features?

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?

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?

Hello. I buy this subscription but don’t have an access to couses. Can you help me please?

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.

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.

Great video!