Why pure OOP, just for the sake of doing pure OOP
Lately all I have seen is the "Pure OOP is the way to go mentality" without much reasons to back up why its beneficial. I write OOP code, but I don't write overly verbose, bloated and cluttered OOP code either. I attend Zendcon, I have my PHP certification, I read PHP blogs on a daily basis, I have had multiple OOP discussions with other developers, but in the end I still ask the question, "Why do you spend so much time writing and separating your objects? When in the end its unnecessary as you are not extending them in the future anyways."
Before I begin, I want to do a quick review on how I got onto this topic. It started a few days ago when Brandon Savage posted his article Why Great Development Tools Don't Seem To Be Written In PHP, in which I agreed with him. Further into the comments, many users mentioned the PHP bug tracker Arbit Tracker. After downloading the source and browsing the code, I came to the following conclusion and posted this comment on Brandons entry:
After looking at Arbit... Why do people always need to use SO MANY files and classes to do such a basic task? Its unbelievable how bloated some projects can get. There is a thing with being to modular.
Just take a guess at how many files are required for a basic issue tracker... just guess. There are 2,077 files and 402 folders, and remember this is still an alpha version so that can grow even larger. Basically my first reaction was "Seriously? Do we really need all these files and classes to create a simple and basic bug/issue tracker". I have nothing against Arbit, nor the developers (They know there PHP for sure), but there is something terrible wrong about this in my opinion. This is a "3rd party script that is installable on a users machine", yet looks like a full blown framework and application. When I download a script to install on my machine, I want it to be lightweight, usable, easy and customizable. I find something really wrong about this when it takes this many classes to do such a basic task, and on top of that it requires multiple dependencies like EZ Components and CouchDB (and from what I could find, this wasn't even in the source! Now add more files into the final count). After my comment everyone seemed to post the same response: "Well of course, its a pure OOP project", and "This is what happens when you do it in true OOP", and "Nothing beats an OOP setup!".
I mentioned that a project does not need an abstract, an interface or even an exception for every class in its system, and I received this lovely little response.
If you want superior software then you use the standard and that (just) happens to be object oriented methodologies.
Drop object oriented methodologies and you drop way too many other natural benefits to software development; so enough of your bullsh*t okay?
I find this response laughable. Please tell me what those natural benefits are? To expand on classes if you want to customize it or create your own? To extend them even further? Dependency Injection? Multiple other reasons... You get my point. That's what abstract and interfaces are for. So why create them when YOU KNOW you will never extend them further, or even bother creating child classes. It seems everyone is in this mentality of "Ill do pure OOP just for the sake of doing OOP."
I can see when abstract and interfaces are required, like Zend Framework for example, but even then its overkill. Very rarely does anyone ever extend or use the abstract/interfaces in Zend. I've worked at many jobs and on many projects that utilized Zend, and have even worked with individuals that do the "Pure OOP" approach, and still I have not seen them extend objects like they are supposed to be, or use OOP to its fullest. I can only recall very few instances when people actually extended the objects, and it was primarily for Auth classes to customize to fit their application.
Another thing I dislike about pure OOP approaches is the amount of code you have to write to do such basic tasks. Take for example the routing components of Zend:
$this->getRouter()->addRoute('user', new Zend_Controller_Router_Route('user/:username', array('controller' => 'user', 'action' => 'info')));I mean, whats so difficult about the following approach (below)? Why do you need to create a whole new object as an argument, when the object is just going to be a toArray() anyways and set as a property? Oh I know, its because you want to maybe use a Route_Regex class, or a Route_Hostname class. Now my question is, why would those even need to be their own class? Because they each do a different purpose and have their own methods that overwrite the abstracts? I guess that's where we disagree then. I honestly don't see a reason why these should be "split" up. The Router should manage all routes and package the class appropriately. Breaking up the classes isn't being "Pure OOP", its just being overly modular.
Say and think what you wish, but there's nothing wrong with the following piece of code either. But you'll probably find something wrong with static methods as well, seeing as how it doesn't add any OOP functionality.
Router::addRoute('user', 'user/:username', array('controller' => 'user', 'action' => 'info'));I also have a problem with the amount of getters and setters I see everywhere. Have you not heard of __call, __get, __set, __isset, or __unset? But I digress, that topic is for another entry at another time.
I'll stop ranting now, its a matter of preference. Id also like to note that CakePHP (a non-pure OOP approach, but still OOP) has the same functionality and customization as Zend and Symfony (both pure OOP approaches). So why do you think Cake is inferior to the others? Personally, I think it has more beneficial and useful functionality.