В мире существуют две разновидности PHP-разработчиков. Одни предпочитают статические методы, потому что с ними легко работать, другие же, напротив, считают статические методы - зло и не используют их в своей практике.
В этой статье попробую, используя опыт работы с несколькими фреймворками, объяснить, почему некоторые разработчики игнорируют лучшие практики и используют целую кучу статических методов.

Кто любит статические методы?

Особенно часто их применяют разработчики, которые когда-либо использовали в своей работе фреймворк CodeIgniter .

Также, в число последователей статистических методов входят большинство Kohana- и Laravel-разработчиков.
Тут нельзя не упомянуть тот факт, что программисты, которые решают начать писать собственные вещи, обычно отказываются от использования CodeIgniter.

Почему, спросите вы?

CodeIgniter поддерживал PHP 4 до того, как статические методы были добавлены в PHP 5. Кроме того, CodeIgniter использует «супер-объект», который предоставляет равный доступ всем классам, назначенным контроллеру. Таким образом они становится доступными к использованию в рамках всей системы.

Это означает, что классы могут быть доступны из любой модели с помощью метода __get(), который будет искать запрашиваемое свойство с помощью get_instance()->{$var} . Ранее, когда поддержки функции __get() не было в PHP 4, для этого использовалась конструкция foreach через параметры CI_Controller, а затем они назначались переменной $this в модели.

В библиотеке вы должны вызвать get_instance. Библиотека не наследует класс в принудительном порядке, поэтому нет никакого способа обойти функцию __get().

Объем…

Получается довольно громоздкая конструкция для доступа к коду. Точно такой ​​же функциональности без дополнительных усилий можно достичь с помощью статического метода.

Да и нет особого смысла рассуждать о такой конструкции. Хорошо, вы можете получить доступ к данным сессии в своей модели. Но зачем вам это делать?

«Решение»

Kohana-разработчики были первыми, кто серьезно поработал над статическими методами. Они внесли следующие изменения:
//было $this->input->get("foo"); // стало Input::get("foo");
Для многих CodeIgniter-разработчиков с их устаревшим PHP 4, которые переехали на фреймфорк Kohana, чтобы пользоваться всеми прелестями PHP 5, в этом ничего необычного нет. Но ведь, чем меньше символов, тем лучше, так?

И в чем же проблема?

Многие PHP-разработчики (особенно те, кто хорошо разбирается в Symfony и Zend) скажут: « Это же очевидно - используй Внедрение зависимостей!» Но не многие разработчики в сообществе CodeIgniter имеют реальный опыт работы с этим процессом, так как он довольно сложен.

Еще один факт о фреймворке Fuel PHP - пока в основном статические методы выступают в качестве интерфейса. Например, логика все еще имеет проблемы со статикой, особенно когда задействуется концепция HMVC.

Это псевдокод, который я не использовал в FuelPHP, начиная с версии 1.1:
class ControllerA extends Controller { public function action_foo() { echo Input::get("param"); } }
Довольно стандартный код. Этот метод будет выводить значение ?bar= в методе.

Что происходит, когда мы делаем HMVC-запрос к данному методу?
class ControllerB extends Controller { public function action_baz() { echo Input::get("param"); echo " & "; echo Request::forge("controllera/foo?param=val1")->execute(); } }
Вызвав в браузере controllerb/baz , вы увидите вывод «val1», но если вы наберете controllerb/baz?param=override , то получите оба вызова для получения метода, возвращающего то же самое значение.

Актуальность

Глобальный код не даст вам какого-либо отношения. Пример лучше любых слов:
$this->request->input->get("param");
Запрошенный объект будет содержать совершенно новый экземпляр для каждого запроса, тогда ввод объекта будет создаваться для каждого запроса, который содержит только входные данные для конкретного запроса. Это справедливо для FuelPHP 2.0 plans to work и решает проблему Внедрения зависимостей, а также проблемы с HMVC.

Как быть с грубым синтаксисом?

Symfony- или Zend- разработчики таким не страдают, а вот тем, кто использует CodeIgniter, долго будут сниться кошмары о «возвращении к PHP 4».

$this всегда обращается к «текущему» объекту, и точно не стоит использовать ее для доступа к глобальному коду.

$this->request->input->get() может выглядеть как удлиненная форма CodeIgniter-синтаксиса, но на самом деле мы просто находимся в контроллере. Когда контроллер создает экземпляр нового вложенного в него запроса, конструктор запроса также получает экземпляр на входе.

Если вы находитесь в модели или другом классе, то доступ вида $this->request->input->foo() не будет работать, потому что $this - не контроллер.

Конструкция Input::get("foo") создает фасад для экземпляров логики в фоновом режиме. Но это не решает вопросов, связанных с работой глобального кода. Самые ленивые при тестировании приложений могут переключаться между двумя режимами без необходимости полностью использовать новый фреймворк.

Есть отличное видео от Тейлора Отвелла (creator или laravel 4), в котором он описывает, как вы можете заменить статический код с единичным экземпляром, проверяемым через его DiC-контейнер.

Laravel 4 - IoC Controller Injection & Unit Testing from UserScape on Vimeo .

Это отличная презентация того, как можно обойтись без использования статических методов в Laravel. Хотя некоторые современные фреймворки, на первый взгляд, очень напоминают Kohana, они абсолютно по-разному решают даже самые стандартные задачи.

На этой печальной ноте…

Сейчас я занимаюсь преобразованием PyroCMS с CodeIgniter на Laravel. Пытаюсь перейти прямо от глобального кода PHP 4 к совершенному внедрению зависимостей - это абсолютное самоубийство. Промежуточный шаг перед использованием загрузчика CI - использование PHP 5, автозагружаемого кода PSR-2 с кучей статичных методов. Ну а пока мы все еще находимся в CodeIgniter.

Переход от статики к DiC-коду можно будет легко показать, когда мы, наконец, сделаем переход на Laravel.

Переход от сильносвязанного кода CodeIgniter к тестируемому PSR-2 - главная задача. Команда Pyro уже в пути - и это будет эпично.

Reg.ru: домены и хостинг

Крупнейший регистратор и хостинг-провайдер в России.

Более 2 миллионов доменных имен на обслуживании.

Продвижение, почта для домена, решения для бизнеса.

Более 700 тыс. клиентов по всему миру уже сделали свой выбор.

*Наведите курсор мыши для приостановки прокрутки.

Назад Вперед

Статические методы и свойства в PHP

В предыдущих материалах мы освоили основные возможности объектно-ориентированного программирования в PHP и сейчас переходим к изучению более сложных и интересных аспектов.

До этого мы всегда работали с объектами. Мы охарактеризовали классы как шаблоны, с помощью которых создаются объекты, а объекты - как активные компоненты, методы которых мы вызываем и к свойствам которых получаем доступ.

Отсюда следовал вывод, что что в объектно-ориентированном программировании реальная работа выполняется с помощью экземпляров классов. А классы в конечном счете - это просто шаблоны для создания объектов.

Но на самом деле не все так просто. Мы можем получать доступ и к методам, и к свойствам в контексте класса, а не объекта. Такие методы и свойства называются "статическими" и должны быть объявлены с помощью ключевого слова static .

Class StaticExample { static public $aNum = 0; static public function sayHello() { print "Привет!"; } }

Статические методы - это функции, используемые в контексте класса. Они сами не могут получать доступ ни к каким обычным свойствам класса, потому что такие свойства принадлежат объектам.

Однако из статических методов, как вы уже наверное догадались, можно обращаться к статическим свойствам. И если вы измените статическое свойство, то все экземпляры этого класса смогут получить доступ к новому значению.

Поскольку доступ к статическому элементу осуществляется через класс, а не через экземпляр объекта, нам не нужна переменная, которая ссылается на объект. Вместо этого используется имя класса, после которого указывается два двоеточия "::".

Print StaticExample::$aNum; StaticExample::sayHello();

С этим синтаксисом вы уже должны быть знакомы по основам ООП в PHP. Мы использовали конструкцию "::" в сочетании с ключевым словом parent для того, чтобы получить доступ к переопределенному методу родительского класса.

Сейчас, как и тогда, мы обращаемся к классу, а не к данным, содержащимся в объекте. В коде класса можно использовать ключевое слово parent для того, чтобы получить доступ к суперклассу, не используя имя класса.

Чтобы получить доступ к статическому методу или свойству из того же самого класса (а не из дочернего класса), мы будем использовать ключевое слово self .

Ключевое слово self используется для обращения к текущему классу, а псевдопеременная $this - к текущему объекту. Поэтому из-за пределов класса StaticExample мы обращаемся к свойству $aNum с помощью имени его класса.

StaticExample::$aNum;

А внутри класса StaticExample можно использовать ключевое слово self .

Class StaticExample { static public $aNum = 0; static public function sayHello() { self::$aNum++; print "Привет! (" . self::$aNum . ")\n"; } }

Обратите внимание: кроме случаев обращения к переопределенному методу родительского класса, конструкция "::" должна всегда использоваться только для доступа к статическим методам или свойствам.

По определению статические методы не вызываются в контексте объекта. По этой причине статические методы и свойства часто называют переменными и свойствами класса. Как следствие, нельзя использовать псевдопеременную $this внутри статического метода.

А зачем вообще использовать статический метод или свойство?

Вот мы и дошли до самого важного вопроса. Дело в том, что у статических элементов есть ряд полезных характеристик.

Во-первых , они доступны из любой точки сценария (при условии, что у вас есть доступ к классу). Это означает, что вы можете обращаться к функциям не передавая экземпляр класса от одного объекта другому или, что еще хуже, сохраняя экземпляр объекта в глобальной переменной.

Во-вторых , статическое свойство доступно каждому экземпляру объекта этого класса. Поэтому можно определить значения, которые должны быть доступны всем объектам данного типа.

И, наконец, в-третьих , сам факт, что не нужно иметь экземпляр класса для доступа к его статическому свойству или методу, позволит избежать создания экземпляров объектов исключительно ради вызова простой функции.

Чтобы продемонстрировать это, давайте создадим статический метод для класса ShopProduct , который будет автоматически создавать экземпляры объектов ShopProduct . C помощью SQLite определим таблицу products следующим образом:

CREATE TABLE products (id INTEGER PRIMARY KEY AUTOINCREMENT, type TEXT, firstname TEXT, mainname TEXT, title TEXT, price float, numpages int, playlength int, discount int)

Теперь создадим метод getInstance() , которому передается идентификатор строки и объект типа PDO. Они будут использоваться для извлечения строки из таблицы базы данных, на основании которой затем формируется объект типа ShopProduct , возвращаемый в вызывающую программу.

Мы можем добавить эти методы к классу ShopProduct , который был создан нам в более ранних материалах. Как вы, наверное, знаете, PDO расшифровывается как PHP Data Object (объекты данных PHP). Класс PDO обеспечивает универсальный интерфейс для различных приложений баз данных.

// Класс ShopProduct private $id = 0; public function setID($id) { $this->id = $id; } // ... public static function getInstance($id, PDO $pdo) { $stmt = $pdo->prepare("select * from products where id=?"); $result = $stmt->execute(array($id)); $row = $stmt->fetch(); if (empty($row)) { return null; } if ($row["type"] == "book") { $product = new BookProduct($row["title"], $row["firstname"], $row["mainname"], $row["price"], $row["numpages"]); } else if ($row["type"] == "cd") { $product = new CdProduct($row["title"], $row["firstname"], $row["mainname"], $row["price"], $row["playlength"]); } else { $product = new ShopProduct($row["title"], $row["firstname"], $row["mainname"], $row["price"]); } $product->setId($row["id"]); $product->setDiscount($row["discount"]); return $product; } // ...

Как видите, метод getInstance() возвращает объект типа ShopProduct , причем он достаточно "умен" для того, чтобы на основании значения поля type создавать объект с нужными характеристиками.

Я специально опустил код обработки ошибок, чтобы пример был по возможности лаконичным. Например, в реально работающей версии этого кода нам нельзя быть слишком доверчивыми и предполагать, что переданный PDO-объект был корректно проинициализирован и подключен к требуемой базе данных.

На самом деле нам, вероятно, следует заключить PDO-объект в класс, который гарантирует такое поведение. К этому вопросу мы еще вернемся в одном из будущих материалов.

Метод getInstance() более полезен в контексте класса, чем в контексте объекта. Он позволяет легко преобразовать данные, находящиеся в базе данных, в объект, причем для этого нам не нужно иметь отдельный экземпляр объекта типа ShopProduct .

В этом методе не используются никакие методы или свойства, требующие отдельного экземпляра объекта, поэтому нет никакой причины, чтобы не объявить его статическим. Тогда, имея корректный PDO-объект, мы можем вызвать данный метод из любого места приложения.

$dsn = "sqlite://home/bob/projects/products.db"; $pdo = new PDO ($dsn, null, null); $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION); $obj = ShopProduct::getInstance(1, $pdo);

Подобные методы работают как "фабрики", поскольку они берут "сырые" материалы (например, данные, полученные из строки базы данных или файла конфигурации) и используют их для создания объектов.

Термин "фабрика" относится к коду, предназначенному для создания экземпляров объектов. С примерами подобных "фабрик" мы еще встретимся с вами дальше.

Постоянные свойства

Некоторые свойства не должны изменяться. Например, такие элементы, как коды ошибок или коды состояния программы, задаются обычно вручную в классах. Хотя они должны быть общедоступными и статическими, клиентский код не должен иметь возможность изменять их.

Для этого можно определить постоянные свойства внутри класса. Как и глобальные константы, константы класса нельзя изменять после того, как они были определены. Постоянное свойство объявляют с помощью ключевого слова const .

В отличие от обычных свойств, перед именем постоянного свойства не ставится знак доллара. По принятому соглашению им часто назначают имена, состоящие только из прописных букв, как в следующем примере:

Class ShopProduct { const AVAILABLE = 0; const OUT_OF_STOCK = 1; // ...

Постоянные свойства могут содержать только значения, относящиеся к элементарному типу. Константе нельзя присвоить объект.

Как и к статическим свойствам, доступ к постоянным свойствам осуществляется через класс, а не через экземпляр объекта. Подобно тому как константа определяется без знака доллара, при обращении к ней также не требуется использовать никакой символ впереди.

Print ShopProduct::AVAILABLE;

Попытка присвоить константе значение после того, как она была объявлена, приведет к ошибке на этапе синтаксического анализа..

Константы следует использовать, когда свойство должно быть доступным для всех экземпляров класса и когда значение свойства должно быть фиксированным и неизменным.

На этом данную статью я завершаю, а в следующей речь пойдет про .

Понравился материал и хотите отблагодарить?
Просто поделитесь с друзьями и коллегами!

Не секрет, что на собеседованиях любят задавать каверзные вопросы. Не всегда адекватные, не всегда имеющие отношение к реальности, но факт остается фактом - задают. Конечно, вопрос вопросу рознь, и иногда вопрос, на первый взгляд кажущийся вам дурацким, на самом деле направлен на проверку того, насколько хорошо вы знаете язык, на котором пишете.

Попробуем разобрать «по косточкам» один из таких вопросов - что значит слово «static» в PHP и зачем оно применяется?

Ключевое слово static имеет в PHP три различных значения. Разберем их в хронологическом порядке, как они появлялись в языке.

Значение первое - статическая локальная переменная

function foo() { $a = 0; echo $a; $a = $a + 1; } foo(); // 0 foo(); // 0 foo(); // 0

В PHP переменные локальны. Это значит, что переменная, определенная и получившая значение внутри функции (метода), существует только во время выполнения этой функции (метода). При выходе из метода локальная переменная уничтожается, а при повторном входе - создается заново. В коде выше такой локальной переменной является переменная $a - она существует только внутри функции foo() и каждый раз при вызове этой функции создается заново. Инкремент переменной в этом коде бессмысленен, поскольку на следующей же строчке кода функция закончит свою работу и значение переменной будет потеряно. Сколько бы раз мы не вызвали функцию foo(), она всегда будет выводить 0…

Однако всё меняется, если мы перед присваиванием поставим ключевое слово static:

Function foo() { static $a = 0; echo $a; $a = $a + 1; } foo(); // 0 foo(); // 1 foo(); // 2

Ключевое слово static, написанное перед присваиванием значения локальной переменной, приводит к следующим эффектам:

1. Присваивание выполняется только один раз, при первом вызове функции
2. Значение помеченной таким образом переменной сохраняется после окончания работы функции
3. При последующих вызовах функции вместо присваивания переменная получает сохраненное ранее значение

Такое использование слова static называется статическая локальная переменная .

Подводные камни статических переменных

Разумеется, как всегда в PHP, не обходится без «подводных камней».

Камень первый - статической переменной присваивать можно только константы или константные выражения. Вот такой код:
static $a = bar();
с неизбежностью приведет к ошибке парсера. К счастью, начиная с версии 5.6 стало допустимым присвоение не только констант, но и константных выражений (например - «1+2» или ""), то есть таких выражений, которые не зависят от другого кода и могут быть вычислены на этапе компиляции

Камень второй - методы существуют в единственном экземпляре.
Тут всё чуть сложнее. Для понимания сути приведу код:
class A { public function foo() { static $x = 0; echo ++$x; } } $a1 = new A; $a2 = new A; $a1->foo(); // 1 $a2->foo(); // 2 $a1->foo(); // 3 $a2->foo(); // 4
Вопреки интуитивному ожиданию «разные объекты - разные методы» мы наглядно видим на этом примере, что динамические методы в PHP «не размножаются». Даже если у нас будет сто объектов этого класса, метод будет существовать лишь в одном экземпляре, просто при каждом вызове в него будет пробрасываться разный $this.

Такое поведение может быть неожиданным для неподготовленного к нему разработчика и послужить источником ошибок. Нужно заметить, что наследование класса (и метода) приводит к тому, что всё-таки создается новый метод:

Class A { public function foo() { static $x = 0; echo ++$x; } } class B extends A { } $a1 = new A; $b1 = new B; $a1->foo(); // 1 $b1->foo(); // 1 $a1->foo(); // 2 $b1->foo(); // 2

Вывод: динамические методы в PHP существуют в контексте классов, а не объектов. И только лишь в рантайме происходит подстановка "$this = текущий_объект"

Значение второе - статические свойства и методы классов

В объектной модели PHP существует возможность задавать свойства и методы не только для объектов - экземпляров класса, но и для класса в целом. Для этого тоже служит ключевое слово static:

Class A { public static $x = "foo"; public static function test() { return 42; } } echo A::$x; // "foo" echo A::test(); // 42
Для доступа к таким свойствам и методам используются конструкции с двойным двоеточием («Paamayim Nekudotayim»), такие как ИМЯ_КЛАССА::$имяПеременной и ИМЯ_КЛАССА:: имяМетода().

Само собой разумеется, что у статических свойств и статических методов есть свои особенности и свои «подводные камни», которые нужно знать.

Особенность первая, банальная - нет $this. Собственно это проистекает из самого определения статического метода - поскольку он связан с классом, а не объектом, в нём недоступна псевдопеременная $this, указывающая в динамических методах на текущий объект. Что совершенно логично.

Однако, нужно знать, что в отличие от других языков, PHP не определяет ситуацию «в статическом методе написано $this» на этапе парсинга или компиляции. Подобная ошибка может возникнуть только в рантайме, если вы попытаетесь выполнить код с $this внутри статического метода.

Код типа такого:
class A { public $id = 42; static public function foo() { echo $this->id; } }
не приведет ни к каким ошибкам, до тех пор, пока вы не попытаетесь использовать метод foo() неподобающим образом:
$a = new A; $a->foo(); (и сразу получите «Fatal error: Using $this when not in object context»)

Особенность вторая - static не аксиома!
class A { static public function foo() { echo 42; } } $a = new A; $a->foo();
Вот так, да. Статический метод, если он не содержит в коде $this, вполне можно вызывать в динамическом контексте, как метод объекта. Это не является ошибкой в PHP.

Обратное не совсем верно:
class A { public function foo() { echo 42; } } A::foo();
Динамический метод, не использующий $this, можно выполнять в статическом контексте. Однако вы получите предупреждение «Non-static method A::foo() should not be called statically» уровня E_STRICT. Тут решать вам - или строго следовать стандартам кода, или подавлять предупреждения. Первое, разумеется, предпочтительнее.

И кстати, всё написанное выше относится только к методам. Использование статического свойства через "->" невозможно и ведет к фатальной ошибке.

Значение третье, кажущееся самым сложным - позднее статическое связывание

Разработчики языка PHP не остановились на двух значениях ключевого слова «static» и в версии 5.3 добавили еще одну «фичу» языка, которая реализована тем же самым словом! Она называется «позднее статическое связывание» или LSB (Late Static Binding).

Понять суть LSB проще всего на несложных примерах:

Class Model { public static $table = "table"; public static function getTable() { return self::$table; } } echo Model::getTable(); // "table"
Ключевое слово self в PHP всегда значит «имя класса, где это слово написано». В данном случае self заменяется на класс Model, а self::$table - на Model::$table.
Такая языковая возможность называется «ранним статическим связыванием». Почему ранним? Потому что связывание self и конкретного имени класса происходит не в рантайме, а на более ранних этапах - парсинга и компиляции кода. Ну а «статическое» - потому что речь идет о статических свойствах и методах.

Немного изменим наш код:

Class Model { public static $table = "table"; public static function getTable() { return self::$table; } } class User extends Model { public static $table = "users"; } echo User::getTable(); // "table"

Теперь вы понимаете, почему PHP ведёт себя в этой ситуации неинтуитивно. self был связан с классом Model тогда, когда о классе User еще ничего не было известно, поэтому и указывает на Model.

Как быть?

Для решения этой дилеммы был придуман механизм связывания «позднего», на этапе рантайма. Работает он очень просто - достаточно вместо слова «self» написать «static» и связь будет установлена с тем классом, который вызывает данный код, а не с тем, где он написан:
class Model { public static $table = "table"; public static function getTable() { return static::$table; } } class User extends Model { public static $table = "users"; } echo User::getTable(); // "users"

Это и есть загадочное «позднее статическое связывание».

Нужно отметить, что для большего удобства в PHP кроме слова «static» есть еще специальная функция get_called_class(), которая сообщит вам - в контексте какого класса в данный момент работает ваш код.

Удачных собеседований!

Не секрет, что на собеседованиях любят задавать каверзные вопросы. Не всегда адекватные, не всегда имеющие отношение к реальности, но факт остается фактом - задают. Конечно, вопрос вопросу рознь, и иногда вопрос, на первый взгляд кажущийся вам дурацким, на самом деле направлен на проверку того, насколько хорошо вы знаете язык, на котором пишете.

Попробуем разобрать «по косточкам» один из таких вопросов - что значит слово «static» в PHP и зачем оно применяется?

Ключевое слово static имеет в PHP три различных значения. Разберем их в хронологическом порядке, как они появлялись в языке.

Значение первое - статическая локальная переменная

function foo() { $a = 0; echo $a; $a = $a + 1; } foo(); // 0 foo(); // 0 foo(); // 0

В PHP переменные локальны. Это значит, что переменная, определенная и получившая значение внутри функции (метода), существует только во время выполнения этой функции (метода). При выходе из метода локальная переменная уничтожается, а при повторном входе - создается заново. В коде выше такой локальной переменной является переменная $a - она существует только внутри функции foo() и каждый раз при вызове этой функции создается заново. Инкремент переменной в этом коде бессмысленен, поскольку на следующей же строчке кода функция закончит свою работу и значение переменной будет потеряно. Сколько бы раз мы не вызвали функцию foo(), она всегда будет выводить 0…

Однако всё меняется, если мы перед присваиванием поставим ключевое слово static:

Function foo() { static $a = 0; echo $a; $a = $a + 1; } foo(); // 0 foo(); // 1 foo(); // 2

Ключевое слово static, написанное перед присваиванием значения локальной переменной, приводит к следующим эффектам:

1. Присваивание выполняется только один раз, при первом вызове функции
2. Значение помеченной таким образом переменной сохраняется после окончания работы функции
3. При последующих вызовах функции вместо присваивания переменная получает сохраненное ранее значение

Такое использование слова static называется статическая локальная переменная .

Подводные камни статических переменных

Разумеется, как всегда в PHP, не обходится без «подводных камней».

Камень первый - статической переменной присваивать можно только константы или константные выражения. Вот такой код:
static $a = bar();
с неизбежностью приведет к ошибке парсера. К счастью, начиная с версии 5.6 стало допустимым присвоение не только констант, но и константных выражений (например - «1+2» или ""), то есть таких выражений, которые не зависят от другого кода и могут быть вычислены на этапе компиляции

Камень второй - методы существуют в единственном экземпляре.
Тут всё чуть сложнее. Для понимания сути приведу код:
class A { public function foo() { static $x = 0; echo ++$x; } } $a1 = new A; $a2 = new A; $a1->foo(); // 1 $a2->foo(); // 2 $a1->foo(); // 3 $a2->foo(); // 4
Вопреки интуитивному ожиданию «разные объекты - разные методы» мы наглядно видим на этом примере, что динамические методы в PHP «не размножаются». Даже если у нас будет сто объектов этого класса, метод будет существовать лишь в одном экземпляре, просто при каждом вызове в него будет пробрасываться разный $this.

Такое поведение может быть неожиданным для неподготовленного к нему разработчика и послужить источником ошибок. Нужно заметить, что наследование класса (и метода) приводит к тому, что всё-таки создается новый метод:

Class A { public function foo() { static $x = 0; echo ++$x; } } class B extends A { } $a1 = new A; $b1 = new B; $a1->foo(); // 1 $b1->foo(); // 1 $a1->foo(); // 2 $b1->foo(); // 2

Вывод: динамические методы в PHP существуют в контексте классов, а не объектов. И только лишь в рантайме происходит подстановка "$this = текущий_объект"

Значение второе - статические свойства и методы классов

В объектной модели PHP существует возможность задавать свойства и методы не только для объектов - экземпляров класса, но и для класса в целом. Для этого тоже служит ключевое слово static:

Class A { public static $x = "foo"; public static function test() { return 42; } } echo A::$x; // "foo" echo A::test(); // 42
Для доступа к таким свойствам и методам используются конструкции с двойным двоеточием («Paamayim Nekudotayim»), такие как ИМЯ_КЛАССА::$имяПеременной и ИМЯ_КЛАССА:: имяМетода().

Само собой разумеется, что у статических свойств и статических методов есть свои особенности и свои «подводные камни», которые нужно знать.

Особенность первая, банальная - нет $this. Собственно это проистекает из самого определения статического метода - поскольку он связан с классом, а не объектом, в нём недоступна псевдопеременная $this, указывающая в динамических методах на текущий объект. Что совершенно логично.

Однако, нужно знать, что в отличие от других языков, PHP не определяет ситуацию «в статическом методе написано $this» на этапе парсинга или компиляции. Подобная ошибка может возникнуть только в рантайме, если вы попытаетесь выполнить код с $this внутри статического метода.

Код типа такого:
class A { public $id = 42; static public function foo() { echo $this->id; } }
не приведет ни к каким ошибкам, до тех пор, пока вы не попытаетесь использовать метод foo() неподобающим образом:
$a = new A; $a->foo(); (и сразу получите «Fatal error: Using $this when not in object context»)

Особенность вторая - static не аксиома!
class A { static public function foo() { echo 42; } } $a = new A; $a->foo();
Вот так, да. Статический метод, если он не содержит в коде $this, вполне можно вызывать в динамическом контексте, как метод объекта. Это не является ошибкой в PHP.

Обратное не совсем верно:
class A { public function foo() { echo 42; } } A::foo();
Динамический метод, не использующий $this, можно выполнять в статическом контексте. Однако вы получите предупреждение «Non-static method A::foo() should not be called statically» уровня E_STRICT. Тут решать вам - или строго следовать стандартам кода, или подавлять предупреждения. Первое, разумеется, предпочтительнее.

И кстати, всё написанное выше относится только к методам. Использование статического свойства через "->" невозможно и ведет к фатальной ошибке.

Значение третье, кажущееся самым сложным - позднее статическое связывание

Разработчики языка PHP не остановились на двух значениях ключевого слова «static» и в версии 5.3 добавили еще одну «фичу» языка, которая реализована тем же самым словом! Она называется «позднее статическое связывание» или LSB (Late Static Binding).

Понять суть LSB проще всего на несложных примерах:

Class Model { public static $table = "table"; public static function getTable() { return self::$table; } } echo Model::getTable(); // "table"
Ключевое слово self в PHP всегда значит «имя класса, где это слово написано». В данном случае self заменяется на класс Model, а self::$table - на Model::$table.
Такая языковая возможность называется «ранним статическим связыванием». Почему ранним? Потому что связывание self и конкретного имени класса происходит не в рантайме, а на более ранних этапах - парсинга и компиляции кода. Ну а «статическое» - потому что речь идет о статических свойствах и методах.

Немного изменим наш код:

Class Model { public static $table = "table"; public static function getTable() { return self::$table; } } class User extends Model { public static $table = "users"; } echo User::getTable(); // "table"

Теперь вы понимаете, почему PHP ведёт себя в этой ситуации неинтуитивно. self был связан с классом Model тогда, когда о классе User еще ничего не было известно, поэтому и указывает на Model.

Как быть?

Для решения этой дилеммы был придуман механизм связывания «позднего», на этапе рантайма. Работает он очень просто - достаточно вместо слова «self» написать «static» и связь будет установлена с тем классом, который вызывает данный код, а не с тем, где он написан:
class Model { public static $table = "table"; public static function getTable() { return static::$table; } } class User extends Model { public static $table = "users"; } echo User::getTable(); // "users"

Это и есть загадочное «позднее статическое связывание».

Нужно отметить, что для большего удобства в PHP кроме слова «static» есть еще специальная функция get_called_class(), которая сообщит вам - в контексте какого класса в данный момент работает ваш код.

Удачных собеседований!

Давно хотел написать на эту тему. Первым толчком послужила статья Miško Hevery "Static Methods are Death to Testability ". Я написал ответную статью, но так и не опубликовал ее. А вот недавно увидел нечто, что можно назвать «Классо-Ориентированное Программирование». Это освежило мой интерес к теме и вот результат.

«Классо-Ориентированое Программирование» - это когда используются классы, состоящие только из статических методов и свойств, а экземпляр класса никогда не создается. В этой статье я буду говорить о том, что:

• это не дает никаких преимуществ по сравнению с процедурным программированием
• не стоит отказываться от объектов
• наличие статических членов класса!= смерть тестам

Хотя эта статья про PHP, концепции применимы и к другим языкам.

Зависимости

Обычно, код зависит от другого кода. Например:

$foo = substr($bar, 42);
Этот код зависит от переменной $bar и функции substr . $bar - это просто локальная переменная, определенная немного выше в этом же файле и в той же области видимости. substr - это функция ядра PHP. Здесь все просто.

Теперь, такой пример:

Class BloomFilter { ... public function __construct($m, $k) { ... } public static function getK($m, $n) { return ceil(($m / $n) * log(2)); } ... }
Эта маленькая вспомогательная функция просто предоставляет обертку для конкретного алгоритма, который помогает рассчитать хорошее число для аргумета $k , используемого в конструкторе. Т.к. она должна быть вызвана до создания экземпляра класса, она должна быть статичной. Этот алгоритм не имеет внешних зависимостей и вряд ли будет заменен. Он используется так:

$m = 10000; $n = 2000; $b = new BloomFilter($m, BloomFilter::getK($m, $n));
Это не создает никаких дополнительных зависимостей. Класс зависит сам от себя.

Альтернативный конструктор. Хорошим примером является класс DateTime , встроенный в PHP. Его экземпляр можно создать двумя разными способами:

$date = new DateTime("2012-11-04"); $date = DateTime::createFromFormat("d-m-Y", "04-11-2012");
В обоих случая результатом будет экземпляр DateTime и в обоих случаях код привязан к классу DateTime так или иначе. Статический метод DateTime::createFromFormat - это альтернативный коструктор объекта, возвращающий тоже самое что и new DateTime , но используя дополнительную функциональность. Там, где можно написать new Class , можно написать и Class::method() . Никаких новых зависимостей при этом не возникает.

Остальные варианты использования статических методов влияют на связывание и могут образовывать неявные зависимости.

Слово об абстракции

Зачем вся эта возня с зависимостями? Возможность абстрагировать! С ростом Вашего продукта, растет его сложность. И абстракция - ключ к управлению сложностью.

Для примера, у Вас есть класс Application , который представляет Ваше приложение. Он общается с классом User , который является предствлением пользователя. Который получает данные от Database . Классу Database нужен DatabaseDriver . DatabaseDriver нужны параметры подключения. И так далее. Если просто вызвать Application::start() статически, который вызовет User::getData() статически, который вызовет БД статически и так далее, в надежде, что каждый слой разберется со своими зависимостями, можно получить ужасный бардак, если что-то пойдет не так. Невозможно угадать, будет ли работать вызов Application::start() , потому что совсем не очевидно, как себя поведут внутренние зависимости. Еще хуже то, что единственный способ влиять на поведение Application::start() - это изменять исходный код этого класса и код классов которые он вызызвает и код классов, которые вызызвают те классы… в доме который построил Джек.

Наиболее эффективный подход, при создании сложных приложений - это создание отдельных частей, на которые можно опираться в дальнейшем. Частей, о которых можно перестать думать, в которых можно быть уверенным. Например, при вызове статического Database::fetchAll(...) , нет никаких гарантий, что соединение с БД уже установлено или будет установлено.

Function (Database $database) { ... }
Если код внутри этой функции будет выполнен - это значит, что экземпляр Database был успешно передан, что значит, что экземпляр объекта Database был успешно создан. Если класс Database спроектирован верно, то можно быть уверенным, что наличие экземпляра этого класса означает возможность выполнять запросы к БД. Если экземпляра класса не будет, то тело функции не будет выполнено. Это значит, что функция не должна заботиться о состоянии БД, класс Database это сделает сам. Такой подход позволяет забыть о зависимостях и сконцентрироваться на решении задач.

Без возможности не думать о зависимостях и зависимостях этих зависимостей, практически невозможно написать хоть сколь-нибудь сложное приложение. Database может быть маленьким классом-оберткой или гигантским многослойным монстром с кучей зависимостей, он может начаться как маленькая обертка и мутировать в гигантского монстра со временем, Вы можете унаследовать класс Database и передать в функцию потомок, это все не важно для Вашей function (Database $database) , до тех пор пока, публичный интерфейс Database не изменяется. Если Ваши классы правильно отделены от остальных частей приложения с помощью внедрения зависимостей, Вы можете тестировать каждый из них, используя заглушки вместо их зависимостей. Когда Вы протестировали класс достаточно, чтобы убедиться, что он работает как надо, Вы можете выкинуть лишнее из головы, просто зная, что для работы с БД нужно использовать экземпляр Database .

Классо-ориентированное программирование - глупость. Учитесь использовать ООП.