I saw this article earlier in doing a Google search for dealing with Anemic Domain Objects in PHP. I think the author is really off when it comes to PHP as being related to VB6. His main argument is that PHP's does not enforce OOP style programming the way .NET does (or some others such as Ruby on Rails, Java or #C). He even calls PHP a "Framework." He also mentions that for large scale projects, PHP is not a serious language compared with .NET.
I think these miscues focus on the wrong issue.
His write up targets mostly the issue of PHP not being serious as a language because the object support enforcement is non-existent. He claims that a lot of the internal procedural style libraries disengage PHP programmers from using more OOP programming, which apparently allows for highly scalable, enterprise-class software.
Let's be honest here. He's full of shit.
PHP's problems as a language being ready for the enterprise has little to nothing to do with not enforcing OOP structure. Actually, that's a huge benefit because the ability to learn something like PHP is far quicker than something that enforces OOP concepts like Java. PHP is primarily a functional language, and functional languages have been traditionally easier to teach than OOP languages. My old professor in college once mentioned how difficult it is to teach OOP to new computer science students. Just to create Hello World, you have to teach about OOP theories rather than just allowing something to use:
echo "Hello world";
Not to mention not enforcing the OOP paradigm simply allows people to build software quicker. You don't have to worry about transforming your object into byte classes or anything complicated.
That said, the real problem with PHP has been the fact that most people who are programming PHP do not typically (nor probably) have fundamentals in computer science to create large scale software. Any language can be faulted as being unmaintainable if 1) there is no architect guiding the younger programmers; 2) there is no vision nor design for the piece of software; 3) the people building and maintaining the software are simply "script kiddies."
From a functional perspective, PHP is one of the richest languages around, having numerous libraries that can support many enterprise related task. You have persistent DB connections, XML parsers, XSLT functions, SOAP, WSDL, caching, graphics manipulation, etc. As a language it can scale too as you can create your own cache or use the PEAR caching system or even use horizontal caching with the memcache piece. And you can't say that PHP is not worthy of large scaled projects since companies like Yahoo, Friendster, etc. all implement PHP in their online applications.
Him calling PHP a framework is ludicrous. It's a programming language. A framework would be Zend, PHP Cake, etc. that do enforce to varying degrees (depending on the framework) the notions of good design patterns.
To say that you cannot promote good design patterns with PHP is also ridiculous. I've been my own frameworks based on the outdated MVC models, using numerous design patterns such as business delegates, service layers, MVCs, singletons, factory/builder patterns, iterators, etc. Heck without some of the newer OOP features since PHP 5, I would've had a much more difficult time designing my systems.
I think a better comparison would've been Ruby on Rails to VB6. The thing with PHP is that you can use it as a decent teaching language since it has all the qualities of a decent programming language (you can even enforce types in parameters and do limited pass-by-reference in function calls!). With Ruby on Rails though, you're teaching a limited paradigm, not the fundamentals of a programming language where you can expand the purpose outside much of a web context. VB6 likewise was limited to GUI client and perhaps some server programmer. With VB6, you're limited in the type of paradigm you are programming so the type of thinking that goes into a VB6 application is more bent towards rapid prototyping, just like Ruby on Rails.
PHP provides you with the tools and basics to build enterprise scalable applications. Rails shelters you into a paradigm and makes you think that scaffolding is king, compared to understanding how certain fundamentals like types, function callls, etc. work in a regular programming language.
The other thing is that I just don't buy the excuse that PHP is bad in his context because of not enforcing OOP thinking. And his bad being the equivalent of not being able to build scalable applications. Well, so what would you call all those C and C++ systems out there? C++ does not enforce programmers to program in OOP like Java either. I've seen so-called enterprise level systems for trading securities written in C++, where everything looked more like a csh-script than some elegant piece of reusable code.
As I mentioned before, the language itself does not impose bad thinking. It's that people who adopt a language themselves were never good programmers to begin with and never learned fundamentals of design. I've been on both ends of the spectrum where I saw horribly designed (for lack of a better term) systems built with C++, Java or these heavily praised languages as well as partaking in building monstrously scaling open source systems like Ticketmaster. And I'm certain his much beloved .NET can easily fall prey to poor design in the hands of an incompetent programmer.
I truly wish people stop blaming the languages themselves in the end for poorly designed systems. The only thing languages offer is a slight difference in taste for syntax with a few more features here and there or syntactic sugar coating to make some developer's weener hard because they enjoy the mental masturbation of the puzzle like ways of twisting a language apart.
Trackbacks: (Trackback URL)