Deje de usar `global` en PHP

El punto en contra de global variables es que la pareja de código muy bien. Su código base completa depende de a) la variable de nombre $config y b) la existencia de esa variable. Si desea cambiar el nombre de la variable (por el motivo que sea), tienes que hacerlo en todas partes a lo largo de su código base. Usted también no puede usar cualquier pieza de código que depende de la variable de forma independiente de ella ya.

Ejemplo global variable:

require 'SomeClass.php';

$class = new SomeClass;
$class->doSomething();

En cualquier lugar en las líneas de arriba usted puede obtener un error porque la clase o algún código en SomeClass.php implícitamente depende de una variable global $config. No hay ninguna indicación de ello en absoluto, aunque sólo mirando a la clase. Para solucionar esto, tienes que hacer esto:

$config = array(...);

require 'SomeClass.php';

$class = new SomeClass;
$class->doSomething();

Este código puede todavía fracasan si no se establecen las teclas correctas en el interior de $config. Ya no es obvio lo que las partes de la configuración de la matriz SomeClass necesita o no necesita y cuando los necesita, es difícil recrear el ambiente adecuado para que se ejecute correctamente. También crea conflictos, si usted pasó a tener ya una variable $config utilizar para otra cosa dondequiera que usted desea utilizar SomeClass.

Así que en lugar de crear implícita, invisible dependencias, inyectar todas las dependencias:

require 'SomeClass.php';

$arbitraryConfigVariableName = array(...);

$class = new SomeClass($arbitraryConfigVariableName);
$class->doSomething();

Al pasar el array de configuración de forma explícita como un parámetro, todos los problemas están resueltos. Es tan simple como la entrega de la información requerida alrededor en el interior de su aplicación. También hace que la estructura y el flujo de la aplicación y lo que habla de lo mucho más clara. Para llegar a este estado si su aplicación es en la actualidad una gran bola de barro pueden tomar algunos de reestructuración.

El más grande de su código base, más tienes que separar las piezas individuales de cada uno de los otros. Si cada parte es dependiente de cualquier otra parte en su base de código, simplemente no se puede probar, utilizar o reutilizar cualquier parte de la misma de forma individual. Que simplemente se convirtiera en un caos. Para separar las piezas de cada uno de los otros, de código como clases o funciones que tienen todos sus datos requeridos como parámetros. Que crea limpio costuras (interfaces) entre las diferentes partes de su código.

Tratando de atar a su pregunta en un ejemplo:

require_once 'Database.php';
require_once 'ConfigManager.php';
require_once 'Log.php';
require_once 'Foo.php';

// establishes a database connection
$db = new Database('localhost', 'user', 'pass');

// loads the configuration from the database,
// the dependency on the database is explicit without `global`
$configManager = new ConfigManager;
$config = $configManager->loadConfigurationFromDatabase($db);

// creates a new logger which logs to the database,
// note that it reuses the same $db as earlier
$log = new Log($db);

// creates a new Foo instance with explicit configuration passed,
// which was loaded from the database (or anywhere else) earlier
$foo = new Foo($config);

// executes the conversion function, which has access to the configuration
// passed at instantiation time, and also the logger which we created earlier
$foo->conversion('foo', array('bar', 'baz'), $log);

Lo voy a dejar para la implementación de las clases individuales como ejercicio para el lector. Cuando se trate de ponerlas en práctica, te darás cuenta de que está muy clara y sencilla de implementar y no requiere de una sola global. Cada función y clase pone a todos sus datos necesarios pasado en la forma de los argumentos de la función. También debería ser obvio que los componentes anteriores pueden ser conectados juntos en cualquier otra combinación o que las dependencias pueden ser fácilmente sustituidos por otros. Por ejemplo, la configuración no necesita venir de la base de datos, o el registrador puede iniciar sesión en un archivo en lugar de la base de datos sin Foo::conversion tener que saber acerca de esto.

Ejemplo de aplicación para ConfigManager:

class ConfigManager {

    public function loadConfigurationFromDatabase(Database $db) {
        $result = $db->query('SELECT ...');

        $config = array();
        while ($row = $result->fetchRow()) {
            $config[$row['name']] = $row['value'];
        }

        return $config;
    }

}

Es una manera muy simple trozo de código que incluso no hace mucho. Usted puede preguntar por qué te gustaría esto como orientado a objetos de código. El punto es que esto hace que el uso de este código extremadamente flexible, ya que aísla perfectamente de todo lo demás. Usted da una conexión de base de datos en, se obtiene una matriz con una cierta sintaxis de la espalda. De Entrada → Salida. Claro costuras, claro interfaces, mínimo, responsabilidades bien definidas. Usted puede hacer lo mismo con una simple función.

La ventaja adicional de un objeto tiene es que es aún más desacopla el código que llama a loadConfigurationFromDatabase de cualquier particular, la aplicación de esa función. Si usted acaba de utilizar un global function loadConfigurationFromDatabase(), básicamente tiene el mismo problema de nuevo: que la función debe ser definida cuando se trate de llamar y existen conflictos de nomenclatura si desea reemplazarlo con otra cosa. Mediante el uso de un objeto, la parte crítica del código se mueve aquí:

$config = $configManager->loadConfigurationFromDatabase($db);

Usted puede substituir $configManager aquí para cualquier otro objeto que también tiene un método loadConfigurationFromDatabase. Que el "duck typing". No importa de qué es exactamente $configManager , siempre que se tiene un método loadConfigurationFromDatabase. Si camina como un pato y grazna como un pato, es un pato. O más bien, si se tiene un loadConfigurationFromDatabase método y le da la espalda válido de un array de configuración, se trata de algún tipo de ConfigManager. Se han disociado el código de una determinada variable $config, de un particular, loadConfigurationFromDatabase función y de un particular, ConfigManager. Todas las piezas pueden ser cambiado y cambiado y reemplazado y se cargan de forma dinámica desde cualquier lugar, porque el código no depende de ninguna otra pieza.

El loadConfigurationFromDatabase método en sí misma no depende de una determinada conexión de base de datos, siempre puede llamar a query en él y obtener los resultados. El $db objeto que se pasa en ella puede ser totalmente falso y leer datos desde un archivo XML o en cualquier otro lugar, siempre y cuando su interfaz todavía se comporta de la misma.