Although it sometimes feels like there’s a new programming language coming out from somebody every couple of weeks, I believe it is now fair to say that both PHP and Python are very well established platforms for development. Both enjoy considerable corporate support, as well as very active user communities. They also jump across the operating system divide reasonably well.

The following is not meant to be a full tutorial on the Python programming language for a PHP developer. I would hope that it would make reading a full tutorial a good bit easier. Python is a rich language with a wide variety of capabilities. If I leave a few of the Python details out of the picture I just want you to know up front this is not meant to bolster PHP.

Where They Came From

Most PHP folks have already heard the story so many times as to cause eyes to roll when yet another site gets into the history of their platform. Sorry folks, need to do it here again. I’ll try to keep it short.

PHP started as a set of Perl scripts to solve some form processing issues on the author’s web site. They were his Personal Home Page tools, and thus the acronym was born. Over time the number of those functions increased to a point where PHP was becoming a full language itself. Eventually the engine was moved to C and the Personal Home Page tools meaning was dropped. Today PHP is no longer an acronym, just the name of the language. At it’s core from its very earliest days PHP was a procedural language to get things done on the web quickly and easily.

At the time Perl ruled the dynamic web site game. For all the good or bad you can say about Perl, it was outpaced by the ease of use that PHP provided programmers. When PHP got matched up to a MySQL database that’s when things really started to shine. Put those two on a Linux machine running the Apache web server and the LAMP stack was born. PHP didn’t really need any of the other parts, as it ran on other operating systems with different web servers and could talk to a wide variety of database engines. Still, LAMP is where the success really took off.

Python started life a bit differently. Where PHP sort of became a programming language almost by accident, Python began life as a better way to develop a general purpose programming language. Object oriented at it’s core, but still supporting procedural methodologies so it could be used for scripting as well as a scalable programming language. It too was focused on simplifying the life of developers by taking care of memory management and removing extraneous syntax.

How Different Are They

Once you get past some of the definitions the languages use to describe certain aspects about themselves, there are more similarities than differences. To be sure, there are differences, but many of the same programming structures you would do in PHP look very similar in Python. You’ve got “if” statements, “while” loops, strings, integers, classes, objects, inheritance and enough tools in either language to carry over knowledge from one to another.

What is notable about Python, compared to most languages, is what it doesn’t have. Mostly, a lot of the carry over syntax from C and Perl that got stuffed into PHP. If you’re making the leap into Python say goodbye to your good friend the semi-colon “;”. In Python the end of a line is the end of the command, so there’s no need for them. They can be used for compounding multiple statements on a single line, but that’s just sloppy no matter what language you’re talking about.

You can also say goodbye to those lovely curly brackets “{ }” to define your “if” and “while” structures. In Python you define a structure by spacing. Here’s a quick look at some very basic PHP and Python code illustrating the difference.

-----------------------------------
<?php
$x = “Howdy”;
if ($x == “Howdy”) {
  print “Howdy back atcha!”;
  $x = “”;
}
?>
-----------------------------------
#!/usr/env python
x = “Howdy”
if x == “Howdy”:
  print “Howdy back atcha”
  x = “”
-----------------------------------

I’ve included the PHP tags and the “#!” so you know which language is which here. In the Python example you’ll note that the “print” statement is indented following the “if”. This isn’t just good style, it’s a requirement in Python. Every command indented along with that “print” is considered a part of the “if” block.

Most comments I have seen out there by folks who don’t like Python point to this single syntactic detail as a reason for their dislike. The notion that using proper style as a part of the language’s syntax is just wrong in their eyes. From Python’s perspective, any decent programmer is already going to be indenting their code in this fashion, so why not lose all that extra cruft and make it part of the syntax? Furthermore, by getting rid of that extra junk there will likely be fewer syntax errors due to the missing brace or semi-colon.

Python makes a good point here. I doubt there’s a single PHP developer alive who hasn’t been caught by a missing semi-colon, or improperly nested brackets. In practice, I definitely don’t miss those semi-colons which aren’t much more than a legacy from C. I do miss those curly brackets though. Especially since my text editor is able to automatically show the matching brace when the cursor is near by. With nothing but indentation defining code I find it a little more difficult to visually define a block.

Issues of style are highly subjective. You could argue that Python’s layout looks more like a page layout made up of paragraphs. Without the extra punctuation source code can look cleaner. Even though Python essentially uses style to define blocks, there are still numerous ways for a programmer to obfuscate the code. When it gets right down to it, the readability of the source code is still up to the programmer to follow the style guides the language encourages.

You should also notice the difference in the variable “x”. There is no special character, like PHP’s “$”, to define a variable. The variables do look a bit cleaner, but once again without some way of flagging an editor there’s no good way to highlight variables. Another minor annoyance is that you can’t do something like:

$name = “Bob”;
print “Howdy there $name”;

You would instead have to do something like this in Python:

name = “Bob”
print “Howdy there “ + name

Hey, where is the “.” dot connector for strings? Python uses “+” to concatenate strings. This turns out to be a much smarter way of doing this. By not using “.” for string concatenation Python can use that dot for accessing object methods. As opposed to PHP using Perl’s nasty looking arrow thing “->”. I’ll get into object model a bit later, as this is a huge part of what makes Python what it is.

Lists, Dictionaries, and Tuples Oh My

There are other notable syntax differences, but these are usually pretty straight forward to mentally convert over to. One of the nastier stumbling blocks when reading about Python is trying to keep track of what a List, a Dictionary, and a Tuple are. These are essentially overly fancy names for arrays.

Lists and Objects

The following is an example of an index array in PHP and a list in Python.

-----------------------------------
<?php
$z = array(“stuff”, “things”, “widgets”, “gizmos”);
print $z[2];
?>
-----------------------------------
#!/usr/env python
z = [“stuff”, “things”, “widgets”, “gizmos”]
print z[2]
----------------------------------

Both of these create a list of strings that can be accessed by an index value. Where the two languages diverge is how you deal with this data. Let’s start by adding a new element to each then sorting the data.

-----------------------------------
<?php
$z[] = “garbage”;
sort($z);
?>
-----------------------------------
#!/usr/env python
z.append(“garbage”)
z.sort()
-----------------------------------

This illustrates a fundamental difference in how these two languages view data. In PHP, the variable $z is the container for the array in question. Since $z actually contains this data, it would make sense that in order to do something to that data you would need to pass it on in to a function to process it.

This list of elements in Python is actually an object, with z acting as the pointer to that object. An object carries with it the actions that can be performed on it via methods. In this case, it makes sense that rather than passing z to a function you would instead access a List Object method to manipulate it. In a really rough way, you can think of it like the following PHP class.

<?php
class ListObject
{
  $listData = array();

  public function __construct()
  {
    foreach (func_get_args() as $arg) {
      $this->listData[] = $arg;
    }
  }

  public function append($data)
  {
    $this->listData[] = $data;
  }

  public function sort()
  {
    sort($this->listData);
  }
}
?>

Again, this is a really rough way of looking at what Python is doing. When you created that list called z you were actually creating a new object. Like if you were to do the following in PHP.

<?php
$z = new ListObject(“stuff”, “things”, “widgets”, “gizmos”);
$z->append(“garbage”);
$z->sort();
?>

Everything in Python is considered an object. When you create a list, dictionary, a string, etc., you are in actuality creating a built in Python object of that type. This has provides for benefits that a Python developer can make good use of.

PHP has 75 functions to deal with handling arrays. They all have to exist in the global namespace, so you can’t put together a user defined function using any of those names. Python doesn’t run into these kinds of namespace issues.

You can actually extend Python’s built in types. So, if you need a method to deal with a List that Python doesn’t have then you can easily add it in through inheritance.

Since Python’s built in types are run in C the methods are wicked quick.

Cleaner namespace, faster execution, extendability… what’s not to love?

For PHP, giving over the ability to override a built in function is a no go. Not because the language couldn’t allow something like this, but it starts into issues with the integrity of the commands. When you ask for a sort of the elements in an array you always know that you’re running the real sort function. In Python things may not be that straight forward.

This is also not because PHP isn’t object oriented from the get go. Even a language like Java, which is also very centered around the notion of objects, doesn’t allow overriding built in methods. For some, Python’s flexibility in this regard is seen as a good thing, where others may regard this as a liability.

Not only are creating and filling lists different under the hood in Python, but getting data back out has some pretty cool features to it. The first time I saw a setup like this was way back on Atari Basic (okay, I’m really showing my age here). Python calls it “slicing”. Here’s how that plays out:

#!/usr/env python
print z[0]

Nothing too special there. That outputs “stuff”. Now here’s a taste of the clever stuff.

#!/usr/env python
print z[0:2]

So that’s kind of odd. What you get back from that is ['stuff', 'thing']. This outputs a list, as denoted by the brackets, with the first 2 elements. I’ll leave the full story about slices to a more complete Python tutorial, but this is one of those features that once you get acquainted with it you’ll be looking over the fence at Python’s yard in envy. It also knocks out an entire stack of those array functions PHP relies upon.

I won’t be getting into it here, but strings are dealt with in a similar way. Instead of substr() kinds of functions you use slicing to pull out portions of text.

Dictionaries

So if a list is sort of like an indexed array, what is a dictionary? Pretty much an associative array. You get to put items into this array using key/value pairs.

Just when you thought you would see the last of curly brackets “{ }” by jumping to Python, they come right back with dictionaries. Where a list uses brackets to frame up the data list, curly brackets frame up dictionaries.

-----------------------------------
<?php
$z = array( “stuff” => 2,
            “things” => 42,
            “widgets” => 37,
            “gizmos” => 12 );
print $z[“stuff”];
?>
-----------------------------------
#!/usr/env python
z = { “stuff”: 2,
      “things”: 42,
      “widgets”: 37,
      “gizmos”: 12 }
print z[“stuff”]
----------------------------------

Like lists, dictionaries are an object type with a variety of methods for manipulating them. As you might well imagine, you deal with these a good bit differently than what you would expect from an associative array.

Rather than getting into the details of dictionaries, I would like to point out one advantage to this overall approach versus what PHP does. Picture one such array in PHP that you have built up. You then add a key/value pair where the key is an integer. Wrap it in quotes all you like, PHP will take that and make it an index value even though what you wanted was an associative style key/value.

Python doesn’t suffer from this problem since a list and dictionary are independent objects. In a dictionary, a key is always a key. I really think Python’s approach to explicitly separating these two kinds of grouped data is a huge benefit.

Tuples

Finishing off the stack of data types that hold multiple values we have the “tuple”. Simple as I can put this, a tuple is a list that the values of can not be changed in place. If you were to actually study up on Python you would most certainly be well versed in “mutable” and “immutable”. Not getting into all of that here beyond saying that a tuple is immutable since it can’t be changed.

For example, when I sorted the list earlier that actually altered the list object in place. A tuple can’t be altered in place, so you won’t be running a sort, or any other method that would alter it. So why have tuples at all? One reason for them is a degree of data integrity. Since they can’t be altered, you know that when you pass a tuple around it retains it’s value. More importantly, tuples can be used in places where lists can’t be. Things like function calls and such. In fact, you see something like a tuple all the time in PHP without thinking about it.

So lists have brackets “[ ]“, dictionaries have curly brackets “{ }”, and tuples have parenthesis “( )”. Pretty much any time you see values in parenthesis you’ve got a Python tuple.

-----------------------------------
<?php
$z = array(“stuff”, “things”, “widgets”, “gizmos”);
print $z[2];
?>
-----------------------------------
#!/usr/env python
z = (“stuff”, “things”, “widgets”, “gizmos”)
print z[2]
-----------------------------------

I could go on for a while about the various syntax issues between the languages, and many very good books do just that. Time to dive into more controversial stuff.

Object Oriented Code

Both of these languages now support object oriented design, thanks to PHP5. Python has always had this in place, but it’s model is a bit different. Python uses “class” to define objects, like PHP. Unlike PHP, Python objects are pretty much wide open at all times. There’s no concept of “private” or “protected” members or methods. Any data member can be altered by any code accessing that class. You can even dynamically assign new data members to a class without having to do so in the class itself.

You can simulate similar behavior with PHP’s __set and __get magic methods. With Python, this kind of dynamic assignment is built in to every class, whether you want it or not.

If that last sentence sounded a little biased, my apologies. I was hoping it would sound very biased.

In my personal opinion a class should be a fixed blueprint used to define an object. Python seems to see a class as just another means for wrapping data into a container with inheritance benefits. Depending on how you view OOP design issues this may be a good or bad. Even from a PHP perspective, which plays fast and loose with a number of design issues, Python’s approach may be a bit much in providing flexibility.

Inheritance

With PHP a class may inherit from exactly one parent. That parent can in turn be inherited from another parent and on up through any number of generations. Python can of course inherit from a parent, but it’s not limited to just one. You can inherit numerous parent classes into a single class.

Languages that restrict inheritance to a single parent, like PHP, usually point to naming conflicts as the reason for the restriction. Python deals with that by providing for a specific search order to how it looks for methods or members in the class tree. For example:

class MyClass(Parent1, Parent2, Parent3):
  pass # an empty statement

Let’s say you have a method called doSomething() that is in one of those parent classes. Python begins at the lowest level of the tree, then at each level goes from left to right looking for that method. In the above example the search starts with Parent1, then to Parent 2, and so on. If it isn’t found, on up the tree it goes and repeats.

The cool part about this kind of inheritance is that you can have a number of utility classes that can be inherited into a wide variety of classes. Things like database handlers, file management, or text processing. You can maximize the reuse of your code by just inheriting into the class you’re writing and away you go.

There’s a hidden cost here though. Well, a number of them actually. As restrictive as PHP is about inheritance, you always know there is going to be a linear path from the lowest child to the top of the class tree. Tracking back is a relatively simple process. Allowing multiple inheritance opens the door wide to creating a maze of class trees to climb through.

A more fundamental problem here is the notion of “IS-A” and “HAS-A” relationships. This being a metaphor that developers can use to determine whether or not you should inherit from a class or use an object from that class. By allowing inheritance from multiple parents this metaphor is an easy one to break, thus muddying up the waters of what is considered proper OO design.

Of course you don’t have to actually use multiple inheritance in Python. You can structure your code as you see fit. The problem with allowing this at all comes in when you need to work on or with someone else’s code. Did that other person already merge an unrelated class into the tree you wish to inherit from? How wide is that class tree you’re wanting to inherit from? What kind of time is involved with hunting all of that down?

You can run through these arguments back and forth for a while. You’ll certainly see this in mailing list threads as the “proper” way to handle OO design is debated. How much importance you put on being able to control access and structure of your classes will be a determining factor in whether Python is right for you. Java is on one extreme of defining exactly what a class is, and being able to lock it down. Python over on the other extreme with a focus on flexibility. PHP sits sort of between the two in this regard.

Class and Methods

Back in my earlier post discussing and introduction to Object Oriented Programming for PHP is made heavy use of a Product class. Here I’ll present to you a similar class as it would appear in Python.

class Product:
  model = ""
  description = ""

def __init__(self, index):
  self.pullFromDatabase()

def showProductSpecs(self, index):
  # Some clever display code

def displayProductPrice(self, index)
  # Clever price calculations returned

def pullFromDatabase(self, index)
  // Fancy database query would run here
  self.model = dataRow[“model”]
  self.description = dataRow[“description”]

No curly brackets, and no semi-colons. Instead of __construct() you now have __init__(). Both of those methods do the same thing, run when an object is created. The other big difference you should have noticed is that “self” stuff in the argument list for every method. This serves the very same purpose as “this->” does in PHP. For some reason Python decided that just having that automatically pass into a method wasn’t explicit enough, so you have to pass it in through an argument.

The other, and probably more valid, reason for having to explicitly state “self” in the argument list is due to the fact that there’s really no such thing as a “static” method in Python. When you define a method without “self”, it essentially becomes static since it doesn’t have access to an object instance that its class created.

In all fairness, the need for static classes in Python may be a moot point. The main reason they’re handy in PHP is due to being able to group what are essentially procedural functions within the namespace of a class. Python doesn’t have the namespace issues of PHP, so needing to group functions into a class is generally something you wouldn’t need to do.

Using a class to create an object is as simple as…

p = Product(12)
print p.showProductSpecs(12

Looks like I missed the “new” command. If this were PHP you’d be right, but in Python there is no keyword for creating an object. Everything is an object, so any time you see an assignment like the above happening an object is being assigned to a pointer.

Using an object is pretty much the same as with PHP, just a dot “.” instead of that dash arrow thing “->”.

Namespace Handling

A file containing functions, variables, and classes in Python is considered a “module”. Importing a module from one file into another doesn’t (by default) just jump into the global namespace. In fact, Python doesn’t even have a concept like a global namespace. The scope of naming exists within a module at the top most level.

To briefly illustrate this point let’s pretend there is a function called doSomething() in the file “MyLibs.py”. You want to utilize this function in the file you’re working on. Here’s how this plays out in the code.

import MyLibs
x = MyLibs.doSomething()

There are a wide variety of variations on this theme. You can change the import line to read “from MyLibs import *” and not have to specify “MyLibs” to call functions from it. That line could be tweaked to only import the functions or classes you specifically want to utilize, or even give a specific name to how you access resources from that module. I won’t bore you with all the details of dealing with modules. These are some very powerful tools for bringing in code from other files without running into the kinds of namespace issues that PHP suffers from.

Python only has a about a dozen or so reserved keywords as a part of the core language. As I mentioned earlier, PHP has 75 keywords just to deal with array functions. Python allows a programmer to keep a fairly tight rein on the allowed scope of the namespace, where PHP throws tons of stuff into a global namespace that everything has to fit into.

Clearly Python has much better structure in handling namespace. The only down side to this is that you really can’t define a global constant. In PHP these can be pretty handy for dealing with site preferences and other pieces of information that need to cross scope boundaries. I’ll grant you, that’s a very minor point, but one to be aware of if you’re looking to migrate code to Python from PHP.

What Got Left Out?

In short, lots! I warned you up front this was not going to be an attempt at a full Python tutorial. I didn’t get into string handling, or differences in “for” loops. For the purposes of this post I believe much of that to be minor issues of syntax that a reasonably competent PHP developer would pick up on through a true tutorial. Those things are handled differently between the languages, but I don’t believe they do all that much to illustrate the conceptual differences.

Advanced Python topics like threads were left out since PHP doesn’t support them, and I wouldn’t have done the topic justice in this format. This is the same reason why GUI development and/or network sockets weren’t discussed either. There’s really good reasons why there are big fat books that cover the full scope of capabilities. Both of these languages do a lot of stuff!

Summary

At the beginning of this post I talked about what drove these languages forward from their early days. Even after all these years most PHP code is produced to do one basic task, get to that closing </html> tag as quickly as possible. Run through things as quickly as possible, then dump out of memory just as quickly to get ready for the next page. This all obviously stems from the fact that PHP and web development go hand in hand. This is a task that PHP was built for and does a fine job at. Certainly PHP is capable of more than that, but I would venture to guess that PHP use away from the web is fairly limited.

Python is a general purpose platform, that can also be used for web development. You could use it to script web pages, or even program the web server itself. It’s proven itself as a fine GUI development platform with a wide variety of supported widget sets that can run on multiple platforms. It integrates well with Java, and can make use of C libraries. Anything from a simple shell script to an advanced multi-threaded application can make good use of Python.

Each of these languages have strengths and weaknesses in their approach to solving the universal problem of how to tell these stupid machines what to do. Ultimately it’s up to you to determine which of these solutions best fits the problems that confront you.

If you are already knowledgeable in one of these two languages I would recommend the following.

• Listen to the supporters of each. They can provide valuable insight into why these platforms do things the way they do.
• Ignore suggestions pointing you to use this language or that. Always keep in mind that humans have a basic need to feel justified in their decisions. Getting others to agree with their world view helps to do that for them, but most likely will do little for you.
• Focus on the languages that are getting talked about the most, and where actual applications are coming out of. If certain languages are getting little attention there’s probably a good reason why.
• Get knowledgeable about C, C++, Perl and Java. Both PHP and Python derive quite a bit from these languages, even if what they got out of one or the other was to not implement something.

Hopefully I’ve provided a reasonable comparison of these development platforms to you. Leave a comment below and let me know what you think.

Building on my previous article about abstracting your database inserts and my little introduction to Object Oriented design, I would now like to put these two together for you. While I’m at it, let’s see what we can do about pushing many of your data requests to your database into the background by having the table structure define your objects.

Fair warning, not much of what I’m about to get into makes sense without referencing my other two articles. If you’re already comfortable with Object Oriented development you can certainly skip that article (though your comments would be appreciated there).

Refresher

In my Object Oriented post I mentioned how doing things in this manner would save you some serious coding time. It does this by getting you into thinking about how to best group similar bits of data and actions then share them through the rest of your code through inheritance. What does this isn’t so much the structure of the code itself, but how the developer (that’d be you) approaches the problems they face.

My next post got into the notion of utilizing the structure of your data in the database to do something intelligent with it. In that case I showed how you could get a better handle on putting stuff into the database in a way that was both easier and provided for better integrity of that data.

Building on both of these concepts I intend to show you how we can take the data structure of your database to help define a wide variety of objects using just a wee bit of inheritance.

Building The DatabaseObject Class

I really need to learn how to come up with cooler names. Even though it’s got a boring name it should provide us with something descriptive as we move along. So let’s get together the beginnings of this.

class DatabaseObject
{
  private $objectData = array();
  private $fieldList = array();
  private $primaryIndex = "";
  private $indexValue = 0;
  protected $dbPtr = FALSE;
  protected $databaseTable = "";

  public function __construct($id=0)
  {
    $this->dbPtr = fancyDatabaseConnector();
    $this->indexValue = intval($id);
  }
}

Not much to it at this point. We’ve got a couple of arrays, some strings, and an integer for our data members. A simple constructor that passes an integer value along to the $indexValue member. So, let’s get into what all this is supposed to do.

The $objectData array will keep all the data for an object stored in an associative array. You know, like the one you get from running a mysql_fetch_assoc() function. The field names will act as the key, with what is either in, or needs to go into, the database as the value. Needs to go into? Oh yeah, we can also use this to update the database. We’ll get there.

If you recall from my database abstraction post, I used $fieldList as a place to store information about the field in question with a simplified subset of types. In that earlier post that information was forgotten, but now that we’re in Objectville we can not only remeber this information, but use it.

The $primaryIndex will be the name of the field that stores… wait for it…. the primary index! We’ll assign that when we go to populate the $fieldList array. On a very related note, the $indexValue will be the, lacking a better way to say this, the value of the primary index. Pretty simple stuff huh?

The constructor starts by calling out to a database connection function. I didn’t want to get bogged down in connection details or the error handling that you “should” have in there. For what I’m talking about here, just know you’ve got a database resource sitting in the $dbPtr member.

Last in our data member parade is the $databaseTable. Kind of weird that it’s blank, and it has a different permission set. I’m going to let the child class deal with that one, but I need it at least defined here for methods that will be running here.

Getting The Data

At this point we can’t get any data out of the database no matter how many fancy methods we toss in there. We don’t know which table to get that data from! Sounds like before we go any further we’ll at least need the skeleton of a child class.

class Product extends DatabaseObject
{
  protected $databaseTable = "Products";

  public function __construct($id=0)
  {
    parent::__construct( intval($id) );
  }
}

Yes, our good friend the Product class has returned to us from the OO tutorial post. This time he’s not the top of the tree, just a child of DatabaseObject. To make sure the parent class gets passed the index value an explicit call is made to the parent’s constructor.

Getting back to the DatabaseObject class, let’s get a little pulling action going on from the database.

class DatabaseObject
{
  private $objectData = array();
  private $fieldList = array();
  private $primaryIndex = "";
  private $indexValue = 0;
  protected $dbPtr = FALSE;
  protected $databaseTable = "";

  public function __construct($id=0)
  {
    $this->dbPtr = fancyDatabaseConnector();
    $this->indexValue = intval($id);
    $this->pullFromDatabase()
  }

  public function getValue($field) {
    if ( array_key_exists($field, $this->objectData) ) {
      return $this->objectData[$field];
    } else {
      return FALSE;
    }
  }

  private function pullFromDatabase()
  {
    if ( !$this->indexValue
         OR !$this->primaryIndex
         OR !$this->databaseTable) {
      return FALSE;
    }
    $id = $this->indexValue;
    $idFld = $this->primaryIndex;
    $table = $this->table;

    $query = "SELECT * FROM ".$table." WHERE ".$idFld." = ".$id;
    $queryResource = mysql_query($query, $dbPtr);
    $this->objectData = mysql_fetch_assoc($queryResource);
  }
}

This still isn’t quite ready to run. It seemed like a good stopping point to explain what has happened, and to illustrate one of the nifty little aspects of dealing with an object.

Once the object is constructed it then runs the pullFromDatabase() method. Within that method if anything we’re going to need is missing it doesn’t run. Sure, we’ve got the $indexValue and the $databaseTable from the child class, but we still haven’t hunted down the $primaryIndex yet. I’ll be getting to that bit shortly.

I would like you to notice at this point something about the structure of pullFromDatabase(). There are no arguments being passed in. Everything that method needs to know to run is sitting in those data members. It also doesn’t return a value, since it directly assigns what it has pulled back from the database to this objects $objectData. For you folks still working through getting out of procedural land, this is a pretty good example of how sharing data within an object class works out. Due to this, methods aren’t limited to just arguments in and a single value out like a function out there in global namespace land.

Since we’re putting all of this data into a private data member, $objectData, not even an inherited class can get to this information directly. This is where the accessor method getValue() comes into a play. The additional advantage to this, outside of controlling how the data is passed around, is that now you can also handle what happens if a child class asks for a field that doesn’t exist.

As I said, this isn’t ready to roll yet. The code to figure out the primary index hasn’t been put into place yet. If you look at the line that assigns a value to the string $query it should be readily apparent that this is fairly important. Now this class starts to get a bit longer, as it’s time to convert that old nasty dbFields() function into a slick method worked into this class.

class DatabaseObject
{
  private $objectData = array();
  private $fieldList = array();
  private $primaryIndex = "";
  private $indexValue = 0;
  protected $dbPtr = FALSE;
  protected $databaseTable = "";

  public function __construct($id=0)
  {
    $this->dbPtr = fancyDatabaseConnector();
    $this->indexValue = intval($id);
    $this->dbFields_mysql();
    $this->pullFromDatabase()
  }

  public function getValue($field)
  {
    if ( array_key_exists($field, $this->objectData) ) {
      return $this->objectData[$field];
    } else {
      return FALSE;
    }
  }

  public function setValue($field, $value)
  {
    if ( !array_key_exists($field, $this->fieldList) ) {
      return FALSE;
    }
    $this->objectData[$field] = $value;
  }

  private function pullFromDatabase()
  {
    if ( !$this->indexValue
         OR !$this->primaryIndex
         OR !$this->databaseTable) {
      return FALSE;
    }
    $id = $this->indexValue;
    $idFld = $this->primaryIndex;
    $table = $this->table;

    $query = "SELECT * FROM ".$table." WHERE ".$idFld." = ".$id;
    $queryResource = mysql_query($query, $dbPtr);
    $this->objectData = mysql_fetch_assoc($queryResource);
  }

  private function dbFields_mysql()
  {
    // A translation array used to convert a specific MySQL data type to
    // a generic datatype used within this class.
    $dataTypes  = array("tinyint"   => "integer", "smallint" => "integer",
                        "mediumint" => "integer", "int"      => "integer",
                        "bigint"    => "integer",
                        "float"     => "float",   "decimal"  => "float",
                        "double"    => "float",
                        "varchar"   => "string",  "text"     => "string",
                        "char"      => "string",
                        "datetime"  => "date",    "date"     => "date",
                        "time"      => "date");

    // Go out and hunt down all that field information
    $query = "SHOW COLUMNS FROM ".$this->databaseTable;
    $queryResource = mysql_query($query, $this->dbPtr);

    // Run through it all and fill in the fieldList and fieldIndex vars
    while ( $row = mysql_fetch_assoc($queryResource) ) {
      $field = $row["Field"];
      $prop  = $row["Type"];
      $key   = $row["Key"];

      // Look for a value stored in parenthesis
      $sizeStart  = strpos($prop, "(") + 1;
      $sizeLength = strpos($prop, ")") - $sizeStart;

      if ($sizeStart > 1) {  // We have a parenthesis
        $type = substr($prop, 0, $sizeStart - 1);
        $size = substr($prop, $sizeStart, $sizeLength);
      } else {               // No parenthesis, so set the size to zero
        $type = $prop;
        $size = 0;
      }

      // Look for a space in the Type, as that is used to specify unsigned
      // or some other type of attribute for this field.
      if ( strpos($prop, " ") ) {
        $attrib = substr($prop, strpos($prop, " ") + 1);
      } else {
        $attrib = FALSE;
      }

      // Assign the generic data type as the type we'll be storing in the
      // returned array.
      if ( array_key_exists($type, $dataTypes) ) {
        $type = $dataTypes[$type];  // Assign a generic data type
      }

      // Assign what we've discoverd to the fieldList array
      if ($key == "PRI") {
        $this->primaryIndex = $field;
      } else {
        $this->fieldList[$field]["type"]   = $type;
        $this->fieldList[$field]["size"]   = $size;
        $this->fieldList[$field]["attrib"] = $attrib;
      }
    }
  }
}

The first thing to notice here is that there is now a new call in the constructor to the dbFields_mysql() method. All that was needed to convert this from a procedural style function was a to add a few “$this->” references to the data members, and get rid of having to declare those variables at the top of the method. There is also a new assignment for the $primaryIndex data member, which is what we’re really needing at the moment. The pullFromDatabase() method now has all the information it will need to run.

I’ve also snuck in another little method you can use to change the data within that private $objectData. The setValue() method allows an inherited class a controlled means for altering the data.

As setValue() presently exists it will work, but this method is hardly complete. At this point it at least verifies that a field exists before allowing a value to be assigned. Thing is, thanks to the dbFields_mysql method we also know what are the allowable values for each and every field. At this point I’ve excluded that error checking for the sake of keeping this sort of brief. Essentially you could work up a simple switch/case handler like in the dbUpdate() function from my earlier post.

In a language like Java where type safety is integral the JVM handles making sure that only a string can be assigned to a string, or a number to an integer. Here the setValue() method can be used to implement some type safety into your inherited classes, with the additional ability of insuring that string lengths and numeric values are all within bounds before storing them.

Putting It To Use

Let’s bring back the child class for just a moment here.

class Product extends DatabaseObject
{
  protected $databaseTable = "Products";

  public function __construct($id=0)
  {
    parent::__construct( intval($id) );
  }
}

Thanks to inheritance, this is now a fully database enabled object. When you pass in an index all the fields are filled in from the database and are ready to use. So let’s see it in action:

$product = new Product(12);

print $product->getValue("model");
print $product->getValue("description");
$product->setValue("price", 12.32);

That’s pretty much it. No SQL to write. It all just happens since the DatabaseObject class handles all of that. Just creating the object makes all of the data readily available to us. We can even change the data in a controlled way. Well, we’re still missing one part of this over all puzzle, and that’s writing changes back to the database. Again going back to my previous post about database abstraction, we have all the data sitting in an array that just happens to be in the exact format the dbUpdate() function is expecting to get in.

The correct way to do this would be to also convert that dbUpdate() function into a method for this class. At this point I would hope that I have provided enough information on doing this so I’m not going to put that code in here for you. Let’s just call it a little bit of homework.

What I will mention here is a little publicly available wrapper method to call your dbUpdate() method.

private function dbUpdate_mysql()
{
  // Converted copy of that global function mentioned earlier
}

public function commitChanges()
{
  $id = this->dbUpdate_mysql();
  return $id;
}

Now when you’re actually using that Product object you can send those updates to the database with just a simple:

$product->commitChanges();

You may be asking yourself, or at least I hope you would, why not just make dbUpdate() public and call it directly? Isn’t it sort of a wast to call one method that doesn’t do anything but call another one? Normally it would be wasteful, but in this case the cost is worth it. By running your update requests through commitChanges() you can point to any dbUpdate routine. In this case we’re using MySQL. You may need to convert your application to use some other database backend at some point due to any one of a variety of reasons. Don’t let yourself get locked in to just one kind of database call.

Perfect database abstraction is a myth. It’s the holy grail of developers to have this one perfect suite of code that is able to talk to any database with the flip of a switch. Like the grail, it is often seen just around the corner, but never actually acquired. The truth of the matter is that often enough you’ll need a feature one engine provides but another doesn’t. The only way to correct this is to be able to code directly to that engine. By abstracting which set of methods are used to do the database transactions you’ve given yourself a way to update which functions are being talked to, without having to go out and alter every line of code that needs something from the database.

The commitChanges() method could just as readily called dbupdate_postgre(), or perhaps worked in some logic to select which method to call based on the type of database used.

What’s Left For You To Do

I’ve left a lot of gaps in that object to get to this point in the post. Like my other posts, and what seems to be a recurring theme here, I’m not providing you copy and paste kind of stuff for your code. That’s what PEAR is for. Here my point is to show you what is hopefully a new and useful concept that you can take with you into your own development. With that being said, here’s a list of items you should complete in order to make this class into something that you would use in production.

1. Proper error handling for your database connection.
2. Data validation in the setValue() method.
3. Properly convert dbUpdate() into a method using data members rather than arguments.
4. Fully abstract the calls to the database to avoid engine specific calls.

It doesn’t stop there. You could work in little utility functions like date conversion to and from a database format and a unix date integer for use in the date() function. Whatever else you can dream up for moving as much of the database handling into the background so you can focus on the logic of how you use that data in the foreground.

Different Kinds Of Objects

Let’s just say that you’ve put together a reasonably complete and production ready version of this DatabaseObject. So far I’ve shown how you can use that to create a Product class that immediately has database reading and writing with all the data members in place ready to use. Certainly there are many more kinds of objects out there that a database is going to hold. Stuff like accessories, options, shopping cart data, and everything else that goes into completing a site. If you’ve created the tables in the database with all the appropriate fields, you just keep extending from that DatabaseObject class.

class Accessory extends DatabaseObject
{
  protected $databaseTable = "Accessory";

  public function __construct($id=0)
  {
    parent::__construct( intval($id) );
  }
}

class Option extends DatabaseObject
{
  protected $databaseTable = "Options";

  public function __construct($id=0)
  {
    parent::__construct( intval($id) );
  }
}

Every new class your create from DatabaseObject gets all the basic features that your Product object got.

Many Objects

So far I’ve shown what I believe to be a pretty reasonable way to deal with individual database records. This class is built around the notion of one record at a time as an object. You can pull that information in and update it one at a time. So what happens when you need to deal with 100 records at once? Like a list of those products, or showing all the accessories available for a product.

The obvious answer to this is to just create a bunch of those Product objects. It may be obvious, but not ideal.

$indexList = array(12, 32, 14, 1, 87, 23);
foreach ($indexList as $index) {
  $prodObj[] = new Product($index);
}

A quick example of creating 6 Product objects each loaded up with all the data associated with each index value. The reason this isn’t an ideal solution is that you had to make 6 seperate database calls. Imagine you needed to get a list of 100 products for 50 people all asking for them at the same time. This approach just doesn’t scale well, especially considering how many different tables are already being needed to get together something presentable. Usually the biggest bottleneck of a dynamic site is getting information out of the database. We want to be as efficient there as possible for the biggest performance gains.

This is heading us down the road to something called an “aggregate class”. Yet another big fancy phrase that means something pretty simple. It’s just a class that has objects as data members. In other words, and object that holds other objects. For what I personally do to deal with this issue is create what I call a list class. This probably has a fancier name than I’m aware of, so you can leave a comment if you know of such a thing.

In a list class I create empty DatabaseObjects then pull in a multi-row result directly from the database engine to fill them in. Notice how in the DatabaseObject class the $index argument isn’t required? In the pullFromDatabase() method I don’t try to get anything from the database unless I have an $index value. Also note that in the setValue() method I check in the $fieldList array rather than the array holding results to determine if the field is valid. These are all little hooks to allow a list class to do all the data filling.

Creating a list class is something I’ll leave for a follow up post. Before getting into reading that, consider how you would approach putting together an inheritable list class for all of these various DatabaseObjects created here. What sort of shared methods could this list employ?

When you start to think in those terms, you are developing in an Object Oriented style.

While that might seem like the end of the story, it isn’t be any means. As a project grows and starts into using elements of other projects you suddenly find yourself with a whole new naming problem. Now those classes are starting into getting those obnoxiously long names. Other OOP languages that are more established in this realm, like Java and Python, have implemented solutions to these problems long ago. It seems that PHP is finally starting to address this.

I personally didn’t think we would see PHP release this until version 6, but it looks like as of PHP 5.3.0 you can start into working with defining namespaces. To quote the PHP manual…

Namespaces are available in PHP as of PHP 5.3.0. This section is experimental and subject to changes.

To better get a handle on what this is all about comes from a post by Dmitry Stogov to the PHP Internals mailing list.

[PHP-DEV] Simple Namespace Proposal

The full thread is well worth the read since these were many of the formative arguments that have lead to what is in there today, and what will likely be where things are at when the dust settles.

As interesting as all of this is, namespaces are still not a part of the the stable PHP release just yet. It’s very likely that it will be months even after 5.3.0 hits the streets before web hosts are fully upgraded. There are also a number of unresolved issues facing the PHP developers. One such problem is noted in a post on the PHP manual concerning the namespace rules.

Sadly enough, the latest class name resolution rules render PHP namespaces quite useless.

Let’s face it, not only do us users of PHP have namespace issues, the language itself is getting out of control. I can remember back when this list would nearly fit on a single page with two columns. Everything on there exists in the global namespace. As PHP continues to grow and add functionality are we forever going to see the function list grow?

Java dealt with this problem early on by keeping the core functionality of the language to a bare minimum, then distributing libraries in the form of packages that each exist within a namespace. It may be that with the combination of a more complete object model and the need to add core functionality PHP may be forced into that type of model. If a packages style model is in the works, it’s most likely out there on the fringes of a PHP7 wish list that I haven’t seen yet.

My first immediate concern as I got looking into this was how autoloading would be impacted. I use autoloading for all my class imports, so this is near and dear to my heart. Searching about I found the following post discussing this. The interesting stuff is in the follow up replies, so be sure to check out the full thread. It’s only a couple of messages.

[PHP-DEV] PHP 5.3 Autoload+Namespaces+Functions incorrect (atleast weird) behavior.

I then ran across a blog entry by David Coallier discussing namespaces and their usage. Within the comments he addresses autoloading. Many of the other comments express a pretty negative set of opinions about what Dmitry has worked up here.

Autoloading comment on David Coallier’s blog

Whatever the final direction of this goes, it’s important to keep in mind that PHP started as a fairly simple procedural scripting language. What we’re seeing now are the growing pains associated with becoming a platform that can readily handle much larger projects than would be practical today. Look for all of this goodness to be hitting mirrors near you very soon.

“If eval() is the answer, you’re almost certainly asking the wrong question.”

Not sure who originally said this, but it is surely sage advice. You can see this in context here if you’re so inclined.

If you’ve been doing this PHP thing for more than a project or two you have certainly noticed the mess that is the database functions. An entire stack of functions for MySQL, Microsoft SQL, ODBC, PostgreSQL, etc. Sure, PHP is rich in interfaces to a wide variety of database platforms, but trying to change which platform your using can be a little nightmare. Were you supposed to run mysql_query() or pg_query()? Like many of you, I put together a little set of abstraction tools that we’re pretty much a set of functions that added a layer between the code that needed the data and the database itself. Now that PDO is on the scene it would seem that these kinds of custom libraries are no longer needed.

There is still a place for creating your own libraries though. Implementing tools that push the SQL into the background and allow you to focus on your logic and presentation. In this article I will share some methods I use to abstract UPDATES and INSERTS.

Not So Friendly SQL

Most of the web projects I work on require a lot of data lookups from a database. This really hits home with the publicly viewable pages where data lookups are critical to performance. On the other hand, the data needs to get in there somehow in the first place. The need for content management screens has always been a part of any dynamic web site.

As a developer I really used to hate dealing with forms. Those darn things are just filled with bugs the moment you start in to them. A few of the pitfalls in dealing with them…

1. Setting the max length on input fields
2. Checkboxes that don’t pass anything along if not checked
3. Basic validation
4. Filling in values for editing
5. Does the database need to UPDATE or INSERT

This list could go on for a while. I used to deal with these things manually, and without exception I always ran into issues with the UPDATE and INSERT actions. I’d quote an integer, or forget to quote a string, or some other typo would stop the process. I think I have spent more time debugging forms than any other kind of code. Then when you consider what a nasty set of security glitches can happen when a user gets to enter data into your code… yuck!

It Was Always Right There

So one day I got to looking at the database tables that I was using on a project. It sort of just hit me that almost everything I needed to know about my forms was just sitting there in the database. I created those tables to reflect the kind of data I would need to display, and the forms to get that data in there. Every field in the table had a clue as to what I was going to do with that data.

It was one of those huge, “well duh!” moments. Something so obvious that I’ve been overlooking it for far too long. So how do I put this to use?

I can tell you right now that this approach isn’t a catch all for every kind of data updating. If your site is getting hammered with updates and inserts you most likely don’t want any kind of abstraction going on. You certainly don’t want to waste time looking in the database to see what data needs to go in. You’ll want to have hard coded what fields are getting data. To make what I’m about to discuss work you need to run an additional query on the database to figure out what goes where, then you can follow that up with putting data in.

For the bulk of the work I do I’m usually not that concerned with squeezing the last performance drop out of putting data into the database. Usually there are only a handful of people who are authorized to enter data, so I’m not looking at a bottleneck for most data writing. A small performance hit is acceptable here for some big integrity and simplification gains.

What You Know About Your Data

I mostly work with MySQL for my web site needs. Despite some very good arguments against using them, I almost always have an auto incrementing field acting as my primary index. Again, this is not for a site getting hammered with updates. The only type of table I wouldn’t have a primary index for would one that I flush the entire table out before importing new data. A feed from another site or alternate data source for example. It’s safe to say that every other table in use will have that primary index field in there.

I also know that if my updating routine is not passed a value for this primary index, then I’m looking at performing an INSERT. When an index is passed along I know an UPDATE is needed, since I wouldn’t have had that index value unless a record already existed. Pretty basic stuff.

Every other field in a table is going to be of some “type”. This could be a varchar, integer, or any other valid MySQL field type. From the stand point of figuring out how to dynamically put together the SQL from PHP I don’t need to get that specific. I do need to know some basics though.

• I need to know if the type should be expecting a string or not, since I need to know if quotes around the value are needed.
• If a string is of a particular size, like a varchar(120), then I’ll want to make sure I don’t try to put more than the value needed.
• Integer and float types better not be getting letters stuffed in there.
• A float can have a decimal, an integer can’t.
• All strings should be run through the appropriate escape routines so invalid characters don’t muck up the SQL.
• Dates and times need a bit of special handling to make sure they’re in the correct format.
• Which field is the primary key.

From that criteria I determined that what I needed was 4 basic field types that my code could utilize, rather than trying to have a special case for every kind of MySQL type. Also, this allows for abstracting to other databases that have an even larger variety of field types. The types in question are:

1. string
2. integer
3. float
4. date

To handle the conversion between the MySQL field type and the one that I will be using I just put together an associative array to handle this.

$dataTypes = array("tinyint"   => "integer", "smallint" => "integer",
                   "mediumint" => "integer", "int"      => "integer",
                   "bigint"    => "integer",
                   "float"     => "float",   "decimal"  => "float",
                   "double"    => "float",
                   "varchar"   => "string",  "text"     => "string",
                   "char"      => "string",
                   "datetime"  => "date",    "date"     => "date",
                   "time"      => "date");

I realize there are more field types then this, but these are the ones I personally utilize most often. Besides, I’m not going to do ALL the work for you. What fun would that be?

Looking Up What To Look Up

So this article doesn’t turn into a full blown book here I’m going to focus in on how to do this with those old style MySQL functions. I’m also going to put this together with a set of functions, though this really works better within the framework of an object. You’re going to want to tweak this to your needs, and there’s certainly more work than just throwing PDO at it to fully abstract multiple databases.

I’m going to assume that you’ve already established a connection to your database and have a resource pointer for it. I’ll call it $dbPtr here. This also assumes you have a table with a primary index and some fields of various types. We’ll just call this “InfoTable”.

With all the disclaimers out of the way, let’s get that field information from the table, which we’ll be using later. To do this I’m going to run a query out to the database asking for all the columns, or fields, from the specified table. This is probably the fastest way to get everything we need out of there since we’re only making one request to the database server. I will then examine each field as it comes out to determine which of my four basic field types each one of these fits into.

When field types come out of MySQL they may contain an attribute, like “varchar(120)”. From the perspective of what I’m trying to do here these are two valuable pieces of information, so I need extract that number as the “size” of the field and get “varchar” by itself so I just have the type. Once the type is known, I then look it up in my $dataTypes array for my more generic type.

function dbFields_mysql($table)
{
  global $dbPtr;
  $fieldList  = array();
  $fieldIndex = "";
  $dataTypes  = array("tinyint"   => "integer", "smallint" => "integer",
                      "mediumint" => "integer", "int"      => "integer",
                      "bigint"    => "integer",
                      "float"     => "float",   "decimal"  => "float",
                      "double"    => "float",
                      "varchar"   => "string",  "text"     => "string",
                      "char"      => "string",
                      "datetime"  => "date",    "date"     => "date",
                      "time"      => "date");

  // Go out and hunt down all that field information
  $query = "SHOW COLUMNS FROM $table";
  $queryResource = mysql_query($query, $dbPtr);

  // Run through it all and fill in the fieldList and fieldIndex vars
  while ( $row = mysql_fetch_assoc($queryResource) ) {
    $field = $row["Field"];
    $prop  = $row["Type"];
    $key   = $row["Key"];

    // Look for a value stored in parenthesis
    $sizeStart  = strpos($prop, "(") + 1;
    $sizeLength = strpos($prop, ")") - $sizeStart;

    if ($sizeStart > 1) {  // We have a parenthesis
      $type = substr($prop, 0, $sizeStart - 1);
      $size = substr($prop, $sizeStart, $sizeLength);
    } else {               // No parenthesis, so set the size to zero
      $type = $prop;
      $size = 0;
    }

    // Look for a space in the Type, as that is used to specify unsigned
    // or some other type of attribute for this field.
    if ( strpos($prop, " ") ) {
      $attrib = substr($prop, strpos($prop, " ") + 1);
    } else {
      $attrib = FALSE;
    }

    // Assign the generic data type as the type we'll be storing in the
    // returned array.
    if ( array_key_exists($type, $dataTypes) ) {
      $type = $dataTypes[$type];  // Assign a generic data type
    }

    // Assign what we've discoverd to the fieldList array
    $fieldList[$field]["type"]   = $type;
    $fieldList[$field]["size"]   = $size;
    $fieldList[$field]["attrib"] = $attrib;

    // Note if this is the primary key or not
    if ($key == "PRI") {
      $fieldList[$field]["key"]  = TRUE;
    } else {
      $fieldList[$field]["key"]  = FALSE;
    }
  }

  // Send it all back to the caller
  return $fieldList;
}

Using What The Database Told Us

Thanks to that dbFields_mysql() function we now know what is allowed to go into the database. We know the type, the size, and the attribute of each field. We even know which field is the primary index.

Although this post is about simplifying the construction of INSERT and UPDATE operations, you should also consider what else you can do with this. You could put together routines that know exactly what the maximum length of an input field should be on a form. Upon submitting you can use this information to validate that numbers are where they need to be, and strings where they need to be. All of this is now dynamically figured out, greatly reducing the amount of code needed to run basic validation. This may be a fine subject for a new article, but for now let’s get back to slapping some data into the database.

Normally you would take all the information coming in from a form submission and go about constructing your SQL with that. New records would get all the INSERT syntax, where existing records get all that UPDATE syntax. Of course, neither of these two look anything like the other. You would either create 2 sections of code to handle each, or perhaps utilize the INSERT ON DUPLICATE KEY UPDATE utility. When I’m trying to get data stored I just don’t want to deal with the hassle of the syntax intricacies involved with any of this. I’ve got this data that needs to go in these fields, just do it already!

What if we could just match up the data to the fields, then let some other bit of code deal with putting together the SQL. How about a nice dbUpdate() function? We’d have to tell it what table we want to update, as well as the data itself. Also need to give it the value of our primary index when we’re doing an edit. Okay, I can deal with that:

$tableData = array("name"    => $name,
                   "address" => $address,
                   "state"   => $state,
                   "zip"     => $zip,
                   "salary"  => $salary,
                   "friend"  => $friend);
$indexValue = 3;
$tableName = "InfoTable";
 // All the data is together, so update the database
$returnIndex = dbUpdate($tableName, $tableData, $indexValue);

This is pretty much all the code you’d need to update this person in our make believe table. No need to check for strings being properly escaped, or whether quotes are needed. Even check boxes are dealt with properly. Leave out the $indexValue, or set it to zero, and it runs an INSERT automatically. It’s also far easier to read than the SQL you would normally use, thus making typos a little less likely. Even a typo won’t stop this from working, as we know what fields are allowed. We can weed out fields that don’t really exist.

Constructing The SQL

Now that you’ve seen what an INSERT or UPDATE would look like using this dbUpdate() routine, let’s get into actually coding some of this up. Be warned up front, I have not thrown in all of the data validation that can be done here. My intention is to show the technique, not put together a ready to use package.

function dbUpdate($table, $fldValArray, $indexValue=0)
{
  global $dbPtr;
  $q = "";
  $indexValue = intval($indexValue); // Make sure this is an integer

  // Make sure we've at least got the minimum stuff to run this
  if (strlen($table) < 2 or count($fldValArray) == 0) {
    return FALSE;
  }

  $fieldList = dbFields_mysql($table); // Load up all the stuff we need to know
                                       // about the fields in this table.

  if (count($fieldList) < 1) {  // doesn't look like we have a field list
    return FALSE;
  }

  if ($indexValue != 0) {  // Do we need to know which is the primary key?
    // Yes we do.  Find it!
    $primaryKey = "";
    foreach ($fieldList as $field => $value) {
      if ($fieldList[$field]["key"]) {
        $primaryKey = $key;
      }
    }
    if ( !$primaryKey ) { // An index value, but no primary key... ERROR!
      return FALSE;
    }
  }

  if ($indexValue > 0) {  // With an index value we need to UPDATE the table

    $q  = "UPDATE $table\n";
    $q .= "SET\n";

    foreach ($fldValArray as $field => $value) {

      if ( array_key_exists($field, $fieldList) ) { // Only run for valid fields

        switch ( $fieldList[$field][$type] ) { // Prepare the value based on the type of field

          case "string":
            $value = strval($value);
            $value = trim($value);
            if ( $fieldList[$field]["size"] > 0 ) {  // Chop it down to size
              $value = substr($value, 0, $fieldList[$field]["size"]);
            }
            // Make sure we've got a clean input
            $value = mysql_real_escape_string($value, $dbPtr);
            $q .= "$field = \"$value\",\n";
          break;

          case "date":
            $value = strval($value);
            $value = trim($value);
            $q .= "$field = \"$value\",\n";
          break;

          case "integer":
            $value = intval($value);
            $q .= "$field = $value,\n";
          break;

          case "float":
            $value = floatval($value);
            $q .= "$field = $value,\n";
          break;

          default:
            $q .= "$field = \"$value\",\n";
        }
      }
    }
    $q = substr($q, 0, -2); // Strip the last comma and line feed off
    $q .= "\nWHERE ".$primaryKey." = ".$indexValue;

    $qr = mysql_query($q, $dbPtr); // Run the update

  } else { // No id passed, so put together an INSERT

    $fldStr = "(";  // Begin the field section of the INSERT
    $valStr = "(";  // Begin the values section

    foreach ($fldValArray as $field => $value) {

      if ( array_key_exists($field, $fieldList) ) { // Only run for valid fields

        $fldStr .= $field.", ";

        switch ( $fieldList[$field][$type] ) {

          case "string":
            $value = strval($value);
            $value = trim($value);
            if ( $fieldList[$field]["size"] > 0 ) {
              $value = substr($value, 0, $fieldList[$field]["size"]);
            }
            $value = mysql_real_escape_string($value, $dbPtr);
            $valStr .= "\"$value\", ";
          break;

          case "date":
            $value = strval($value);
            $value = trim($value);
            $valStr .= "\"$value\", ";
          break;

          case "integer":
            $value = intval($value);
            $valStr .= "$value, ";
          break;

          case "float":
            $value = floatval($value);
            $valStr .= "$value, ";
          break;

          default:
            $valStr .= "$value, ";
        }
      }
    }
    $fldStr = substr($fldStr, 0, -2).")"; // Strip comma and add a closing ")"
    $valStr = substr($valStr, 0, -2).")"; // Strip comma and add a closing ")"

    $q  = "INSERT INTO $table\n";
    $q .= $fldStr."\nVALUES\n".$valStr;

    $qr = mysql_query($q, $dbPtr);   // Run the INSERT
    $indexValue = mysql_insert_id(); // Pull in the primary key ID
  }

  return $indexValue;
}

So let’s walk this through step by step.

The indexValue defaults to 0 so that can be an optional argument. I then make sure that this is an integer no matter what.

So things don’t totally go awry I check that a table and some data has been passed on in here.

I then populate my fieldList array with the dbFields_mysql() function shown earlier. That fieldList array has everything I need to know about getting this SQL together. I then make sure something is loaded in that array before I let this go any further. There may be a typo with the table name.

I only need to know which field is the primay key if I’m going to update this record, which means I only need to hunt it down if indexValue has a value. If it does, I then store the name of this field as $primaryKey.

The next big section is broken into two segments depending on whether an index value exists. The first section puts together and updates the database. The second does almost the same thing for an insert. Both sections utilize a switch/case setup to determine what kind of clean up and formatting is needed for each field. If the field this function has been asked to update doesn’t exist, it doesn’t add it to the SQL.

Whether an UPDATE or an INSERT take place you always get back the value for the primary index.

What Is Missing

This isn’t exactly the code I use in production since I have further abstraction going on within a class usually. I didn’t want to get into the full framework I use right here, so I presented a procedural approach to this. Utilizing an object oriented approach allows me to store the field list and primary index as member data, so I normally don’t have to dig that kind of stuff out.

The worst bug in this version is that it doesn’t take into account what to do if none of the fields being requested to update exist. If you do run into a situation like this I would recommend that you stop trying to type with your elbows and start working with your fingers. Seriously though, a solid function should anticipate this and deal with it.

You could also work in much tighter controls on numeric and date fields to further validate what is going in to make sure the values are not jumping out of bounds and are in the correct format. I left that out of there in this example to keep things brief.

Does It Work?

Since putting this together into a class I’ve found that I rarely have to write INSERT or UPDATE syntax. I’ve also spent very little time having to debug why an update to the database has failed. These functions are tightly aligned to how I put together my database tables which stay pretty consistent between projects, so it’s worked out very nicely for me. Yes, there is a slight performance cost, as I have already discussed, but not one that’s noticeable under a light updating load.

To apply this to other database engines you will want to do more than just use a simple abstraction layer like PDO. Each one has different field types and ways in which to extract the field information from them. Still, there’s no reason why you couldn’t duplicate this effort for another engine with a simple wrapper function to decide which bit of code needs to run for which engine. Once you have established a call to user defined functions as your means to talk to your database, you won’t have to go revisit that code again.

Summary

I hope I’ve provided to you a different way of approaching getting data into your database. By creating functions or methods for handling this task I believe you will simplify your code, provide for better data integrity, and generally make the world a more wonderful place.

I think I may now understand why this was. Most of the efforts I’ve seen to describe object oriented design are coming from the perspective of someone who thinks in an OO way. I’m not saying this was a bad approach, it just really didn’t work for me. Perhaps if I hadn’t been so deeply entrenched in the methodologies I had been using for years I would have been more receptive to this type of presentation.

I don’t have any better arguments here for designing in an OO way, but I believe this article approaches the topic from an angle that might make things a bit clearer for people like me. Programmers who have been putting together working sites in a procedural manner and can’t seem to make the mental hurdle into OO.

Mind you, if we were still talking about PHP4 avoiding OO would have been a good thing. It really was a hack job slapping on only some of the most basic functionality for objects. It was bad enough that many of the ways you would have done things in version 4 are now, thankfully, obsolete. PHP5 has finally started making it real.

The issue with learning how to deal with objects isn’t in the syntax or the mechanics. I can promise you, once you get a handle on the concept of OO design the mechanics darn near write themselves. Much of it is just a matter of rethinking much of what you already know. Perhaps learning a few new terms along the way.

The real key to your understanding of Object Oriented programming is purely in getting the concept of it. This article intends to focus on concept rather than functioning code. I will be leaving a bunch of details out that I believe will hinder your grasping of the concepts. Many of these are better handled by some of the books I’ve referenced at the end of the article or the PHP manual online.

I will begin by taking you through some of the problems you may have already experienced with a purely procedural approach to your design. One by one I hope to address how what appear to be problems in procedural land are actually features of designing in an Object Oriented way.

Development Stages of a Developer

Looking back on it now I went through a set of stages in my thinking and development habits as the projects I worked on got larger. It is not, as many people might lead you to believe, because an OO design strategy is only useful on a large project. It is due to the fact that many of the pitfalls of writing purely procedural code don’t really become readily apparent until you are dealing with a larger set of code. They become screamingly obvious once you start working on the next project needing similar code as the one before.

If you’ve been working with PHP for a while you may recognize some of these stages. I know I went through each and every one of them, and I know others who have done much of the same.

Stage 1

You’ve got your script talking to a database. You’ve got forms collecting data, and clever SQL and loops producing that data into something presentable. Your PHP code and HTML are coexisting in harmony on all of these wonderful dynamic pages. There is much rejoicing.

Stage 2

The harmony that had existed has started to vanish. The data and the pages they are producing are becoming more complex. Worse still, trying to work out what code is doing a few months after you wrote it has become more of a headache than writing new code. It’s time to move as much of the logic as possible into functions.

Stage 3

Moving the logic into functions has proven to be a beautiful thing. You’ve started to create libraries of these functions which you include when you need them. You may have a set of core functions that you use on multiple projects, site specific items, perhaps some database handling routines. New features mean new functions that grow into new libraries of them. It’s all under control.

Stage 4

The functions are working still, but not all is well in paradise. With all of these functions about you have started giving them wonderfully descriptive names like “PullProductInfoFromDatabaseInHTML()”. It’s starting to get a little nutty so you don’t run into naming conflicts with functions written long ago.

With all of these functions in various files you’ve been including it’s also getting harder to track down which file has a specific function. While looking for a lost function you also find that you’re running across long forgotten functions you’re no longer sure are even still being used.

Things have started to get a little painful, but you’ve got it under control. Just a little filing issue really. Just need to start writing a little documentation for all of those functions. Documentation that, even as you write it, you know doesn’t stand a prayer of staying up to date.

Stage 5

You start up a new project that is similar to a previous one, so you want to use those function libraries over again. Problem is, too many of those functions were tied so closely to the previous project that you end up having to edit those functions in place. Not a bad deal initially, except that now you have two sets of the very same functions with minor tweaks between them. Enough minor tweaks, and you can’t use those libraries over again.

Now you not only have the problem of figuring out what function is in which file, but now you also need to identify which group of files has the up to date versions that you’ve got all optimized and working better than the earlier versions.

Stage 6

What had started out so elegant in it’s simplicity has turned into a mess of complexity. Everything is in the global namespace, so you’re spending as much time trying to name new functions and variables as you are actually programming. Your once good friends, “Copy&Paste”, have actually made your life more, not less, complicated.

The Problem with Functions: Part I – Context

If you will, journey back with me a bit to Stage 4 mentioned previously. Consider for a moment just what you are doing when you give your functions really long descriptive names. What broke down from when you could just write something like productInfo(), or even info()?

This gets into the first problem that needs to be addressed with functions, and that is context. You are trying to put some action into the context of what it is acting upon. By their very nature a function exists without a context of it’s own, so a fully procedural program has to work around this by getting clever with how functions are named. This can get real ugly real fast when you have multiple kinds of data that could really use a getName() procedure.

Jumping a bit further into metaphor land, you can think of a function as a verb without a noun. It’s purely an action statement. Like saying “run”, but not saying what is running.

One reasonably simple way to deal with this is to create a “class” that contains a set of your procedural functions. This is not an Object Oriented approach just yet, but it is a valuable building block.

Old function calls

function pullProductInfoFromDatabaseInHTML()
{
  // Pretend to run query and return a result
  return "Acme 123 Motorized Widget";
}

Doing the exact same thing with a static class.

class Product
{
  public static function pullFromDatabaseInHTML()
  {
    // Pretend to run query and return a result
    return "Acme 123 Motorized Widget";
  }
}

To run the old function you would just call it’s name and look for a result.

$productInfo = pullProductInfoFromDatabaseInHTML();

With our fancy new class you would instead say…

$productInfo = Product::pullFromDatabaseInHTML();

These two approaches do the exact same thing. The difference here is now we can group all of the functions dealing with a “Product” inside of this class. Now you can have numerous functions called pullFromDatabaseInHTML() for whatever kind of grouping of data that you wish with much less chance of a naming conflict.

With this alone, you could stick with the procedural style you’ve been doing and start to seriously simplify your naming schemes. Better still, you could pass the entire contents of this class to an entirely different project with a drastically reduced chance of a naming conflict. Better still, you can now import little libraries of these functions from other developers right into your code without conflict. Feeling all organized yet?

We haven’t got into anything involving objects or OO design as of yet. All we’ve done is provided a way to group a bunch of functions together. That is what a “static class” is all about. We’ll be doing quite a bit with classes here shortly. At this point just take this little tid bit with you before leaving this section.

• A class that has all of its functions defined as static is a “static class”.

Now who could possibly argue with that?

The Problem with Functions: Part II – State

Let’s just pretend that you’ve put together a wonderful little library of functions into a class. The problem now is that each and every function has to call out to the database to get some of it’s information, every time. For example, if you wanted to have a dedicated function for getting a product’s name and one for the description, each one has to do their own lookup or come up with some means of sharing that information with the other functions.

There are 3 basic ways to get information into a function.

1. Pass an argument in the call.
2. Define a variable as global.
3. Use a defined constant.

To start with, is there anything more obnoxious than a function with a large number of arguments? I know I love trying to track down a function to figure out what order things went in. Worse still, trying to work out what values were supposed to go in there. It’s all I can do to try and remember if the haystack or needle comes first in strpos(). Let’s just say at this point that one of my new goals here is to limit the number of arguments that need to go into a function call.

You could dance around this problem by using lots of “global” statements in the functions, but then we’re back to the same old naming problems we ran into before we put things into a class. Yet another goal here is not just to have something that works, but to keep that global namespace as clean as can be. From this point forward we can just think of the “global” keyword as the work of the devil. It is an easy temptation that initially sounds good, but can only end poorly.

Defined constants can be used at any level of code. They can be really good stuff for setting up preferences and the like. Of course they’re not much good for the problem we’re running into here. They’re constants! You can’t change their value.

Getting information in or out of a function is quite limited. Oh sure you can toss an arrays around, but in doing so the caller has to know what the arrays will contain. More complexities! What you really want to be able to do is keep your functions small, easy to call to, and easy to understand what will come back out. To do that one thing it needs to do really well. Your also trying to hide the complexity of what is going on behind the curtain so you can focus on the larger picture of your project.

What you need is some reasonable way for related functions to share information with each other in some reasonable way. How do you do that? How would you try to solve this problem?

I believe it was this question that lead to the notion of creating an object in the first place. You’ve got this grouping of functions that not only need to remember stuff, but share that stuff amongst each other within that group of functions.

• An object is a library of functions that can remember and share stuff.

Okay, What Was That Again?

My little definition of an object is worth repeating, but let’s instead repeat it using the proper terminology.

• An object is a library of “methods” that can remember stuff.

When you stuff a function into a class it gets called a “method”. It acts in almost every way like a function. You stuff data into it with arguments, and you can get a single return value from it. It is a little different as you will see shortly.

To make matters even more confusing, in PHP you declare a “method” by calling it a “function”! This has got to be worse than clicking on Start to shut your computer down. I believe this has to do with legacy reasons more than anything else, as you certainly don’t see the keyword “function” used in a language like Java.

If calling a “function” a “method” wasn’t bad enough, now variables get a new name too. A variable that is declared within a class, but outside of a method, is called a “member”. It’s still a variable like you’d use outside the notion of a class. Saying something like $x=”Howdy” still means that $x is a string. Do that outside of a class and it’s just a string variable. Inside a class it’s referred to as a “member”, “data member”, or “instance variable”.

So why in the world do we have to rename perfectly good things like functions and variables when they’re put into a class? Remember, we’re trying to put together a group of methods that can use and share information within that group. That concept doesn’t really exist for functions hanging out in the global namespace.

To appreciate this difference let’s step back a bit and review some basics about what you know about a function.

function adder($x, $y)
{
  $z = $x + $y;
  return $z;
}

In this little adder() function we have 3 variables, all of which only exist while the function is running. In other words, the contents of this function exist within a little world of their own. The function can’t see anything outside the scope of it’s enclosing brackets. Data goes in, data comes out, but anything about what happened in between is lost once the function has completed.

We need to get together a class that not only has some methods, but also some members. You can think of this as the blueprint of creating an actual object. Hang on to that mouse, it’s about to get a little bumpy here.

A Class Is Not an Object

The first class example I showed you had a “static method”, which essentially means you can just call that method directly with what them PHP folks call a “Scope Resolution Operator”, which is a really big fancy term for a pair of colons “::”.

We could just take everything in our Product class and make it static. What if we had to have two or more of those products at the same time? Consider a product catalog that needs to show lots of products on the same page. Wouldn’t it be cool to have a bunch of objects that could be created using the same class?

Turns out, this is exactly how it works! You use a class to define what an object should do and remember, then you create an object from that. I better slap some code here before I metaphor again.

A Product class that’s ready to be turned into an object:

class Product
{
  public $model = “”;
  public $description = “”;

  public function pullFromDatabase($index)
  {
    // Fancy database query would run here
    $this->$model       = $dataRow[“model”];
    $this->$description = $dataRow[“description”];
  }
}

So now what in the heck can we do with that? How about we finally go and make us an object with this thing already. Gather the family around, this part is really exciting.

$p = new Product();

Pretty cool huh? Okay, so you’ve got the kids and your aunt walking away in disgust at how dull that was. I guess they just can’t appreciate just how cool this really is. You have just made a bona fide object! So what can you do with this thing you just did? Well, you could run that method that is now a part of this object. How about let’s go and get a product record from the database with an index value of 12.

$p->pullFromDatabase(12);

Another big fat yawn you say? Well, now we have some values in those members. Here, let’s use them to show a model and description.

print $p->model.” “.$p->description.”\n”;

There’s some might funky looking syntax there with all that “->” stuff going on. This is PHP’s way of stating what context you mean. You created an object from the Product class and called it $p. Now to use that in your code you need to show that you mean the method or member from that object. Without saying “$p->” PHP is going to think you’re referring to the global namespace. Just saying “pullFromDatabase(12);” tells PHP go look for that as a function, not a method for an object.

I promised you a solution for when you needed more than one product didn’t I? You could just run that same database pull method, but then we just lost what that $p object knows. How about we instead just create a new Product object.

$p1 = new Product();
$p1->pullFromDatabase(15);
print $p1->model.” “.$p1->description.”\n”;

Now there’s 2 objects, $p and $p1, with different stuff they know. You could even put those objects into an array. Something I will illustrate after I explain a couple of goodies I tossed in that you may be wondering about if you’ve been watching closely.

Which This Is $this

Hopefully you’re wondering what those “$this->” is about. Before I can tell you that you’ll need some terminology thrown at you.

• The keyword “new” creates a new “instance” of an object.

So what does that mean? Well, you created two objects from that Product class. Each one is considered an instance of that object. Each instance can all do the same things, but they all know different things. Lose you yet?

Our first object instance was $p. That instance has the model and description of that product. In other words, it knows something about that specific product we asked for. $p1 was another instance that also knows a model and description, but a different one than $p.

Even though each instance knows something different, they both have the same action, pullFromDatabase(). Two instances, two sets of data that they know, but one set of actions.

So how does “$this->” fit in? Outside the class we need to specify our created object before requesting something, like $p->model. Inside of the class when a method refers to one of the members it has to specifically state that it is a member of, and here it comes, “this” instance of the object.

If you had instead had a method that looked like the following you wouldn’t have gotten the result you expected.

public function pullFromDatabase($index)
{
  // Fancy database query would run here
  $model       = $dataRow[“model”];
  $description = $dataRow[“description”];
}

Methods are quite a bit like functions, in that variables declared within a method only exist within the scope of that method. PHP needs some way to have you tell it what you really mean is the member variable model, not a local one.

Just Do It

It seems kind of silly to have to create this new object, then tell it to pull some information out of the database. It would be nice to instead have it just do that when you create your new instance of the Product class. A perfect lead in to what PHP refers to as “Magic Methods”.

The PHP site doesn’t do a very good job at defining a Magic Method, so I’ll do what I can here for you.

• A “Magic Method” is a method that runs due to some action taken on an object.

A Magic Method isn’t meant to be called directly. They happen when some kind of event is detected. These are methods that are already defined by PHP, so you don’t get to make new ones yourself. Our first of these methods happen when an object instance is constructed. Your just going to love the name of this… it’s called the “constructor”. All of these fancy methods start with two underscores, so as to avoid possible naming conflicts and perhaps to look a bit like Python. Anyone’s guess.

Let’s get a constructor slapped into our Product class already.

class Product
{
  public $model = “”;
  public $description = “”;

  public function __construct($index)
  {
    $this->pullFromDatabase($index)
  }

  private function pullFromDatabase($index)
  {
    // Fancy database query would run here
    $this->$model       = $dataRow[“model”];
    $this->$description = $dataRow[“description”];
  }
}

You now must pass an index value argument into the class when you construct a new instance object of this class. That’s a lot of syllables for saying you get to pass an argument on in when you create a new object. Here’s what that looks like.

$p = new Product(12);

There are two new little concepts I sneaked in here on you. First, notice how I needed to use that darn “$this->” operator to call the pullFromDatabase() method? Because it isn’t a static method, it belongs to the instance of this object. Trying to call it without “$this->” and you’ll get yourself a lovely little error message that the function can’t be found in the global namespace.

The second thing to notice is that I changed the first keyword on the pullFromDatabase from “public” to “private”. Why in the world did I do that? What does that mean?

Locking Things Down

Up until this point, everything I had in that class was public, meaning that anywhere this object existed a request to run that method could happen. From way out in the global namespace I could ask for that method to run. I’ve decided that I didn’t want just any old code to call my database routine, only my constructor. By marking that method “private” I’m saying only methods within this specific class can even see it, much less run it. An attempt to run it from anywhere else will kick off an error.

So why are we keeping secrets from other parts of our code? Aren’t we all friends here? What, you don’t trust me? Ah geesh, hurt my feelers why don’t ya.

In my mind there are a couple reasonable answers to the question of why you can and should lock down who is allowed to access a method.

1. Classes are supposed to exist to simplify your life. A year after you’ve written your perfectly written class you aren’t going to want to dig through every method. You’re only going to want to know about the methods that you need to use that class. The public ones.
2. You may have an order in which different methods need to run that may not be entirely obvious from outside code. By marking those as private your public classes can insure things are run properly. This impacts the integrity of your program.
3. Some information that you use within a class may not be any other code’s business. For example, only your database connection class ever need know anything about a database password. Only your billing code ever need any kind of access to a credit card number. You can make things a bit more secure by locking down what parts of your program can be seen.

Taking the next logical step here, let’s also lock down those members, or “instance variables”.

class Product
{
  private $model = “”;
  private $description = “”;

  public function __construct($index)
  {
    $this->pullFromDatabase($index)
  }

  private function pullFromDatabase($index)
  {
    // Fancy database query would run here
    $this->$model       = $dataRow[“model”];
    $this->$description = $dataRow[“description”];
  }
}

Oh great, now that only methods within this class can even look at those members how do we get them out of there? We slap together a couple of “accessor” methods to provide those to us.

class Product
{
  private $model = “”;
  private $description = “”;

  public function __construct($index)
  {
    $this->pullFromDatabase($index);
  }

  public function getModel()
  {
    return $this->model;
  }

  public function getDescription()
  {
    return $this->description;
  }

  private function pullFromDatabase($index)
  {
    // Fancy database query would run here
    $this->$model       = $dataRow[“model”];
    $this->$description = $dataRow[“description”];
  }
}

Now we’re starting to see a class that looks something like you would see in the real world. Data members that are private, but accessible via public methods. This is a form of “encapsulation”. We’re now in full control of how members are accessed or changed. In this case, only the pullFromDatabase() method is allowed to change the model and description.

So let’s jump back out into the global namespace realm again and put this to use.

$p[0] = new Product(12);
$p[1] = new Product(13);
$p[2] = new Product(14);

foreach ($p as $productObj) {
  print $productObj->getModel().” “.$productObj->getDescription.”\n”;
}

Oh sure that works, but it’s kind of ugly. All those “->” things really muck things up. There is a prettier way of doing this, and it works in my 2nd favorite Magic Method, “__toString()”. Let’s toss that into our rapidly growing class to see what it does.

class Product
{
  private $model = “”;
  private $description = “”;

  public function __construct($index)
  {
    $this->pullFromDatabase($index);
  }

  public function __toString()
  {
    return $this->getModel().” “.$this->getDescription().”\n”;
  }

  public function getModel()
  {
    return $this->model;
  }

  public function getDescription()
  {
    return $this->description;
  }

  private function pullFromDatabase($index)
  {
    // Fancy database query would run here
    $this->$model       = $dataRow[“model”];
    $this->$description = $dataRow[“description”];
  }
}

With our new Magic Method in place let’s see what our code would look like back from where we want to call this from.

$p[0] = new Product(12);
$p[1] = new Product(13);
$p[2] = new Product(14);

foreach ($p as $productObj) {
  print $productObj;
}

Ooooo, pretty! Creating our objects and assigning them to an array let us put together a quick list of those Products ready to foreach through them. All that yucky “$objName->methodCall()” stuff I now have tucked away into a Magic Method that is magically called when I print the object. You just gotta love that, if only a little.

Take a Breather

Let’s just stop right here and say that’s all there is to the story. If this were all there was to it and you wanted to put what we’ve discussed up to this point to use. What good is it?

To start with, we’ve got this wonderful mechanism for both grouping our methods within this fancy wrapper called a “class”. That alone pulls a ton of muck out of the global namespace. Not only have we organized functions that would have all been in the global space, but now those functions can actually remember stuff. We’ve got magical methods that get the ball rolling when you create an object, and put it all together when you need some output.

No matter how many different strings, integers, arrays, or functions you need to handle everything to do with products, none of them muck up your global namespace. This should also make it easier to name things, since the context is provided for by the class. Life is good.

And it gets better, because what I’ve shown you up to this point would allow you to make use of most of those fancy libraries in the PEAR repository. Most everything in PEAR is made up of either object oriented classes or static classes. You would either create an object from them or call to them directly with that “::” notation. Even if you never write anything that goes into a class yourself, you can still use code that has been.

If all that wasn’t cool enough, by knowing how to access objects you also open yourself up to the highly dynamic world of SOAP, Simple Object Access Protocol. SOAP is an impossibly cool technology that’s changing the face of development. I don’t want to get into this too much in this article, but here’s a bird’s eye view of it.

Imagine you wrote a really swell class with a stack of very useful methods. You’d like to integrate that with a project running on a different machine, be it across the LAN or WAN. Although it’s a really swell class you’ve got, it’s pretty heavy on CPU usage and requires access to a database that is not available across the network. You can’t just copy the code on over to your other project, since the resources on that machine are already taxed. Wouldn’t it be cool if you could just share that class out to that other project and have it act just like a locally installed class? You know, with methods and members.

It is this very thing that SOAP provides. If that wasn’t cool enough, there’s one more trick in the hat. SOAP is language agnostic. The server could be running Java and your client code could be in PHP, or vice versa. This pretty much works between most any object oriented language that has an implementation of SOAP, which is most of the major ones today.

There are also a healthy stack of companies out there providing a variety of data and computation services to developers across the Internet. Things like address look ups, sales tax rates, or stock data. All kinds of data that an individual developer would normally never have access to is now readily embeddable in your code thanks to SOAP.

My point to you here is that just knowing how to access objects your value as a developer shoots up tremendously. Implementing things like the PEAR repository or SOAP isn’t much different than my little example creating a new Product object.

Moving Along

If at this juncture if I haven’t managed to convince you that there really is some benefits to all this class and object stuff then you might want to stop now while you’re ahead. Take no shame in this, as I have been there myself many times with various books and tutorials on this subject. More likely my approach to the subject may not have convinced you that there’s enough benefit to this for the cost of changing how you develop today.

For those of you still with me here, we’re about to embark into the realm of thinking in terms of object oriented design. Up to this point I’ve purposely kept things mostly procedural, even the Product class isn’t much more than some grouped functions.

Actual Object Oriented design gets us thinking in terms of how to better share methodologies between the classes that we create. In OO terms this is referred to as “inheritance”. The basic notion is that one class can inherit all the methods and members of another class. The inherited class then gets all those goodies from it’s parent. From there you can extend or override methods and members of the parent.

Inheriting A Fortune

Have I lost you yet? I know this all lost me on the road to OO design many times. To attempt to illustrate this let me present this to you in a purely functional way.

In our pretend scenario we’ve got a file with a dozen or so functions that deal with presenting different aspects of a product. Most of these are perfect for use across different projects that need to display a product.

A new project from Acme Widgets comes across your desk that could sure use most of that library. Unfortunately 2 of the functions are, by necessity are very specific to the project they are used on. In this scenario they are:

function showProductSpecs($index)
function displayProductPrice($index)

On top of this, Acme’s project also needs a new function that no other project will likely need.

function generateProductColorDropDown($index)

To address your problems here you could take all of these functions and put them in a new library specific to the project. Well that’s not going to work, since older projects expect to find those first two functions in the old library. You can’t just redefine a function on the fly, and you don’t want two almost identical versions of your library. How do you track changes to other functions?

You could just rename all the functions to something that’s specific to the project at hand. That’s not really all that great either since your function names have already gotten huge to avoid namespace conflicts. When you need all 80 columns for a function name, there’s a problem!

Darn, wouldn’t it just be simpler to let us programmers redefine functions on the fly? In short, that would be a really bad thing. Furthermore, I’m not looking to reinvent PHP here. We’ve got the tools we’ve got. And for those of us enterprising folks that are utilizing Object Oriented methodologies none of these problems are a problem at all. In fact, this is the very basis from where we can start into thinking in OO terms.

Let’s get that Product class back in here with the methods we need to implement. I’ve removed the accessor methods for clarity and put in those two functions that existed for another project.

class Product
{
  private $model = “”;
  private $description = “”;

  public function __construct($index)
  {
    $this->pullFromDatabase($index);
  }

  public function showProductSpecs($index)
  {
    // Some clever display code
  }

  public function displayProductPrice($index)
  {
    // Clever price calculations returned
  }

  private function pullFromDatabase($index)
  {
    // Fancy database query would run here
    $this->$model       = $dataRow[“model”];
    $this->$description = $dataRow[“description”];
  }
}

So how does this solve the problem of needing new functions for the Acme project? We can now inherit this Product class into a new class called AcmeProduct. Let’s start slowly here and not implement anything new here.

class AcmeProduct extends Product
{

}

$ap = new AcmeProduct(12);

What the…? There’s nothing in that class! How can you create a new object from an empty class for crying out loud? The answer is, of course, inheritance. Everything about the Product class becomes AcmeProduct when you “extend” it.

So what’s the big deal then? All we’ve got is two classes that do the exact same thing with a different name. Or so it would seem. How about we add in that special method specific to the Acme project.

class AcmeProduct extends Product
{
  public function generateProductColorDropDown($index)
  {
    // return some kind of form list
  }
}

$ap = new AcmeProduct(12);

Now we’ve got everything that Product had, plus a new method only available to code that creates a new AcmeProduct. We’ve just added functionality to the Product class without having to alter anything in the Product class.

Now let’s override those functions in the Product class that need something special for this Acme project.

class AcmeProduct extends Product
{
  public function generateProductColorDropDown($index)
  {
    // return some kind of form list
  }

  public function showProductSpecs($index)
  {
    // Specs like Acme wants to see
  }

  public function displayProductPrice($index)
  {
    // Pricing just for Acme
  }
}

$ap = new AcmeProduct(12);

Unlike functions in the global namespace, methods can be redefined by a child class that’s inherited them. We get all the other methods and members from the Product class as though you had copied and pasted them on in. We’ve added to the library of methods, and changed 2 of them. All the while we haven’t had to alter a single line of code in the original Product class. Can you dig it?

Code that had been utilizing that Product class all along will not be impacted in the least by this new class.

Inheritance Implications

Dear reader I need you to stop for just a moment and consider the implications of this. If you think of this in procedural terms, we’ve just refined an otherwise generic library of functions into a more specific library without losing anything of the original.

If you were to go back and optimize some of your other methods in Product, any class that inherits from this gets all those benefits as well. You may well find that you never actually create an object from that Product class directly, but instead extend it to new classes that refine what it does for each new project. Along that line of thinking, you would try to stuff all those methods and members that child classes could all use into that Product class.

PHP restricts your ability to inherit to just one parent. In other words, a class can only extend from one parent. There’s a darn good reason for this, which I won’t get into here. Just remember that only one parent is allowed. Thing is, you can have multiple generations of parents going up an object’s family tree. For example, here are three classes that live in the same inheritance tree:

Product > AcmeProduct > AcmeProductWidgets

In this case, AcmeProductWidgets gets everything that AcmeProduct has to offer, which is also everything Product has as well.

Where a child is restricted to one parent, a parent can have lots of little class kiddies running about.

Product > AcmeProduct
… > CompProduct
… > SurfProduct

The top most parent in the tree would contain the methods and members most likely needed by it’s children. Then each child further refines or adds functionality.

I Miss My Parent

Our AcmeProduct class has thus far just replaced two perfectly good methods from it’s parent class. In doing so we had to use that evil “Copy&Paste” coding method. What if what you really wanted to do with one of these methods was to just refine it just a bit. Let the parent class do all the work, then just tweak things a bit and take all the credit. Here’s the code:

class AcmeProduct extends Product
{
  public function generateProductColorDropDown($index)
  {
    // return some kind of form list
  }

  public function showProductSpecs($index)
  {
    // Get the initial results from the parent method
    $specs = parent::showProductSpecs($index);
    // Now refine it in some way and return it
    return $specs;
  }

  public function displayProductPrice($index)
  {
    // Pricing just for Acme
  }
}

Worked in a new one in there for you, “parent”. Using parent with our fancy Name Space Identifier double colon thingy, we can get mom (might be dad) to do all the hard work for us. Since both parent and child have this method with the exact same name you have to have some way of telling PHP which one you mean. Using the keyword “parent” does that very thing.

Are My Parents Keeping Secrets

Child classes can’t directly access either methods or members that have been marked “private”. Earlier when I stated that a child gets everything that the parent provides, what this really means is what it provides that isn’t private.

Along the same line of thinking as when I first presented the notion of setting permissions for methods and members, this all holds true even for child classes. There are just some things that parents don’t want their children to know about.

The notion of inheritance brings up a third kind of permission that only makes sense when you will be extending an object. Instead of public or private, you can set a permission of “protected”.

• A method or member that is set to “protected” may only be accessed within the same or inherited class.

Let’s see this in action with our now heavily abused Product class.

class Product
{
  private $model = “”;
  private $description = “”;
  protected $index = 0;

  public function __construct($index)
  {
    $this->index = $index;
    $this->pullFromDatabase();
  }

  public function showProductSpecs()
  {
    // Some clever display code
  }

  public function displayProductPrice()
  {
    // Clever price calculations returned
  }

  protected function fetchPrice()
  {
    // Do something database'ish to get the raw product price
  }

  private function pullFromDatabase()
  {
    // Fancy database query would run here
    $this->$model       = $dataRow[“model”];
    $this->$description = $dataRow[“description”];
  }
}

I’ve changed 2 things in here. Before we get into the permissions bit, notice how I’ve changed the constructor. It now sets a member variable called $index then calls to the database pull. In doing so, I now no longer need to send that argument along to each and every method, as any of these methods can look up $this->index to get the value.

Both the fetchPrice() method and the $index member are protected. So, if you were to try the following bit of code, expect failure in your future.

$p = new Product(12);
$price = $p->fetchPrice(); // Don't have permissions to do that here!

However, the following is perfectly okay to do. In fact, this is what setting that “protected” permission is all about.

class AcmeProduct extends Product
{
  public function generateProductColorDropDown()
  {
    // return some kind of form list
  }

  public function showProductSpecs()
  {
    // Get the initial results from the parent method
    $specs = parent::showProductSpecs();
    // Now refine it in some way and return it
    return $specs;
  }

  public function displayProductPrice()
  {
    $price = $this->fetchPrice();
    // Pricing just for Acme
    return $acmePrice;
  }
}

The public method displayProductPrice() now calls a protected method from the parent as though it were a method within this very same class. We don’t use the “parent” identifier in this case since we don’t have to resolve a naming conflict like when you override a method.

Getting Abstract

Earlier I suggested the notion that a class at the top of the tree might be more useful as a container for methods and members to be shared by child classes. What if you wanted to enforce this. Say you wanted to make sure nobody ever tried to create a new Product object. You only want inherited children to use that class, then folks would create objects from there. Simple enough. Just state that the class is “Abstract”.

abstract class Product
{
  ....
}

With that in place, you can inherit everything provided by the Product class, you just can’t directly create an object from it. In this case, it would make a lot of sense to do this with a nice generic class like Product, with the thinking being that you only want more refined code actually getting utilized as objects.

Abstraction also allows you to force children to take care of some chores on their own. By defining a method without a body you are saying that a child must implement that method in order to inherit from this class. You know you’ve heard mom or dad say, “do as I say, not as I do”.  This looks like:

abstract class Product
{
  public function childMustDo();
  ....
}

Why on earth would you want to do something like that? For this article I’m going to dodge that question, as it gets into the notion of an object contract as well as polymorphism. A couple of topics going beyond the scope of what I’m presenting at this time.

I should also mention here that if any method within a class is abstract, in that it doesn’t have a body, then the entire class must be marked abstract. Making the class abstract does not require you to have any abstract methods though.

When An Object Doesn’t Want Children

In the case of our Product class, child classes really made a lot of sense. In some cases not only do children not make sense, but you actually want to enforce the notion that the class in question can not be inherited from. Mark that class “final” and no more inheritance is possible.

final class Product
{
  ....
}

That’s all well and good, except that we know this Product class is something we want to extend. If the case is that we just want to have certain methods that cannot be overridden by a child class, you can modify just that method with “final”.

class Product
{
  final public function neverToBeOveridden()
  {
    // perfectly formed code goes here
  }
  ....
}

Note that marking a method as private does not prevent a child class from overriding it. A private method just isn’t visible at all to anything outside of the class that declares it. Normally you would be better off avoiding overriding private methods due to the increased ambiguity. Be explicit in all that you do, and code will be usable and reusable for years to come.

What Got Left Out

I don’t want this to be the final word on Object Oriented design for you. My intention here was to help you with jumping some of the conceptual hurdles in going from a procedural methodology to an Object Oriented strategy. So as to keep you around to this point I’ve left a few concepts out of here so as to leave them to more qualified authors to address.

• I’ve totally dodged out of talking about Interfaces. They’re important, but not for the initial understanding of OO design.
• When do you inherit and when do you include objects? This gets into the realm of “IS A” and “HAS A” relationships.
• Various best practices and design patterns were all but totally vacant. Too many good books out there on these topics.
• There are several more magic methods I didn’t discuss. The two I did talk about I believe are the ones that are utilized far more often than any others. Some of these methods aren’t especially wise to use, which is why I didn’t bring up stuff like the Overloading methods.
• Class autoloading got left out. It’s a simple enough concept to read about in the official PHP manual.
• Static and constant data member variables.
• The extremely important topic of exception handling got left out.
• Lots of implementation details that are better handled elsewhere.

Summary

Even with a lot of the details left out I hope I have presented to you a reasonable introduction into the world of Object Oriented design. More importantly, if you can begin to see how you can utilize these concepts into your next project, or perhaps revamp an already existing project, I would consider this a success.

In a language like PHP the notion of traditional functions doesn’t go away now that PHP 5 has brought to us some real OO tools. Try not to get lost into the notion of either OO or procedural methods as the one true path. Combining the two is where you get the most bang for your efforts. Knowing when to apply one strategy or the other is a matter of experience and study.

Further Reading

There are a lot of new books coming out that get into the Object Oriented functionality in PHP. From what I’ve seen, many of these are garbage. Some are not much more than barely updated versions of previous PHP 4 books that just barely touch on how dramatic a change PHP 5 has brought to us lowly web developers. Here are a few good ones I feel comfortable in recommending.

“Head First Java”
by: Kathy Sierra & Bert Bates
O’Reilly

A Java book to learn about PHP? You betcha. If there are some awful PHP books out there, that number is easily tripled when talking about Java books. Here is an exception. This is a wonderful introduction into Java and Object Oriented design. The biggest mental translation to make here is that PHP is not a type safe language, where as Java requires that you declare everything explicitly. Beyond that, the Object Oriented discussions mostly apply to any OO capable language.

“Object-Oriented PHP”
by: Peter Lavin
No Starch Press

Although I found this author’s approach to be weak in how he introduces OO design, it’s an outstanding follow up to better understanding the specifics of how PHP 5 handles things. Just keep in mind that his first couple of chapters has examples using PHP 4. The remainder of the book is pure PHP 5.

“PHP Objects, Patterns, and Practice”
by: Matt Zendra
Apress

Once you have what you think is a firm handle on what all is going on with OO design it would be about time to give some time over to this book. Here is where you’ll pick up many of the best of PHP’s best practices.

Is It All Worth It

For just the sake of PHP developing, it’s worth it and then some. The more that you utilize this approach to designing software, the more time you’ll save. You’ll find it far easier to pass code around to various projects, even projects you may never be directly involved with. You can now utilize the rich variety of classes available on the Internet, and extend them as needed.

Perhaps even more importantly, other languages like Java, Python, and even C++ start making a lot more sense. Most OO design techniques cross the language barrier with mostly syntax details changing between them. There’s certainly more than just minor syntax details that divide these languages, but my point is that the concepts cross those barriers. This is one of the reasons why something like SOAP is able to work at all. The object concept bridges across the divide.