PHP avoid static classes to avoid dependencies, bu

问题:

Many times I heard to avoid static classes because they will insert dependencies that will render your code unusable in other projects, and will not allow to unit test it.

Let's say we have a typical class DB to access the Data Base, if such class is static we could call it wherever in our code:

DB::execQuery(...);

but this creates dependencies, so let's make the DB class NOT static, in such case we would have somewhere in our code:

$db = new DB();

and then we could call in our code

$db->execQuery(...);

But now when using the $db inside a function we need each time to first declare it like this

global $db;

Is there a way to workaround this?

One way could be to inject the $db object in the class that uses it, but I would have to inject it in all classes that use it, that's ridicolous, a static class would be much quicker to work with and less code to write. Am I missing something?!

回答1:

$db could be injected upon instantiation into a property, then you would only need to access this property instead of passing it around to each method.

class MyClass {
  protected $_db; // DB Connection
  public function __construct($db) {
    $this->_db = $db;
  }

  public function foo() {
    $this->_db->query('...');
  }

}

Beyond that, you can look into having a service-container (aka dependency-injection container) that trys to act like a global variable but solves some of the testing issues. Take a look at some of these related questions

• If Singletons are bad then why is a Service Container good?
• Is it good practice to have DI container replace a global $registry object?

Having a DI container lets you use static methods in your classes like DI_Container::get('db'). It looks a lot like global or some of the other static calls.. but in this case DI_Container contains special methods that allow for extra actions to be taken during testing and other circumstances.. eliminating some of the 'evilness' of global.

回答2:

In addition to Mike B's answer, I would point that the wrong design in your code is : « we could call it wherever in our code ».

Actually, database should only be used by your Model, or the small part of your application that has to know about the database. So these classes should know there is a database, and use it as a dependency (passed through the constructor as Mike B said).

But the rest of your application should not care about a database, its should only care about the Model. Focus on refactoring and gathering all the code that access the database into Model classes.

This way, your application will have a Model layer that has a dependency : the database object/connection. And the rest of your application will use the Model, whatever happens in the Model in none of the Controller/View business.

Enjoy refactoring.