In this case, however, the static getConnection method inherited from the database class DBX by the Table_ABC class falls back to a PDOConnection factory where connection settings are stored as constants or retrieved from files, Apache environment, whatever.

My database object knows about its dependency on a connection to a particular db host + schema and this ability is passed on to the extending table objects. This relationship is an implicit part of the model – a database object is a connection to a server/db.

And yet, it can still be overridden with setConnection() for testing or custom purposes.

So how would you create XYZ without a database and without resorting to Global Variable Magic?

If I do new XYZ() that how does $conn get set? From static GetConnection() method which resorts to global state. Not liking it

One of the niceties of some ActiveRecord implementations, is that the creation of an object will cause all of the necessary database table meta data to be resolved:

abstract class ActiveRecordXYZ {
protected $schema; // db name
protected $table; // db table name
protected static PDO $defaultconn;
protected PDO $conn;
protected static $metadata; // sql field types and other meta data

public static setConnection(PDO $pdo) {
return static::$defaultconn = $pdo;
}

public static getConnection() {
return static::$defaultconn;
}

public __constructor() {
$this->conn = self::getConnection();
if (! $this->tablename) {
$this->tablename = $this->guessTablename();
}
}

protected function guessTablename() {
.. regex get_class($this) …
}

public fetchMeta() { .. self::$metadata = …; done once per class at first use .. }

public __get() {…$this->fetchMeta()…}
public __set() {…}
public load() {…}
public save() {…}
}

class DBX extends ActiveRecordXYZ {
protected $schema = ‘dbx’;

public static getConnection() {
if (! parent::getPDO()) {
$pdo = PDOFactory::getConn(’dbx_host’);
return self::setConnection($pdo);
}
}
}

class DBX_TableY extends DBX {}

$user = new DBX_TableY; // PHP now
$user->load(array(’id’=>123));
$user->name .= ‘ Jr.’;
$user->save();

Everything is still testable and mockable and all run-time dependencies are optional. Do you agree?

The getter/setters here are really tied to the Table class (as you put it), and I can’t justify breaking them out which would only seem to add more complexity with no practical advantage.

The testability issues are universal. But lets look at ruby

1) Static methods are hard to override in Java, but easy in Ruby. Overriding the method is equivalent to changing global state since you have to clean up after-yourself. In ruby you have nice frameworks to do that for you, but it is global state any ways, which means you can never run things in parallel. So if ruby ever gets multithreaded you are in trouble. Also you can only override the method for everyone, while in instance method you con override it per instance. So for example if you have a chain of responsibility pattern you will have hard time testing it since you have just overridden the methods for everyone in the chain.
2) Static methods do not make it clear where the configuration is coming from which causes your API to lie to you: http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/
3) Static methods are not OO, they are procedural. There is nothing wrong with procedural, but if your language of choice is OO, why are you writing procedural code.

Just because ruby has figured out clever frameworks to test static methods, it does not make it a good idea.

I think the point of the article was that any implementation which has static methods on the classes for persistence is a bad Idea. Those that separate it to two classes one for the table and one for row are much more testable.

If you want to have Save on Account class rather than Account Table, than the Accounts needs to have a reference to AccountsTable. This means that some of Account class fields will be persisted and some will not. This is mixing of concerns. Check out: http://misko.hevery.com/2008/09/30/to-new-or-not-to-new/