По словам заморских коллег, статические методы не приветствуются в коде. Вопрос почему? Мне привели в пример пару статей, но я не совсем понял из содержания причину такой ненависти к паттерну Singleton и статическим методам в целом.
В статье автор намекает, что стоит придерживаться принципов S.O.L.I.D..

Изначально у меня возник вопрос по прчине нужды в классе Util, где я в данный момент имею методы, которы возможно было бы корректнее оформить, как приводится в пример на php.net

одно отличие, что у меня они статические и тем самым не используется конструктор и атрибуты класса.

Буду очень признателен за комментарии по данному вопросу.

Каких, например?

В PHP народ приходит, обычно, имея опыт программирования на других языках. Обычно - Java. Именно оттуда идут многие ООП-предпочтения и правила кодирования, применимость которых в PHP не настолько очевидна и выигрышна как в Java. 

В данном случае в пример была приведена  статья static considered harmful. Я изначально беседовал на эту тему на таком сайте, как SO. Как мне показалось, что люди знают о чём говорят и тем самым у меня возник данный вопрос. Чёткого ответа я там не получил.

Про первый пример (Static dependencies).

Ну и что? Если рассматривать вызов FileTool::recursiveDelete не как работу с классом FileTool, а как вызов  библиотечной функции FileTool::recursiveDelete, то картинка становится не такой криминальной как кажется автору. Никого не смущает наличие толпы маловразумительных функций в самом php? Названия функций, поименованных через двоеточие, imho, несколько более мнемоничны, чем некоторые стандартные.

Второе (Testing) снимается тем-же "взглядом" на статические конструкции. Некоторые вещи просто так сделаны, "не держите их подобным образом"   К тому-же есть Mock объекты, которые позволяют изменить даже статические реализации для тестирования.

Добавлено через 4 минуты и 8 секунд
Там, кстати, есть пример "фабрики" от `Daniel O'Connor`, в котором те-же возражения применены для нестаитческой реализации.

Довольно сильное утверждение в статье, про ущербность singleton'а, основанного на типичном статическом механизме.
Обычно, +- декоративные элементы, он выглядит как-то так

Понятно, что такая реализация напрочь исключает возможность использования наследника SingleTone_object без правки кода, иcпользующего его.
Значит ли то, что имеющийся, ущербный в этом смысле, шаблон использования singleTone, свидетельствует об ущербности статических методов как таковых? imho - нет, просто вы(и я   ) не умеете их готовить. Давайте использовать более гибкий шаблон singleTone.

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


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

Это сообщение отредактировал(а) ksnk - 7.10.2012, 10:16

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

Это как это? Приватных конструкторов в нашей реальности не бывает. Достаточно прогнать тест и убедится что по этому поводу думает php.


Добавлено через 13 минут и 48 секунд
Хотя нет, бывают...


А разве это существенно?

Имелось в виду, что конструктор Singleton шаблона обычно привытный. Тобишь

А, понял. "то такая "защита" для шаблона реализации синглтона? чтобы злые юзеры не вызвали его снаружи противуестественным образом? Хм... забавно, не знал 

Да. Для моего случая нужно, чтобы конструктор класса-наследника был публичным.

Впрочем, protected вместо public - более кошерно, конечно, и тоже работает.

Вроде более не менее понятно, почему Singleton не приветствуется. Тяжело тестировать. 

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

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