Если речь идет о PHP, то какой смысл использовать классы в качестве неймспейсов, если можно просто положить обычную функцию в неймспейс? Что за мода всюду пихать классы? Объекты нужны для связи данных и методов, которые их обрабатывают. Если метод чистый, то это обычная фукция и классы тут не нужны. Каждой задаче — свой инструмент!
Ветка про использование функций в неймспейсах, и код про использование функции вы назвали извращением и на фразу «так не делают потому что не знают» вы ответили «слава богу, говнокода итак хватает». Вывод сам собой пришел.
статические классы это пережиток прошлого.
в java использование статических классов оправдано т.к. нельзя объявлять функции вне класса.
в php это не нужно т.к. добавили неймспейсы.
для любителей автолоада тоже есть выход
`
final class my_function1 {
static function run($a) {
return "а я люблю собирать функции в классы ";
}
}
final class my_function2 {
static function run($a) {
return " и обмазыватся автолоадом";
}
}
echo my_function1::run(). my_function2::run()
`
да еще для любителе попрятать "всякие приватные механики" будет радость
С каких это пор?
Метод __invoke будет вызван, когда Вы обращаетесь к объекту как к функции
Если Ваша "логика" верна, я бы не смог создать ф-цию test, а ниже класс test!
namespace {
use LongLongNamespace\Math as Math;
echo Math\Sum(1, 2);
echo Math\Sum(1, 2);
}
вот и закончилась приватная математика Cannot redeclare LongLongNamespace\Math\PrivateSum()
а что если мне после рефакторинга нужно вынести этот 1 метод в другой класс? тогда мне будет не доступен больше тот приватный метод.
оформить в виде функции и не трахать людям мозг — это же так просто
// Довольно обидно, что в read-only нельзя минусить
Речь идёт про сокрытие функций внутри функции. Вопрос был поставлен, как обеспечить приватную логику, а я уточнил, что как быть, если эта приватная логика нужна в нескольких публичных методах. Твой комментарий не уместен.
Нет-нет. Я веду мысль к тому, что как только появляется приватная логика, то реализация на функциях начинает сливать. А если появляется необходимость вынести часть общей логики в приватную часть — то вообще не подходит.
Скажем, мы берём методы sum и sub (сложить и вычесть), но хотим складывать в какой-то важной уберфункции, которая параллельно будет что-то и логировать. Такой функцией может стать, например, приватная функция sumInternal с аргументами $a, $b, $operation (плюс, минус, умножение, etc.), а функции sum и sub будут просто вызывать её с правильными аргументами. С функциями так не выйдет, а вот с классом — без проблем.
Да, и не забывай про возможность переопределять статичные методы. Ведь этой возможности нет у функций.
Все нормальные IDE разрабатываются под нормальный код и весь нормальный код нормально поддерживается нормальными IDE.
Если код не может пройти статический анализ, это верный признак говнокодного говнокодища.
Это не тот кейс, который обсуждается в статье. В статье речь идет о чистой функции — функции, которая не зависит от окружения. Зависимость от приватных полей класса — это тоже зависимость и для этого нужно использовать классы, тут я с вами согласен. Но для примера из статьи — нет.
просто они пишут для устаревших версий PHP где нет namespace
а все потому что годами пилили в стиле ООП фреймворк. а за это время PHP развился
а кода много переписать не реально (Yii, Symphony и подобные треш)
Большое количество статики за пределами utils — не слишком хороший признак как мне кажется, особенно если эта статика не является creator\фабричным методом и тем более — мутирует состояние передаваемых аргументов.
А для алгоритмов более актуальным было бы применение стратегии на мой взгляд.
Когда использовать статические методы