Glad these PHP tutorials have been helpful KELVEZU! I love design principles, I'm hoping once I finalize this SOLID Principles series it'll do pretty well so can cover GOF design principles and GRASP design principles as well :)
Zachary's Single Responsibility Video is out ~ big flex on his part. Quality of video went way up. I'm not sure if he's used one before, but he even used a green screen at the get go that was a pretty nice touch! ruclips.net/video/bjZ3278aXPU/видео.html
you presented a 'problem' at the end saying if we changed the report based on exec & HR's request we would be breaking the principle - how could we have mitigated this?
Mitigating this problem comes down to considering who would ask us to change our code prior to writing the given piece of code. A lot of what makes design principles difficult isn't the concept of the principle but rather taking into consideration what would break the principle prior to writing any code. BEFORE we wrote code, we should consider whom could enforce the mutation of our code. If multiple entities could enforce us to change our code, then we are not following the single responsibility principle.
instead of having a class "report" that handles whatever report is needed we should have a class for each type of report ( ClientInteractionReport, EmployeeMoralReport) and maybe an interface called "Report" for grouping all the classes... so before coding we should consider those things.. if bussiness can potentially come with new reports requirements.. we just create our new class ReportNew and we dont have to change the other ones, therefore we dont have to test anything else but the new one
Laravel's Php, that being said I'm not seeing where I'm using Laravel -- but definitely may have. Laravel's a Php framework I use extremely often. In all honesty, I don't remember if I was inside of a Laravel project or not -- made this tutorial a while back. If so I wouldn't be surprised. I'll say this, watching video right now as I'm responding to you -- I'm frankly surprised at the low quality of this lesson compared to the newer content we have. They don't sound, look, or have any sort of similarities in quality. It's crazy, my voice even sounds tremendously different in these older lessons where the lessons aren't nearly as quality as Clean Code Studio's newer Php and Laravel tutorials. It feels like one of those too well know to developer gut checks, where I'm asking myself "Did I really used to be that bad", it just happens to be for a screencast and lesson quality instead of the code this time. During the making of this tutorial, I was still in that initial learning phase where the quality was well what it is. The architecture tips and examples themselves, the code we're going through is solid. Over all the Php offered in these earlier lessons seemed pretty well received and generally liked so I've kept the lessons up. Eventually, I'm planning on redoing this entire SOLID series with higher quality tutorials that have been published lately. Every aspect and I mean every aspect - audio, animations, zooming, panning, did I mention audio - have been improved immensely. Aww - there it was - you're right just saw where I used Laravel in this Single Responsibility lesson. Laravel's "Request" - is that what you noticed to point out we're inside of Laravel? Although you are right that this lesson shouldn't have used Laravel at all, the Request helper at the time felt better because it was more readable. Not providing context on the fact I was in Laravel or how that Request class wouldn't properly work outside of Laravel was me messing up forsure. Wouldn't happen now but hey, that's process. The newer Clean Code Studio content quality is tremendously higher quality and focuses majorly on Laravel, Slim, and a bit but much less so of vanilla Php/Javascript. Eventually, I'll get back around to this series and redo all of these SOLID lessons in their entirety. Even though in this series, the quality literally improves every lesson - there's not a single lesson that I can't knit pick with a number of screen casting mistakes I made. Still make 'em for sure, but getting a bit better every day and over all feeling pretty good about the newer content we've got after re-watching one after so many months 8:D Eventually I'll redo these SOLID tutorials to raise the quality to the level of our newer content. I'm still learning every day on how to create better screencasts that are helpful and of high value.
i love how you explain things in php. Finally, a channel I can rely on PHP. keep this up bro
Glad these PHP tutorials have been helpful KELVEZU!
I love design principles, I'm hoping once I finalize this SOLID Principles series it'll do pretty well so can cover GOF design principles and GRASP design principles as well :)
Zachary's Single Responsibility Video is out ~ big flex on his part. Quality of video went way up. I'm not sure if he's used one before, but he even used a green screen at the get go that was a pretty nice touch!
ruclips.net/video/bjZ3278aXPU/видео.html
Thanks for passing on the information Samual Obryan :)
Really nice. And it is really reliable content 😊. Good job
4 years later, still the best videos on SOLID I found on RUclips.
Appreciate that
you presented a 'problem' at the end saying if we changed the report based on exec & HR's request we would be breaking the principle - how could we have mitigated this?
Mitigating this problem comes down to considering who would ask us to change our code prior to writing the given piece of code. A lot of what makes design principles difficult isn't the concept of the principle but rather taking into consideration what would break the principle prior to writing any code. BEFORE we wrote code, we should consider whom could enforce the mutation of our code. If multiple entities could enforce us to change our code, then we are not following the single responsibility principle.
instead of having a class "report" that handles whatever report is needed we should have a class for each type of report ( ClientInteractionReport, EmployeeMoralReport) and maybe an interface called "Report" for grouping all the classes... so before coding we should consider those things.. if bussiness can potentially come with new reports requirements.. we just create our new class ReportNew and we dont have to change the other ones, therefore we dont have to test anything else but the new one
That's not PHP as the title says, that's Laravel
Laravel's Php, that being said I'm not seeing where I'm using Laravel -- but definitely may have. Laravel's a Php framework I use extremely often.
In all honesty, I don't remember if I was inside of a Laravel project or not -- made this tutorial a while back. If so I wouldn't be surprised.
I'll say this, watching video right now as I'm responding to you -- I'm frankly surprised at the low quality of this lesson compared to the newer content we have. They don't sound, look, or have any sort of similarities in quality. It's crazy, my voice even sounds tremendously different in these older lessons where the lessons aren't nearly as quality as Clean Code Studio's newer Php and Laravel tutorials.
It feels like one of those too well know to developer gut checks, where I'm asking myself "Did I really used to be that bad", it just happens to be for a screencast and lesson quality instead of the code this time.
During the making of this tutorial, I was still in that initial learning phase where the quality was well what it is. The architecture tips and examples themselves, the code we're going through is solid. Over all the Php offered in these earlier lessons seemed pretty well received and generally liked so I've kept the lessons up. Eventually, I'm planning on redoing this entire SOLID series with higher quality tutorials that have been published lately. Every aspect and I mean every aspect - audio, animations, zooming, panning, did I mention audio - have been improved immensely.
Aww - there it was - you're right just saw where I used Laravel in this Single Responsibility lesson. Laravel's "Request" - is that what you noticed to point out we're inside of Laravel?
Although you are right that this lesson shouldn't have used Laravel at all, the Request helper at the time felt better because it was more readable. Not providing context on the fact I was in Laravel or how that Request class wouldn't properly work outside of Laravel was me messing up forsure. Wouldn't happen now but hey, that's process.
The newer Clean Code Studio content quality is tremendously higher quality and focuses majorly on Laravel, Slim, and a bit but much less so of vanilla Php/Javascript.
Eventually, I'll get back around to this series and redo all of these SOLID lessons in their entirety. Even though in this series, the quality literally improves every lesson - there's not a single lesson that I can't knit pick with a number of screen casting mistakes I made. Still make 'em for sure, but getting a bit better every day and over all feeling pretty good about the newer content we've got after re-watching one after so many months 8:D
Eventually I'll redo these SOLID tutorials to raise the quality to the level of our newer content. I'm still learning every day on how to create better screencasts that are helpful and of high value.
@@CleanCodeStudio Thanks, I'll be looking forward that
Laravel is PHP
@@lynic-0091 I know that, Symfony is PHP too, but, based on the title, I expected he would use the plain PHP.
@@mismattia5572 Well, the title doesn't say plain PHP.