PHP Design patterns in Laminas (Zend) - How Laminas uses them internally | Advanced PHP

Best way to learn a tool is to see how it works internally. So I figured I can go over some parts of Laminas and some Advanced PHP, and see some of the design patterns that are used inside. Let me know if you would like to see more of videos like this.
Interested in learning real-life PHP design patterns?
➡️ www.ApplicableProgramming.com/
If you are interested in programming courses related to web, please visit www.applicableprogramming.com/ to view courses where we show the problem, then we try to solve it the hard way, and then we show how we can benefit from proven solutions.
➤ LINKS
➡️ Laminas source on github: github.com/laminas/laminas-mvc/
➡️ Private "Applicable Programmers" facebook group / applicableprogrammers
➡️ Discord server / discord
➡️ Other tutorials: www.ApplicableProgramming.com
Timestamps:
Intro (00:00)
Observer (01:15 )
Singleton (11:05)
Dependency Injection (16:39)
Factory (25:19)

[@ApplicableProgramming]

Here are some free lessons from the course th-cam.com/video/a7bgGhSTTb0/w-d-xo.html

[@SlainR2]

I'm enjoying this design pattern series!

[@ApplicableProgramming]

Thanks for the message Pedro, I was not sure if people find these videos useful.
Which framework are you using, do you have suggestion for a future video?

[@amiranbari5268]

👌👌

[@ApplicableProgramming]

Thanks for watching man!

[@b4rt1j1]

Hi, thank you for introducing us laminas, may I ask about that dependency injection example with controller, there is a lot going on in controller - gets data from other services and passes them to view so basically acts like a middleman. How to prevent controller becoming mess because of a lot thats going on in it? I've read somewhere that controllers should be as thin as possible. Is it true? should it only contain logic thats not possible to encapsulate in separate service? And what about testing them since they rely on other classes?
Have a good evening. :)

[@ApplicableProgramming]

good questions El Bartos. Yes, controllers should be as lean as possible. You can think of reading controllers like reading a list of comments. Firstly you would gather all data and dependencies, prepare all variables. Then you would do all the actions, and then "conclude" with returning something back, or cleaning up or whatever needs to be done. Also, preventing a mess is not about lines of code, it is about intentionality of the code. You can make methods in controllers to do some "dirty and repetitive" part, you can delegate such functionality to objects or services, or you can do a mix of it all. I tend to put reusable code in services, if code is a single purpose then it does belong in the controller (maybe in different method).
About testing them, they are pretty much a plain object at the end, and you know what they should do inside, and you would test for that (if all conditions have been executed properly, all methods on mocks called properly etc). Check Laravel guide for testing controllers, few examples there laravel.com/docs/5.0/testing#calling-routes-from-tests:~:text=Calling%20A%20Controller%20From%20A%20Test

[@b4rt1j1]

@@ApplicableProgramming Awesome explanation, thank you!