cretaceous;10961006 wrote:as an OOP beginner I find this thread informative.. in particular (the highly respected) sneakyimp's comments on a pragmatic approach
I'm deeply flattered by the shout-out, but it's true that I'm kind of lazy when it comes to scheming for better OOP. I would never claim to be an OOP master or anything. Pester Jazz Snob if you want some crazy OOP advice. He seems to have had the OOP awakening in a serious way.
Bad OOP
I find OOP very frustrating sometimes for the following reasons:
1) People tend to encapsulate very elaborate code into some enormous OOP scheme so at the top level you get something like
require_once 'config.php';
$app = new MasterApplication();
$app->go();
Finding something like this in code you have inherited makes you feel like you've been assigned a cryptography lesson. You have to dig through all kinds of crazy file paths, includes, and object relationships to find out what is going on.
2) Classes are rarely well-documented. I can't even count the number of times I've seen a method that accepts one arg which is an array named $params and there are no comments anywhere to tell you what you should put in $params to make the class go.
3) Making changes to an OOP application to get data in one end and out the other can be a like trying to untangle a plate of spaghetti. It's easier if you define catch-all method parameters for all of your methods but then this results in exactly what I'm complaining about in problem #2.
4) Deeply nested layers of OOP tend to hamper performance in your typical PHP setup because there's no bytecode caching. If you have a PHP Accelerator like Zend Optimizer or Ioncube or something, this problem is mitigated. However, on your typical PHP setup, there's not bytecode caching so each script must be recompiled. I might be mistaken about this, but I have been told that deep object hierarchies in PHP can be slow.
Good OOP
I have found OOP very helpful for these reasons
1) When encapsulation works, it's awesome.
I had a system that used OOP to encapsulate the database. I need to switch from MySQL to PostGreSQL and it was very, very easy because access to the db was abstracted by the db classes.
2) Because constants, methods and vars can be connected to a class, you don't run the same risk of name collisions. Classes mean I can actually write simple names for my methods. Instead of snykimp_foo_init_params() for dealing some type of 'foo' thingie, i can write a class foo and just do $foo->init(); Because that init function is a method of the $foo class, it won't run on object $bar and I won't get any weird untraceable errors because of var name conflicts.
3) Neat by-product of consts//methods/vars being connected to a class is that you might have a good idea where to go looking for a definition of this class-related thingy when you stumble across it in code.
4) It helps to clarify my thinking about a complex code project by letting me focus on the object. Instead of worrying about including the right file, how to name my functions to avoid name collisions, etc., It tends to steer my thinking toward my data objects and my processes and my events.
Those are just some personal feelings about it. Nothing earth-shattering.
As for frameworks, I can appreciate that they are useful, but I kind of hate the way one must learn a framework on top of one's PHP knowledge to work on certain projects. It has kind of splintered the PHP marketplace into camps a bit with zealots backing up their project of choice. When you are new to these systems, it's often hard to determine how to thread your data through it and get it where you want. E.g., I want to style my Joomla page. Where does my CSS go???. I want a forum in Drupal. Which modules must I install???. CakePHP and CodeIgniter are pretty different, but you still have to learn their own particular syntax and the mysteries of what happens underneath only come with familiarity.
Ack. This is starting to sound like a rant and it's not meant that way. Just whinging a bit I guess.
