Yeah, but in Magento world there is a one problem. Only "public" methods can be used in "plugin" feature. When you want to make very flexible module you need to use this "public" very often. So normally you would use protected, but you think that there is a nice place to hook by plugin, so you need to change it to "public". I don't like this approach, but as Magento developer I appreciate when I can change some functionality by plugin and I don't need to use patches or override file by "preference".
Hi Kamil, in actuality, you really shouldn’t be using public too often within Magento code. I used to use it for everything but changed my mind after seeing tons of plugins being used, overly used, leading to spaghetti architecture. you really only want to expose those methods that others may need to modify, not your private/protected underlying business logic code. This actually isn’t a restriction of Magento - it’s the pattern for any sort of software that uses plugin-like architecture. The generated code, which makes these plugins work, uses inheritance to write the code that makes plugins possible, due to the reasons in this video.
@@MarkShustof course! But in reality very often u need to change this "closed logic", cause business wants it. I started using `composer patches` for it and I think this approach is great. It protects you while you're doing upgrade -> when parent module is changed, then patch will fail and there is a clear information that you need to rebuild your patch.
@@kamilmaliszewski7942yea it's totally a balance. But I think 3rd-party module devs need to weigh out the situation and realize when a developer will need to modify code, and to architect it appropriately, and therein lies the issue -- they rarely do this. So it's not really a problem with the architecture, but a lack of competence in design and realizing the needs of programmers.
Great idea to describe how the concept applies in the context of most known CMSs/Frameworks, I liked it
Thanks a bunch! I'm glad you enjoyed the video and the way I explained the concept with CMSs/Frameworks
You're making Magento better
Appreciate it!
I already know this, but still a good refresher. Thank you!
Glad it was helpful! I personally like refreshers like this as well. So much to learn & remember!
Hi there , can you also make videos on php interfaces and abstraction please ?
Adding it to the queue Bharath 🙌
@@MarkShust your a gem 💎
Yeah, but in Magento world there is a one problem. Only "public" methods can be used in "plugin" feature. When you want to make very flexible module you need to use this "public" very often. So normally you would use protected, but you think that there is a nice place to hook by plugin, so you need to change it to "public". I don't like this approach, but as Magento developer I appreciate when I can change some functionality by plugin and I don't need to use patches or override file by "preference".
Hi Kamil, in actuality, you really shouldn’t be using public too often within Magento code. I used to use it for everything but changed my mind after seeing tons of plugins being used, overly used, leading to spaghetti architecture. you really only want to expose those methods that others may need to modify, not your private/protected underlying business logic code. This actually isn’t a restriction of Magento - it’s the pattern for any sort of software that uses plugin-like architecture. The generated code, which makes these plugins work, uses inheritance to write the code that makes plugins possible, due to the reasons in this video.
@@MarkShustof course! But in reality very often u need to change this "closed logic", cause business wants it. I started using `composer patches` for it and I think this approach is great. It protects you while you're doing upgrade -> when parent module is changed, then patch will fail and there is a clear information that you need to rebuild your patch.
@@kamilmaliszewski7942yea it's totally a balance. But I think 3rd-party module devs need to weigh out the situation and realize when a developer will need to modify code, and to architect it appropriately, and therein lies the issue -- they rarely do this. So it's not really a problem with the architecture, but a lack of competence in design and realizing the needs of programmers.