Here are my articles for the last two weeks on Web Builder Zone.
PHPUnit 3.5: easier asserting and mocking, which describes the new features of this release (including my MockBuilder).
CSS refactoring
Practical PHP Patterns: Value Object, a timely article while the community is discussing on Value Objects in PHP and how they should be implemented.
What we don't need in object-oriented programming, a controversial article that spawned a long discussion with many insults between OOP purists and "we have to get things done" guys.
The PHP paradigms poll results: OOP wins - did someone have any doubts?
Practical PHP Patterns: Money
What you need to know about your version control system, one of the most popular posts on DZone this week.
Practical PHP Patterns: Special Case
6 comments:
I had a question on your "what we don't need" post - I can understand how strict type method overloading can replace if/switch statements, but how would you handle these on PHP, where polymorphism is achieved through dynamic typing?
function ($var){
if (is_string($var)) $this->doStringAction($var);
elseif (is_array($var)) {
foreach($var as $val) $this->doStringAction($val);
}
}
First, in the article I say that not all ifs can be replaced by polymorphism. :)
For this particular sample, I probably would wrap at the origin $var in an object with a Composite-like interface (see the pattern), with a method applyStringAction(), and then call $var->applyStringAction($this). The Composite would have more than one implementation, one for arrays and one for strings.
I cannot say more without further details.
But that would simply transfer the if into another class, not replace it.
My point is - Whenever a language barrier exists between type operations, and you will want to use the dynamic-typing power of that language, you will need to do type checking - which is dependent on if/switch.
And another case - on that article you showed how you can use filtering to replace if statements, but essentialy, that just transfers the check into the lambda - I'm just not sure if what you are saying is that logical boolean checks should be avoided, or that they should only stay on the "leafs" of the object chain?
It depends - if an array $var is created in a different place with regard to the string $var, for example a findAll() vs. find() methods, it's very simple to wrap it without conditionals.
The point was that the majority of conditionals can be replaced with the extraction of a collaborator or (Strategy) or a Template Method. This Google Tech Talk explains it very well:
http://www.youtube.com/watch?v=4F72VULWFvc
Of course it's not immediate to transform a code snippet into another solution.
OK, so after watching this I did get some more sense of what you're talking about - it isn't about eliminating ifs as much as moving them out of the application logic and into the constructors. Makes sense.
Of course, I can see how I can always abstract everything to make it work (there is no stopping abstracting both strings and arrays to an object that receives a Lambda and passes values to it) but it feels a bit of an overhead. But it's a good challenge for refactoring code.
Another good post....will be back for more!
Post a Comment