A Notifier interface or abstract Notifier class would be the best solution but I didn't want to start delving into dependency inversion in the SRP example...it might have become a distraction.
Hello Gary, Great video, it was really really helpful! At the ISP part, let's say not just the archiver needs to read the file to do an operation on it. How should I handle that? Maybe break the interface into even smaller parts, so I have a FileReaderInterface a FileArchiverInterface and an Interface for my other operation that I want to imeplement? Thank you for the amazing content!!
Hi. Great video! One question though regarding Open/Close principle. How to deal with vendor/ directory classes that does not implement an interface? Let's say there is a x package in vendor directory, and that package has a regular class that performs some task (without implementing any interface nor extending an abstract class). How to add Decorator pattern in such case? Thank you and cheers!
That gets a bit more complex. If you need its functionality you can inject it as a dependency into your own class which does implement the interface. But try to avoid putting square pegs in round holes if it's going to cause more problems than it solves.
For the first example, instead of encapsulation, I would use an interface. And only if the class that I am trying to inject does not implements the interface (like an open source class), I would create this class. Actually, it is a classic design pattern. Globally, it is better to rely on interface which is better than abstraction which is better than concrete class. :)
@@GaryClarkeTech You were actually right not to do it, too much complexity for nothing. BTW, I learned everything about these concept from Miško Hevery (he was Mr Writing-testable-code evangelist at Google). If you google his name, you will find amazing pdfs and yt videos. Lots of tips. As it is a little old, we can see what aged well (almost everything). Take care.
I must thank you for your amazing efforts in taking PHP to general people and creating lots of awareness. 🎉🎉🎉
Love the kind words!
Many thanks for sharing your knowledge, Gary!
My pleasure! Thanks for watching!
Great video!!! Everybody who want more durable code should understand these concept.
Thanks very much!
Love your work!
Glad you enjoy it!
Coooll❤❤
Hi Gary.
I'm just curious why you didn't make SmsDispatcher and Mailer inherit from Notifier and then use a type of Notifier in your code ?
A Notifier interface or abstract Notifier class would be the best solution but I didn't want to start delving into dependency inversion in the SRP example...it might have become a distraction.
Amazing Video Buddy Keep Going ❤🔥
Thanks a lot...appreaciated!
Hello Gary,
Great video, it was really really helpful! At the ISP part, let's say not just the archiver needs to read the file to do an operation on it. How should I handle that? Maybe break the interface into even smaller parts, so I have a FileReaderInterface a FileArchiverInterface and an Interface for my other operation that I want to imeplement?
Thank you for the amazing content!!
Cheers for the kind words...
Yes just break it up and implement as many interfaces as you need
Hi. Great video! One question though regarding Open/Close principle. How to deal with vendor/ directory classes that does not implement an interface? Let's say there is a x package in vendor directory, and that package has a regular class that performs some task (without implementing any interface nor extending an abstract class). How to add Decorator pattern in such case? Thank you and cheers!
That gets a bit more complex. If you need its functionality you can inject it as a dependency into your own class which does implement the interface. But try to avoid putting square pegs in round holes if it's going to cause more problems than it solves.
@@GaryClarkeTech Thank you for response!
For the first example, instead of encapsulation, I would use an interface. And only if the class that I am trying to inject does not implements the interface (like an open source class), I would create this class. Actually, it is a classic design pattern. Globally, it is better to rely on interface which is better than abstraction which is better than concrete class. :)
You're right..but I didn't want to delve into dependency inversion before I got to it..it might have become a distraction.
@@GaryClarkeTech You were actually right not to do it, too much complexity for nothing. BTW, I learned everything about these concept from Miško Hevery (he was Mr Writing-testable-code evangelist at Google). If you google his name, you will find amazing pdfs and yt videos. Lots of tips. As it is a little old, we can see what aged well (almost everything). Take care.
This is what I need