For Great Justice

“PHP Database Classes” - Follow-Up

May 24, 2008 – 1:16 pm

In my previous post, I did an epic rant on so-called PHP Database classes. In the follow-up, I’m going to do a Google search for “PHP Database class” and see what comes up. Read on for the full story.

First link, PHP Database class with caching

ooo, caching. What I first notice is that this particular class was last updated in ‘05 - three years ago. A quick glance tells me it’s written in ye olde PHP 4, which did have something resembling object-oriented programming, but that’s about it. Since it’s three years old and written in PHP 4 (yet still at the top of the google results), I’m gonna go easy on it. Well, sorta.

First thing, *sigh*, the class is called ‘db’. What’s an db? Okay, so it’s an abbreviation for database (which in itself is a thinking error, since the class (i.e. instances thereof) do not represent a database itself, but an interface to a database, or, with a more properly abstracted ‘database class’, a connection to a database, which can in turn be used to transfer queries to the database and retrieve the result set from).

First pointer: Name your class according to what it represents. Does it represent a generic database? Call it Database. Does it represent a generic database connection? Name it DatabaseConnection (or Database_Connection, or whatever coding standard is the shit in PHP right now). Does it represent a database connection to a MySQL database? Call it MySQLDatabaseConnection. It’s more typework, but it’ll save you half the comments required to describe it.

Good class, variable and method naming is half your documentation.

Next up, there’s a generic comment at the top, which is good, but next there’s 15 or so variables declared with cryptic names such as $cnn_id, $fso, $ttl etc, and no comments whatsoever that explain what they represent, what they store, etc.

Next, there’s a connect method. Since the class claims to support multiple database types, there’s logic in there that sets some variables depending on what database type is selected through a numerical value and a switch statement… wait. Why is there a switch statement in a class that sets a variable depending on the type of connection? You’re supposed to just write a subclass that sets those values when initialized.

Switch statements to determine type and behavior of a class is bad.

The above statement is a bit non-specific, and shouldn’t be interpreted as ‘all switch statements are bad’, since it’s not true. But behavior-defining switch statements, however, are. Okay, they’ll do the trick, but it’s not good practice, let alone good design. In this example, the author describes behavior for subclasses in a superclass (or something) - which is actually quite horrible, considering that in a proper object-oriented design, superclasses should not be aware or have anything to do whatsoever with their subclasses.

But anyways, let’s move on.

Wait, let’s not. Scrolling down the source code leads to massive clusterfucks of methods with near-illegible code, switch statements for everything, etc.

The class may work, but does not belong in any proper object-oriented design. That, and it’s 3 years old and written in a now outdated version of PHP. Do not use the class if you know what’s good for you.

Oh, there’s more. Look what’s at the bottom of the page:

Troy has been a professional Internet and database application developer for over 10 years. He has many years’ experience with ASP, VBScript, PHP, Javascript, DHTML, CSS, SQL, and XML on Windows and Linux platforms.

Hahahah, lol. I hope he’s read a book or two since he wrote that code, or at least learned a proper language.

Next site plx.

Database class at phpclasses.org

Apparently has a good 5000 users, written by a 28 year old dude, and all in all, the page describing it looks… promising, in the negative sense of the word. Let’s look at the code.

There’s no date anywhere, but judging by the fact that it’s PHP 4 again, I’d guess it around the same age as the previous one.

Aaand after a quick skim, all of the comments I made about the previous code thingy apply to this one as well. It supports even more database types, which means there’s even bigger switches (replaced by if-statements in this one), and all the functions that don’t belong in any object-oriented design. Poo, next.

PHP Advanced Database Class

ohshits, there’s already a line saying $db->query(”SELECT * FROM Users”); rather large on the page. Same problems. Activating jump to conclusions mode before viewing code.

First line that I notice:

class DB

NNNOOOoOoO!1!1. Same problems, NEXT.

Database class / PHP database extension bridge

ooo, extension bridge, sounds advanced. Let’s take a look.

Hey, more than one file - there’s a ‘mysql.php’ file, a ’sqlite.php’ file, etc. Is there still hope? The code was posted in ‘06 btw, which makes it a little more recent than the last ones. Let’s dive into it, starting by the main class, dbal.class.php.

Starts with an interface, which may look promising. There’s comments, albeit shabby and inadequate. Followed by abstract class that implements the aforementioned interface… and there it goes horribly wrong. There’s a function called ’start’, which takes a variable $resource. In the method itself however, there’s a list of if-statements that check the type of said $resource, using the instanceof thingy.

Don’t. gtfo. You’re making your superclass dependant on your subclasses, which is wrong in a large amount of ways. There’s database adapter-specific code all over the place, which means that you, sir, have no idea what proper object-oriented programming is, even while you’ve grasped the concepts of defining a class, interface, and abstract class. Back to school, kthxbai.

Lessee, is there anything interesting in the list of search results… hrm, OOP in PHP from a .NET OOP Perspective: The Database Class. Might be something, that is, if the author actually knows what he’s doing.

Aaand he doesn’t. He does use PHP 5, and the post is from February ‘07, so that’s recent enough. But then I find a case statement in a DeInitialize method that calls a php function based on whether the current type is mysql or mysqli. Don’t. Make yourself a mysql and a mysqli subclass and have those define a DeInitialize method, that first de-initialize their own adapter-specific connection stuff (the mysql_close methods etc), then have it call the parent’s deinitializer. Same goes for the ExecuteQuery method, which also checks the type, same goes for the FetchResults method, which in fact copies 12 lines of code to the letter, with the only difference in the call to either mysql_fetch_result() or mysqli_fetch_result. Can be solved much more neatly, and I’d even bother posting that if it wasn’t for the fact that this is not object-oriented. A .NET OOP Perspective? I haven’t touched .net yet, but if it encourages you to create ‘object-oriented’ code like this, I wouldn’t bother with it - not personally, and I wouldn’t recommend it to anyone.

I’m not going to bother with the rest anymore. A search for PHP Database Class will all lead to examples to how NOT to create a database abstraction, and also will provide examples of what object-oriented programming really ISN’T.

When I can be arsed, I’ll try to look for PHP database connectivity thingies that are properly object-oriented. I’ll see if I can find the code for PHP’s own database objects, as well as that of the Zend Framework (if there’s any) and some found in website frameworks that, suddenly, popped up everywhere the same time Ruby on Rails did.

Tags: class, database, morons, PHP