PDO wrapper structure

When trying to make things like this, it's amazing how quickly it can become complicated and how many OOP ideas and principles can be involved.

Anyway, there's a lot to cover here, so I'm just going to glaze over a few things and may come back and edit more detail in later.

For a "first heavy OOP code design" this is pretty good (probably better than the typical first real go at it), but there are a few things that stood out:

• self:: is almost always a bad sign
  • It means that a variable is basically a namespaced global
  • It means that a method has absolutely nothing to do with the state of an object of the class it belongs to. This can make sense in a few situations, but it is a decision that should be carefully considered unless it's one of the obvious uses.
  • Your code is wrong on a technical standpoint because you cannot--well, should not, since PHP is overly lenient--call a non-static method statically. It doesn't make sense. $this and self are not interchangable at all.
• Your class is MySQL specific
  • Backticks are MySQL specific
  • A few other things that I'm too lazy to look back through the code and refind :)
• You're mixing concerns with query creation and database connection.
  • prepare, query etc are fairly low level operations
  • creating statements with methods like where is a fairly high level operation
    • If you want a DBAL, create a DBAL. A DBAL should have a connection, not be a connection.
  • People for some reason always want to extend PDO. There are situations where that makes sense, however, 99% of the time, it does not.
    • If you want an SQL helper class, then have a class that uses a PDO instance behind the scenes. Don't couple your helper class and your connection class together.
• You're abusing exceptions
  • How does a consumer of your class know that a PDOException occurred? You should almost never eat an exception. If your methods fail, the consuming code probably needs to know.
• Your logging is flawed
  • If you ever find yourself used a class like C::a(); C::b(); or if you ever find yourself creating a new object in a method, it's likely a sign that the dependency should be provided by the caller.
    • Provides flexibility (what if someone wants to have two instances of your class and use two different loggers?)
    • Eases coupling (Database is secretly dependent on PDO -- telling consumers to uncomment the code if they have a logger named Log is not sufficient)
  • Pass in a logger instead that implements a certain interface
    • Allows flexibility like a null logger (a logger that just discards everything) or like having one instance log to a DB table and another to a CSV
  • Depending how low level your class ends up being, a logger may not belong there.
    • What I mean by this is that there's a certain level where logging just doesn't make sense. System calls don't log. Even PDO doesn't log. You should probably handle logging in application-land where the application can have a better feel for how logging should be handled.
• Your constructor kills flexibility
  • SQL Server or Postgres for example, will have much different DSNs than MySQL
    • in trying to be overly helpful, your constructor has killed this flexibility -- there's a reason PDO takes a DSN and not the params your constructor takes.
  • You address persistence, but what about the other attributes?
• A few stylist notes (note: these are 100% opinion)
  • It's fairly standard to indent to the first level inside of classes
  • switch: and endswitch; are very rarely used. A lot of people will vehemently argue with me on this one, but I think that the endwhile; endif; and so on constructs are a hideous blotch a on C-esque language.
  • Null is almost always written either NULL or null in PHP.

In short, this is a good start, but you're probably headed down the wrong path with this class. There's a lot of technical and design flaws here that need to be addressed. I would suggest learning the OO syntax a bit more and trying to better familiarise yourself with low level philosophies and ideas of object oriented programming (when I have more time later I'll come back and provide some links).

On Extending Classes

As Corbin says. It is rarely necessary to extend a predefined class. Think of it like this. You should only "extend" a class if you want to add functionality to it. Functionality mean a new feature. This does not mean, usually, redefining the entire class. Using a class is not the same as extending it. In this case you want to "use" the class, not "extend" it.

Some things about PHPDoc

I don't know how it is treated in other IDE's, but on netbeans (and I'm pretty sure eclipse) your PHPDoc comments do not show up because they are not in the (proper format)[http://www.phpdoc.org/docs/latest/for-users/anatomy-of-a-docblock.html]. This means the IDE doesn't know what to display when you try to use it, which makes these comments mostly useless. The link should help with any further questions that I don't cover in this section. The way you are currently doing it, it is just treated as a normal comment and therefore ignored. To initiate a PHPDoc comment you MUST use two asterisks /** to open it. A simple search and replace can fix that for you. Also, the "access" parameter is unnecessary, that should be documented somewhere on that site I linked you, but they changed it since last I looked and I'm not sure where it is anymore. I also don't think the "constructor" parameter is used anymore either, but I can't swear to that one.

/**@var mixed $stmt Used as a temporary variable to hold queries*/

/**allows easy instantiation and multiple database connections.
  *
  * @param    mixed $db   When array(), var holds all parameters required to connect.
  *                       When string, var holds the type of DB to connect to. E.g. mysql
  *
  * @param        string $serverHost      the host of the DB connection
  * @param        string $dbName          the name of the database
  * @param        string $dbUser          the respective name of the user
  * @param        string $password        the password of the user connecting
  * @param        bool   $persistent      if true, allows connection to persist through the app
  *
  * Database __construct ( mixed $db, [ string $serverHost = Null], [ string $dbName = Null],
  * [ string $dbUser = Null], [ string $password = Null], [ bool $persistent = Null])
  *
  */

The PHPDoc inside your methods ARE useless. Even if they did have the proper syntax, they would do nothing because they are located in the wrong place and are only making it difficult to read your methods. All of your interior DocBlocks should be combined with their exterior ones. Its also redundant and unnecessary to rewrite parent PHPDoc comments. If the parent class has documentation, the child class inherits that as well as any methods and properties. The only time this becomes an issue is if the child method does something completely different than the parent method, but then you are doing something wrong.

Here's another cool thing about PHP properties/PHPDoc comments. Though this is purely preference, I find it easier to keep my properties together this way :)

private
    /**@var mixed $stmt Used as a temporary variable to hold queries*/
    $stmt = Null,

    /**@var mixed $scopeSelectVar Used as a temporary variable to hold queries*/
    $scopeSelectVar = Null
;

Either way, you are definitely better about your documentation than I am. Keep that up and I'll aspire to be more like you :)

Self vs This

Here's a link to help illustrate the difference between self:: and $this->. I have a hard time explaining this one, otherwise I would normally translate this for you. The more helpful of the answers, in my opinion, is the second one. But the first answer as well as a few others are pretty good too, they just expect you to already understand some of the more advanced OOP concepts. Corbin had a good explanation, but it seemed somewhat vague. No offense to Corbin, he's a good reviewer, but this is a difficult topic to explain (at least for me).

If you take nothing else from that link, just remember self:: is static (as is anything with ::) and $this-> is not. You commonly see this syntax in child classes when overriding parent methods where you use the parent:: to call the parent's version of that method (or property). So the below snippet, and any others like it, should not use self:: because those methods are not static.

$param = self::defineParamType($val);

Comments

Endif, endfor, endforeach, etc... All comments along these lines, at least if you have a common IDE, aren't all that helpful. All IDE's, at least all the good ones, have brace matching highlighting, and usually code folding too. Either of these features is usually enough to find the end of a block of code. The comments typically just add noise. So this comment below is unnecessary. In fact, most comments inside methods should be avoided or only used for development.

//if Var $db == array() then connect using array parameters

Don't Repeat Yourself (DRY)

Along with many other principles, the DRY principle is a key point of OOP. Another good one is the Single Responsibility Principle, which is something Corbin was driving at. The names usually explain the principle fairly well. In this case, don't have repetitious code. Usually this means creating a function or method or loop. But in this case, it means moving things around and assigning new variables or redefining existing ones. So, for example here is your constructor, rewritten to use this principle.

$persistance = array( PDO::ATTR_PERSISTENT => $persistent );
$type = $db;

if( is_array( $db ) ) {
    $type = $db[ 'dbType' ];
    $serverHost = $db[ 'Host' ];
    $dbName = $db[ 'dbName' ];

    $dbUser = $db[ 'dbUser' ];
    $password = $db[ 'dbPassKey' ];
}

$conn = "$type:host=$serverHost;dbname=$dbName";
parent::__construct( $conn, $dbUser, $password, $persistance );

Of course, you could use extract() above to an even better effect, but not many people like extract() or its counterpart compact(). The reasoning being that they are difficult to debug for. I believe that so long as the variables expected are being documented and the source is trusted, you should be fine. So the use of these functions are entirely up to you.

Escaping Variables in Strings

You may have noticed in the above section that I did not define $conn the same way you would have. I removed the braces from inside the strings because they are unnecessary. When declaring simple variables inside a string, it is only necessary to use PHP's escape sequence, "{}", when the variable name is likely to run into another word. For instance:

"{$verb}ing"

The only other time it is necessary to use the escape sequence is when using complicated variables. Such as:

"host={$db[ 'Host' ]}"
//OR
"host={$this->host}"

When in doubt, it wont hurt, but it makes it harder to read. Depending on the implementation it is sometimes just better to manually escape these sequences yourself.

Template Language

PHP is sometimes considered a templating language. One of the features that highlights this is the alternative syntax for its statements. For instance if: endif;. The colon and endif are the alternative syntax. Typically this is seen only in templates. So seeing it inside a class is quite odd, especially when not combined with the other alternatives. You should be consistent, and honestly you should only use this format in templates. It's a stylistic choice, but one most of the community agrees with.

switch( $var ) {
    case 1 :
        //contents
    break;
    //etc...
}

Exception Handling

I'm no expert here, but I believe the proper way to do exception handling is merely to throw the exception if one is found then catch it during implementation. So all of these try/catch blocks are unnecessary and redundant.

Conclusion

It was about at this point that I stopped reading. A lot of it appeared to be repeat issues or things Corbin already covered. As Corbin said, this is a good start. Keep up the good work!