On September 23, 25, and 27, we'll teach you how to find fantastic iOS opportunities, double your income, and work with remarkable people. Register now: iOSLeadEssentials.com
Hello! This is a podcast episode. We can't show code in a podcast episode as most people only listen to it (without seeing the video). But in this channel, we have hundreds of practical videos and coding sessions showing all the principles applied. Check it out ✅
It's not only that you are teaching us these valuable concepts and principles, it is also very recognizable and inspiring how you both resemble a great developer in every single way.
You guys are extremely exceptional. The way you guys make things so simple is commendable. You are opening a different way of understanding concepts. Thanks a lot.
Thank you guys for putting up that architechture crash course advertised on LinkedIn. This is the exactly the topic I wanted to learn about, I recently got the clean architechture book but it became a little heavy to read as I don't have much practice architechting apps so this video is very complimentary to what I read and I start to understand everything much better, mind blowing!
Hey guys! Thank you for this awesome podcast! For me it's one of the best explanation of SOLID principles that I have ever seen. Everything is easy and very clear.
When to apply them? I think it’s more about classes and structs. There are also principles for bigger things- components (independently deployables, frameworks in xcode) Rep, Crp, Ccp and ect.
Hello! You apply the SOLID principles when you want to deliver clean, maintainable, extendable, easily testable, and composable code. Regardless of the type. (In our experience, you always want that.) For example, we want maintainable, extendable, easily testable, and composable functions and modules too. E.g., you can violate the Single Responsibility Principle with a function that has too many responsibilities. Or the Dependency Inversion Principle when the function instantiates its dependencies. And so on. The concepts within the SOLID principles can be applied at every level. And yes, there are even extra rules for modules! The SOLID principles are not the only principles around software, but they are foundational for delivering good SOFTware. ✅
Liked the Podcast. Can you guide me, now I want to implement the Like button in my View? What I'm doing here I will have two protocols. one for interacting with network and other with rendering with UI. How do make UIButton should take care of this? without view knowing all about this.
Hey Guys Thank you for your efforts in making Videos for information. Few suggestions Please try to make videos smaller duration & more informative to cover more topic At 30:00sec while stating Liskov principle, you are referring to not implementing some of the protocol method. This is not possible as swift compiler wont allow. However we can have wrong implementation which is not the scope of Liskov
Hi anand! The Liskov Substitution Principle can be applied to any kind of type substitution, including class inheritance and protocol conformance. The guideline is: "Types should be replaceable with their subtypes without altering the correctness of the system." What we meant by "not implementing the protocol method" is by leaving it empty or using fatalError to bypass the compiler, for example. This would allow the subtype to be used at compile-time, but it would break and alter the correctness of the system at runtime; thus, it's a violation of the Liskov Substitution Principle.
On September 23, 25, and 27, we'll teach you how to find fantastic iOS opportunities, double your income, and work with remarkable people. Register now: iOSLeadEssentials.com
27:00 L: Liscov substitute principle
31:00 I: Interface segregation principle
40:00 D: Dependency inversion
05:01 S: Single Responsibility
16:52 O: Open-Closed
27:00 L: Liscov substitute principle
31:00 I: Interface segregation principle
40:00 D: Dependency inversion
46:01 Bonus Q&A
Insightful!.
Thanks guys.
Glad it was helpful!
Would be nice if we went through codes and highlight those violations so we can also learn to identify it ourselves, and better yet, fix it
Hello! This is a podcast episode. We can't show code in a podcast episode as most people only listen to it (without seeing the video). But in this channel, we have hundreds of practical videos and coding sessions showing all the principles applied. Check it out ✅
It's not only that you are teaching us these valuable concepts and principles, it is also very recognizable and inspiring how you both resemble a great developer in every single way.
You guys are extremely exceptional. The way you guys make things so simple is commendable. You are opening a different way of understanding concepts. Thanks a lot.
Thank you! It's great to know you're enjoying and learning from our content. 😀
Thank you guys for putting up that architechture crash course advertised on LinkedIn. This is the exactly the topic I wanted to learn about, I recently got the clean architechture book but it became a little heavy to read as I don't have much practice architechting apps so this video is very complimentary to what I read and I start to understand everything much better, mind blowing!
Glad it was helpful, Cristian! ✅
Hey guys! Thank you for this awesome podcast! For me it's one of the best explanation of SOLID principles that I have ever seen. Everything is easy and very clear.
Great to hear - thanks!
well explained but it would be even better if you refactor code using solid. do you have any video for that refactoring code using solid
Plenty. Check this free series: www.essentialdeveloper.com/professional-ios-engineering-series
Very informative! Thank you
this is so helpful thank you guys
I think the best example of L violation: Square extends Rectangle
That's a good one!
When to apply them? I think it’s more about classes and structs. There are also principles for bigger things- components (independently deployables, frameworks in xcode) Rep, Crp, Ccp and ect.
Hello! You apply the SOLID principles when you want to deliver clean, maintainable, extendable, easily testable, and composable code. Regardless of the type. (In our experience, you always want that.)
For example, we want maintainable, extendable, easily testable, and composable functions and modules too.
E.g., you can violate the Single Responsibility Principle with a function that has too many responsibilities. Or the Dependency Inversion Principle when the function instantiates its dependencies. And so on.
The concepts within the SOLID principles can be applied at every level. And yes, there are even extra rules for modules!
The SOLID principles are not the only principles around software, but they are foundational for delivering good SOFTware. ✅
Thank you. Very helpful)
This was really helpful... Thank you so much.... 🙏
Your great content doesn't need clickbait titles
Thanks, I guess!
Thank you
Liked the Podcast. Can you guide me, now I want to implement the Like button in my View? What I'm doing here I will have two protocols. one for interacting with network and other with rendering with UI. How do make UIButton should take care of this? without view knowing all about this.
Hi Murali. Here's a series where you can learn how to implement those ideas: www.essentialdeveloper.com/professional-ios-engineering-series ✅
Hey Guys
Thank you for your efforts in making Videos for information. Few suggestions
Please try to make videos smaller duration & more informative to cover more topic
At 30:00sec while stating Liskov principle, you are referring to not implementing some of the protocol method. This is not possible as swift compiler wont allow. However we can have wrong implementation which is not the scope of Liskov
Hi anand! The Liskov Substitution Principle can be applied to any kind of type substitution, including class inheritance and protocol conformance. The guideline is: "Types should be replaceable with their subtypes without altering the correctness of the system."
What we meant by "not implementing the protocol method" is by leaving it empty or using fatalError to bypass the compiler, for example. This would allow the subtype to be used at compile-time, but it would break and alter the correctness of the system at runtime; thus, it's a violation of the Liskov Substitution Principle.