Después de leer this description de enlace estático tardío (LSB) veo bastante claramente lo que está sucediendo. Ahora, ¿bajo qué tipo de circunstancias podría ser más útil o necesaria?¿Cuándo necesitaría utilizar encuadernación estática tardía?
que necesitaba LSB esto para el siguiente escenario:
Si desea obtener más información sobre el tema:
Si necesita acceder a una propiedad/método estático sobrecargado dentro de un método que no ha sido sobrecargado en una subclase: necesita enlace estático tardío. Un ejemplo rápido: paste2.org
El ejemplo clásico es la clase ActiveRecord de Rails, si se intenta implementar algo similar en PHP, que se vería así: class User extends ActiveRecord y luego intenta llamar User::find(1) el método que es llamada es en realidad ActiveRecord::find() porque no ha sobrecargado find() en User - pero sin enlace estático tardío el método find() en ActiveRecord no tiene forma de saber de qué clase se llamó desde (self dentro de él siempre apunta a ActiveRecord), y por lo tanto no puede recuperar su Usuario-objeto para ti.
Una de las principales necesidades que tengo para el enlace estático tardío es para un conjunto de métodos estáticos de creación de instancias.
Este DateAndTime class es parte de una biblioteca de cronología que porté a PHP desde Smalltalk/Squeak. El uso de métodos de creación de instancias estáticos permite la creación de instancias con una variedad de tipos de argumentos, mientras se mantiene la verificación de parámetros en el método estático para que el consumidor de la biblioteca no pueda obtener una instancia que no sea completamente válida.
La vinculación estática tardía es útil en este caso para que las implementaciones de estos métodos de creación de instancias estáticas puedan determinar a qué clase se dirigió originalmente la llamada.Aquí está un ejemplo de uso:
Con LSB:
class DateAndTime {
public static function now() {
$class = static::myClass();
$obj = new $class;
$obj->setSeconds(time());
return $obj;
}
public static function yesterday() {
$class = static::myClass();
$obj = new $class;
$obj->setSeconds(time() - 86400);
return $obj;
}
protected static function myClass() {
return 'DateAndTime';
}
}
class Timestamp extends DateAndTime {
protected static function myClass() {
return 'Timestamp';
}
}
// Usage:
$date = DateAndTime::now();
$timestamp = Timestamp::now();
$date2 = DateAndTime::yesterday();
$timestamp2 = Timestamp::yesterday();
Sin fines de enlace estático, [como en mi aplicación actual] cada clase debe implementar todos los métodos de creación de la instancia como en este ejemplo:
Sin LSB:
class DateAndTime {
public static function now($class = 'DateAndTime') {
$obj = new $class;
$obj->setSeconds(time());
return $obj;
}
public static function yesterday($class = 'DateAndTime') {
$obj = new $class;
$obj->setSeconds(time() - 86400);
return $obj;
}
}
class Timestamp extends DateAndTime {
public static function now($class = 'Timestamp') {
return self::now($class);
}
public static function yesterday($class = 'Timestamp') {
return self::yesterday($class);
}
}
A medida que el numbe r de los métodos de creación de instancias y la jerarquía de clases aumenta la duplicación de métodos se convierte en un verdadero dolor en el trasero. LSB reduce esta duplicación y permite implementaciones mucho más claras y sencillas.
Es útil cuando:
Usted tiene una funcionalidad que varía a lo largo de la jerarquía de clases,
La funcionalidad tiene la misma firma sobre la jerarquía, y
(crucialmente) Usted no tiene una instancia para suspender la funcionalidad.
Si solo obtuviera el n.º 1 y el n.º 2, utilizaría un método de instancia ordinario. Entonces el problema de Alex (ver su respuesta a esta pregunta) no requiere LSB.
Un caso típico es la creación de objetos, donde las subclases se crean de diferentes maneras, pero utilizando los mismos parámetros. Obviamente, no tiene ninguna instancia para llamar, por lo que el método de creación (también conocido como método de fábrica) debe ser estático. Sin embargo, desea que su comportamiento varíe según la subclase, por lo que un método estático ordinario no es correcto. Vea la respuesta de Adam Franco para un ejemplo.
Supongamos que tiene clases que representan tablas (instancias de fila) en un mapeador relacional de objetos simplificado. Tendría una clase "Usuario" y una clase "Empresa" cuyas instancias representan filas de las tablas respectivas. El usuario y la empresa heredarían de una clase abstracta base, digamos "BaseObject" que tendrá algunos métodos comunes como save(), delete(), validate() etc ...
Si desea almacenar datos sobre la validación y la definición de tabla, el mejor lugar sería en una variable estática en cada clase derivada, ya que la validación y la definición de la tabla es la misma para cada instancia de Usuario.
Sin LSB el método validado() mencionado en BaseObject no tendría ninguna referencia a las variables estáticas definidas en Usuario y Empresa, aunque lo esté llamando a través de una instancia de Usuario. Buscará la misma variable estática en la clase BaseObject y generará un error.
Esta es mi experiencia con PHP 5.2.8 - LSB va a ser introducido en el 5,3
tengo una clase con un método estático que se encarga de parte del formato. Tengo otra clase que necesita toda la funcionalidad del original, excepto cómo maneja el formateo.
Sería útil si pudiera agregar * por qué * en este caso usar '' 'static ::' '' sería mejor o más fácil que simplemente usar un método abstracto, * no estático *.Para mí, parece que '' 'save()' '' es algo de lo que no tendrías razón para llamar desde un contexto estático de todos modos, pero tal vez me falta algo. – SeldomNeedy