Статические члены класса. Не дай им загубить твой код

Отличная статья и отличный перевод. Заплюсовал.
Однако, некоторые утверждения кажутся мне странными.

это не дает никаких преимуществ по сравнению с процедурным программированием

Если несколько функций можно как-то сгруппировать по тематике, то я их группирую в один статический класс:

<?php
class My_Math {
	public static function fibonachi($n) {
		return ...;
	}
	public static function getK($m, $n) {
		return ceil(($m / $n) * log(2));
	}
}

Преимущества от этого следующие:

• Вместо одного огромного файла functions.php, функции раскиданы по нескольким файлам и их легко найти
• Работает autoload. Класс Math загрузится только тогда когда мне понадобится

Статические свойства никогда не должны быть доступны снаружи

Почему бы и нет?

<?php
class My_Date {
	// Пусть в моей системе будет только один справочник со списком месяцев
	public static $months = array('Январь', 'Февраль', ...);
	// Сделал бы его константой класса, но константы не могут быть массивами :(
}

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

Как насчёт этого?

<?php
class My_Pager {
	// Каждый экземпляр должен знать свой порядковый номер, что бы генерить уникальные ссылки
	protected $_num = 0;

	// Но как же его посчитать автоматически?
	// А вот как:
	protected static $_cntPagers = 0;

	public function __construct()
	{
		$this->_num = self::$_cntPagers++;
	}
}

Итог: статические члены классов, это неотъемлемый инструмент, которым надо уметь правильно пользоваться, не создавая лишних зависимостей.

Отличный материал! Наокнец-то кто-то про это написал!

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

Так и хочется сказать: «Садись, пять!»
Спасибо за отличный перевод интересной статьи!

Часто использую статику (в разумных пределах) в своих проектах, однако в своей статье, за пример её использования получил критику.

Но, критикующий так и не ответил на вопрос, чем плох код:

    static private  $userData = NULL;
 
    public function getById($uid) {
               if (self::$userData) return self::$userData;
               self::$userData = $this->locGetById($uid); 
               return self::$userData;
            }
 
    private function locGetById($uid) {
              // some code $retData = ...               
               return $retData;
            }

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

А может я в чем-то не прав?

Typofix:

Это может привести {в => к} проблемам.

Очень предвзятая статья. Никаких преимуществ, кроме личного мнения не продемонстрировано.

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

2. Мы обязаны производить подключение к БД, хотя оно может нам вовсе не понадобиться.

3. Любой нормальный код (со статическими методами или без) умеет генерировать исключения при обнаружении ошибок, например, отсутствии подключения к БД. Причем гораздо логичнее бросать их при использовании БД, а не в начале программы (получается вся программа должна знать о БД).

4. Способов реализации примера множество, например, статический конструктор при помощи autoload.

Вообще, в данном случае статический класс служит контекстом создаваемым абстракцией более высокого уровня для Foo.
Так как встроенных средств разделения слоев абстракции в PHP нет, то статические классы и глобальные переменные практически единственные НОРМАЛЬНЫЕ способы их реализации. И их использование это не ошибка программистов — это недостаток языка, который приходится покрывать костылями.

А пример в статье про плюсы подхода для абстракции легко решается созданием нескольких статических классов БД.

ИмяПриложения\БД1
ИмяПриложения\БД2

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

ООП — глупость. Учитесь использовать функциональное программирование.

Действительно, классо-ориентированное программирование практически идентично процедурному. Но конкретно в PHP это оправдано наличием автозагрузки классов (spl_autoload_register, __autoload).

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

А вот, например, в Пайтоне такой подход не имеет смысла, там лучше воспользоваться честным процедурно-ориентированным программированием и поместить функции в файл/модуль arr.py.

научите писать грамотный код на php!!!