After 10 years of coding in PHP both OSS and products, creating 2 frameworks used in production on numerous websites, I still wonder. Why do you need to stuff interfaces in the mix? Why such complex patterns for something so simple?
What I do and it works very well, is that I register plugins, callbacks in the application configuration:
And I can iterate over them and activate them. It is fast, flexible, you can easily test the callbacks in your unit tests, etc. Note that this is the standard approach to load components with Django.
Well, that just executes code. That doesn't alter your application flow, unless you do that during runtime at (for lack of a better word) cutpoints. And if you do it there, it's basically Chain of Responsibility, without the "chain can be cancelled" part.
Just because the pattern has a name, doesn't mean it can't be simple. In fact, a lot of the patterns are implemented all over the place under different names and with slight tweaks.
An important point is to understand the difference between the patterns, and know how to identify them. You can call a cow a lion, but it'll still moo just the same...
What I mean is that most of the time people tend to fire heavy duty classes or libraries to implement these patterns when you can implement just what you need with very little overhead using the built-in language constructs.
I use both Python and PHP extensively and I find interesting that Python developers try to go to the minimum that work while PHP developers try to go the nice conceptually "right" way. I wonder if this is because the PHP developers kind of need to prove that they can do rigorous OO programming with their language or something like that where the Python developers do not care and just do it the simple intuitive way.
I like using classes with PHP not because I have anything to prove, but because I like having auto-complete for my properties and methods in Eclipse and I like getting compiler errors if I mistype a method name.
I'm getting more used to using generic structures and anonymous functions as I write more Javascript but it bugs me sometimes having to look at the source code or API docs to remember what parameters are available for a method call.
I guess it's being lazy in a different way - I like to do more work upfront so I can be lazier later!
Excellent post. I like seeing advanced PHP stuff here. The ignored step-child of languages around here, it seems.
Even though I'm a bit of an OO snob and use design patterns in my work, I also like the simplicity of WordPress's plugin system. I'm not even sure what it would be called but it's proven to be really effective with thousands of plugins.
@jakejake Wordpress uses a procedural version of the mediator pattern (just like Drupal's hooks).
As I said in my post, just because an application doesn't use classes, doesn't mean it's not OOP or borrowing OOP patterns (and Drupal is actually a pretty good example of that).
I suppose resembles the mediator. I just find it to be really simple even though I don't write code in a procedural style, I appreciate different techniques. I think what makes me an OO snob is that I want the interfaces to be there so my IDE or the compiler/interpreter can tell me if I missed a parameter or didn't return the right type.
Actually, my impression is that the php-is-bad dogma has eased up a bit recently. And good at that - programmung language religion gets boring very fast.
It is strange and interesting to see the perception of a language change. Javascript has probably had the fastest and most extreme change in my mind - going from a tool for building doo-dads and alert boxes to one that has MVC frameworks, server-side code, etc.
I do as well. Just having every function that you write instead of returning values, return values through a "do_plugins" function.
It's such a simple and easy thing to write into your code with almost no effort, yet if you do it for every function your app would wind up being extremely pluggable.
12 comments
[ 2.5 ms ] story [ 44.6 ms ] threadWhat I do and it works very well, is that I register plugins, callbacks in the application configuration:
Then in the code I get my configuration like this: And I can iterate over them and activate them. It is fast, flexible, you can easily test the callbacks in your unit tests, etc. Note that this is the standard approach to load components with Django.Just because the pattern has a name, doesn't mean it can't be simple. In fact, a lot of the patterns are implemented all over the place under different names and with slight tweaks.
An important point is to understand the difference between the patterns, and know how to identify them. You can call a cow a lion, but it'll still moo just the same...
I use both Python and PHP extensively and I find interesting that Python developers try to go to the minimum that work while PHP developers try to go the nice conceptually "right" way. I wonder if this is because the PHP developers kind of need to prove that they can do rigorous OO programming with their language or something like that where the Python developers do not care and just do it the simple intuitive way.
I'm getting more used to using generic structures and anonymous functions as I write more Javascript but it bugs me sometimes having to look at the source code or API docs to remember what parameters are available for a method call.
I guess it's being lazy in a different way - I like to do more work upfront so I can be lazier later!
Even though I'm a bit of an OO snob and use design patterns in my work, I also like the simplicity of WordPress's plugin system. I'm not even sure what it would be called but it's proven to be really effective with thousands of plugins.
As I said in my post, just because an application doesn't use classes, doesn't mean it's not OOP or borrowing OOP patterns (and Drupal is actually a pretty good example of that).
It's such a simple and easy thing to write into your code with almost no effort, yet if you do it for every function your app would wind up being extremely pluggable.