[jbwyme]

There is certainly a line that can be crossed when it comes to over thinking OO. However, Dependency Injection enables you to write much more testable code where in many cases people would use static methods therefore breaking the ability to properly unit test.

As for your argument against traits, using global functions clutters up the global namespace and doesn't lend very well to modular development. Next thing you know you have two libraries with "create_hash($string)" or something similar that do two different things.

*Edit: clarification

[contingencies]

(1) Though I am not familiar with the subject (I avoid OO PHP), you seem to raise a valid point; however one could also consider that the same could probably be achieved with less lines of code, arguably looser coupling, greater re-usability and increased conceptual clarity by not writing that code within an OO model at all. (2) The namespace argument is a valid one; however; in what percentage of deployment environments is such a concern truly likely to come to the fore? Usually very few, and when combined with non-braindead naming conventions (eg. 'mylibrary_function()') basically never.

[wvenable]

> one could also consider that the same could probably be achieved with less lines of code, arguably looser coupling, greater re-usability and increased conceptual clarity by not writing that code within an OO model at all.

OO is all about loose coupling, greater re-usability, and conceptual clarity. That is literally the point of it all. You can fume about the abuse of OO but the exception is not the rule. It's quite unlikely that, in general, plain old procedural code is better for coupling, re-usability, or clarity unless your problems are boringly simple.

[contingencies]

> OO is all about loose coupling

It's theoretically an interesting language pattern. However, it grew from controlled environment of experiments for which it is most suited.

It's perhaps telling that, today, a fairly large number of experienced programmers tend to avoid it. Have a look at the interviews in 'Coders at Work: Reflections on the Craft of Programming' for some good examples.

I actually just bought this book again specifically to find this quote, which is gold:

"Armstrong: I think the lack of reusability comes in object-oriented languages, not in functional languages. Because the problem with object-oriented languages is they've got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions-all the data comes in its input arguments and everything goes out and leaves no state behind-it's incredibly reusable. You can just reuse it here, there, and everywhere. When you want to use it in a different project, you just cut and paste this code into your new project. Programmers have been conned into using all these different programming languages and they've been conned into not using easy ways to connect programs together. The Unix pipe mechanism-A pipe B pipe C-is trivially easy to connect things together. Is that how programmers connect things together? No. They use APIs and they link them into the same memory space, which is appallingly difficult and isn't cross-language. If the language is in the same family it's OK-if they're imperative languages, that's fine. But suppose one is Prolog and the other is C. They have a completely different view of the world, how you handle memory. So you can't just link them together like that. You can't reuse things. There must be big commercial interests for whom it is very desirable that stuff won't work together. It creates thousands of jobs for consultants. And thousands of tools to solve problems that shouldn't exist. Problems that were solved years ago."

Peter Seibel. Coders at Work: Reflections on the Craft of Programming (Kindle Locations 2680-2689). Kindle Edition.

[wvenable]

> It's perhaps telling that, today, a fairly large number of experienced programmers tend to avoid it.

No, you have a small number of proponents of functional programming who avoid object oriented programming. These people are a statistical anomaly compared to the overwhelming number of experienced developers working in and on object-oriented technologies in the majority of platforms and languages. It's not even necessary to advocate for OOP anymore.

Perhaps if you were using functional programming instead of OOP I would give you points for this line of reasoning but you aren't.

[contingencies]

> Perhaps if you were using functional programming instead of OOP I would give you points for this line of reasoning but you aren't.

Each to their own. FYI, I spoke at Code Generation 2010 at Cambridge University in the UK and generate much of my code from DSLs and/or other kinds of models these days.

Functional is good, pragmatism is also good. OO is in my view over-used and rarely the best solution.

[ccdan]

Where is functional "good?" Other than in abstract math or FP advocates' heads? :D If it had been any good, it would have been used on a pretty large scale... we live in a pretty large world and someone would have figured it out... and then the others would have fallowed suit...