It works just like a singleton, except instead of having one $instance variable, I have an array of $instances which is keyed by the name of the database connection I want.

My factory method gives me back the appropriate singleton instance like so:
$DB = DB::factory(‘write’);

That way there are only database connections for as many names as I have open, which are usually only the two I mentioned: ‘read’ and ‘write’.

I manage the configurations in an array with names that match the connection names, ‘read’ and ‘write’ like so:

$database = array(
‘read’ => array(
‘host’ => ‘localhost’,
‘user’ => ‘web_db’,
‘pass’ => ‘dog1cat’,
‘data’ => ‘slave_database’,
),
‘write’ => array(
// etc…
‘data’ => ‘master_database’,
),
);

Unfortunately, you haven’t provided one scrap of evidence to support your assertation: that they are patterns that solve design problems with less drawbacks than the alternatives.

Perhaps it would do you well to look at the examples raised in this thread and the links to Misko Hervey’s talks.

These are numerous examples grounded in real life experience about the negatives of using these patterns in your designs, and to date, there are very few drawbacks to dependency injection listed here.

The main reason we’re so passionate about this is pretty simple: you, the author of the original code make a bunch of choices to use statics, global state, singletons, etc; and can’t see the harm in it.

We, the poor saps who have to unit test it, fix it, debug it, and maintain it get stuck with an impossible pile of code which refuses to play nicely with our expectations, breaks unexpectedly, and frustrates us.

That makes us cranky, and makes us think things like “the person who implemented this design is being evil to us”.

To consider: you could very easily modify Brandon’s code to make it ‘write-once-read-forever’ – in order to allow for creating and storing a database connection once in the registry but not allow anything to overwrite this. Which obviously makes all the high-pitched cries about globals meaningless. In other words: use whichever design matches what you’re doing – don’t listen to people fervently arguing that something or other ‘is evil’.

Regards
Fake

I hope there are some sort of better solutions to make testing of singletons, registries, and similar patterns easier.

Why does the SMS code above need a database connection? It doesn’t; and if the SMS code doesn’t run because the database code is broken, that’s annoying.

“And the risk of omitting something important is high (I have an experience).”

Perhaps, but you haven’t given any code examples or scenarios to back your point of view, so…

“By the way – Zend Framework, the flagship of PHP, is full of static methods, the Registry is also there. And some classes are singletons (e.g. Zend_Auth). The world is colorful.”

Zend_Auth is annoying to test and code built using it is too.

// Why should this:
$auth = new Zend_Auth(); // Cause: Fatal error – private method __construct(); ?

// A typical example using a singleton, no injection
class GuardCow {
/** Greets people it knows, moos at strangers */
function noise() {
$auth = Zend_Auth::getInstance();

return $auth->hasIdentity() ? “Hi” : “moo”;
}
}

The above isn’t easy to test if I want to make sure that $auth->hasIdentity() returns true or false or whatever I please.

How would you write the 2x unit test to assert the cow moos at strangers, and greets friends?
1. You have to open up the code in Zend_Auth, read it, and realise that you need to mock out the Storage layer.
2. Create a mock
3. In each test, load the auth object, set the desired result

function testShouldMooAtStrangers() {
$auth = Zend_Auth::getInstance();
$auth->setStorage(new MockStorage(false));

$cow = new GuardCow();
$this->assertSame(“moo”, $cow->noise());
}

function testShouldGreetFriends() {
$auth = Zend_Auth::getInstance();
$auth->setStorage(new MockStorage(true));

$cow = new GuardCow();
$this->assertSame(“Hi”, $cow->noise());
}

What happens if I forget the first two lines in each test case? Why do I need to mock out Auth Storage to say my guard cow doesn’t know me? It’s not obvious when I look at the GuardCow class that I have to think about storage at all.

However, if Zend_Auth wasn’t a singleton, I could have just:

function testShouldMooAtStrangers() {
$cow = new GuardCow(new MockAuth(false));
$this->assertSame(“Hi”, $cow->noise());
}

function testShouldGreetFriends() {
$cow = new GuardCow(new MockAuth(true));
$this->assertSame(“Hi”, $cow->noise());
}

Less code, I don’t need to read the internals of Zend_Auth, and I’m doing what I care about – testing my guard cow.

So, I’d love to see examples where statics, registry pattern or singletons both solve initial design problems and (this is the important one for me and many other DI fans) are still flexible enough when you want to unit test it that it’s trivial / easy to do so, *and saves you time*.

@clockwerx: … I have to fix my problems connecting to the Database before …
Yes, you must. You can of course simulate roof without walls but in reality you need walls at first. No anger, no frustration. And the risk of omitting something important is high (I have an experience).

@fqqdk: I believe that programmer should use the best methods or patterns he can. I am big fan e.g. of stored procedures (evil). If analysis shows the singleton (evil) is applicable I can freely choose it. If I need more return values, I consider output parameters (evil). If total decoupling seems better, have no problems with it.

By the way – Zend Framework, the flagship of PHP, is full of static methods, the Registry is also there. And some classes are singletons (e.g. Zend_Auth). The world is colorful.

Well I can’t really argue with you now. I think it is better to always go for the most decomposed code with the least amount of coupling, and separating unit tests from integration tests gives me that. I can test the methods logic with the DB mocked out very quickly, and the actual integration in a separate suite of tests that won’t run that frequently. That maximizes the speed of feedback, makes my code cleaner, with APIs that do not lie about the dependencies, and that makes me happy. You keep your logic and integration testing coupled, and have your classes depend implicitly on some god object.. erm.. registry, it’s your call. But I still think it’s wrong.

Re the ruling out through exceptions, imagine this sequence of events:

1. Build registry
2. Connect DB (exception thrown)
3. Connect SMS (test failed: exception in DB::connect)
4. Run DB test (test failed: exception in DB::connect)
5. Teardown (test failed: exception in DB::connect)
6. Build registry
7. Connect DB (exception thrown)
8. Connect SMS (test failed: exception in DB::connect)
9. Run SMS test (test failed: exception in DB::connect)
10. Teardown (test failed: exception in DB::connect)

I look at the SMS test first, and it’s talking about failing when the database didn’t connect. Huh? What? I look at the code for you and you don’t even use a database!

Typically this results in anger, frustration, grumbling before…. Oh, it’s some kind of outside influence! It’s in the Registry building code, over here.

Suddenly, I have to fix my problems connecting to the Database before I can know if I’ve even got problems with my SMS code.

Another example:
http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html

That post talks about singletons, but Registry::get() is similar – you have to set it up just right in all sorts of places which are non obvious, and can lead to nasty results and strange interactions for no clear reason.

Given some class that requires a database connection, mocking the database makes testing the business logic much easier:

class Finance {
function __construct($db) { $this->db = $db; }

function calcAmountFinanced($dealno, $term, $payment) {
$amount = $term * $payment;

// save amount in database
$this->db->query( “INSERT INTO deal (DealNum, Amount) VALUES ($dealno, $amount)” );

return $amount; // return to client so they can see amount
}
}

class FakeDb {
function query($sql) {
return true;
}
}

function testCalcAmountFinanced()
{
$db = new FakeDb();

$finance = new Finance($db);

$amount = calcAmountFinanced(60, 150.00);
if ($amount == 9000) {
return true;
}

return false;
}

Now I can automate that test in a cronjob each night without managing a database. This becomes even more useful when I test a particular method multiple times. I don’t have to reset the database information to do it. This does not remove the requirement of integration testing with a live database, but it makes it easier for me to spot a problem earlier.

… can rule out the SMS component failing as a cause of your DB errors / vice versa; which is harder in scenario 1 …
No way. We have e.g. exceptions.
class A {
function b() {
try {
$db = Registry::get(’db’);
….
} catch ….
}

1. Build registry
2. Connect DB
3. Connect SMS
4. Run DB test
5. Teardown
6. Build registry
7. Connect DB
8. Connect SMS
9. Run SMS test
10. Teardown

Scenario 2 (injecting only what you need):
1. Connect DB
2. Run DB test
3. Teardown
4. Connect SMS
5. Run SMS test
6. Teardown

Additionally, by controlling your environment tightly, you can rule out the SMS component failing as a cause of your DB errors / vice versa; which is harder in scenario 1

@clockwerx: … you have to build a registry and fill it with both SMS and DB instances … But to test your first method versions, you must pass existing instances as arguments. Is there any difference in term of speeed?

I agree with you about the problems with this design. Even if someone use Registry pattern it shouldn’t be used within the class but prior to wiring the objects to pull the needed objects from the global repository.