Супер вызовет ваш родительский метод. См .: http://leepoint.net/notes-java/oop/constructors/constructor-super.html
Мне был нужен LSB это для следующего сценария:
Если Вы хотите узнать больше о предмете:
Одна насущная потребность, которую я имею для последнего статического связывания, для ряда статических методов создания экземпляра.
Этот класс DateAndTime является частью библиотеки хронологии, которую я портировал к PHP от Smalltalk/Squeak. Используя статические методы создания экземпляра включает создание экземпляров со множеством типов аргумента, при хранении параметра, регистрируясь в статическом методе так, чтобы потребитель библиотеки не мог получить экземпляр, который не полностью допустим.
Последнее статическое связывание полезно в этом случае так, чтобы реализации этих статических методов создания экземпляра могли определить, какой класс первоначально являлся целью вызова. Вот пример использования:
С 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();
Без последнего статического связывания [как в моей текущей реализации] каждый класс должен реализовать каждый метод создания экземпляра как в этом примере:
Без 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);
}
}
Как количество методов создания экземпляра и иерархии классов увеличивается, дублирование методов становится реальной болью в торце. LSB уменьшает это дублирование и допускает намного более чистый и больше простых реализаций.
Предположим, у вас есть классы, представляющие таблицы (экземпляры строк) в упрощенном объектно-реляционном преобразователе. У вас будет класс «Пользователь» и класс «Компания», экземпляры которых представляют строки соответствующих таблиц. Пользователь и Компания наследовали бы от некоторого базового абстрактного класса, скажем, «BaseObject», который будет иметь некоторые общие методы, такие как save (), delete (), validate () и т. Д.
Если вы хотите хранить данные о проверке и в определении таблицы наилучшим местом будет статическая переменная в каждом производном классе - поскольку определение и определение таблицы одинаковы для каждого экземпляра пользователя.
Без LSB упомянутый метод validate () в BaseObject не имел бы ссылка на статические переменные, определенные в User и Company, даже если вы вызываете их через экземпляр User. Он будет искать ту же статическую переменную в классе BaseObject и вызовет ошибку.
Это мой опыт работы с PHP 5.2.8 - LSB будет введен в 5.3
Если необходимо получить доступ к перегруженному статическому свойству/Методу в рамках метода, который не был перегружен в подклассе - Вам нужно последнее статическое связывание. Быстрый пример: paste2.org
Классическим примером является класс ActiveRecord от направляющих, если бы Вы пытаетесь реализовать что-то подобное в PHP, который был бы похож на это: class User extends ActiveRecord
и затем попытайтесь звонить User::find(1)
метод, который называют, на самом деле ActiveRecord::find()
потому что Вы не перегрузились find()
в User
- но без последнего статического связывания find()
метод в ActiveRecord
не имеет никакого способа знать, который классифицировал его, был назван от (self
в нем будет всегда указывать на ActiveRecord
), и таким образом это не может выбрать Ваш Пользовательский объект для Вас.
Это полезно когда:
У Вас есть функциональность, которая варьируется по иерархии классов,
Функциональность имеет ту же подпись по иерархии, и
(кардинально) у Вас нет экземпляра для зависания функциональности прочь.
Если бы только № 1 и № 2 получили, то Вы использовали бы обычный метод экземпляра. Таким образом, проблема Alex (см. его ответ на этот вопрос) не требует LSB.
Типичный случай является созданием объекта, где подклассы создают себя по-разному, но использование тех же параметров. Очевидно, у Вас нет экземпляра для вызова, таким образом, метод создания (также известный как метод фабрики) должен быть статичным. Все же Вы хотите, чтобы его поведение варьировалось в зависимости от подкласса, таким образом, обычный статический метод не является правильным. См. ответ Adam Franco для примера.
У меня есть класс со статическим методом, который обрабатывает некоторое форматирование. У меня есть другой класс, которому требуются все функциональные возможности исходного, за исключением того, как он обрабатывает форматирование.