Pull to refresh

Comments 44

Если речь идет о PHP, то какой смысл использовать классы в качестве неймспейсов, если можно просто положить обычную функцию в неймспейс? Что за мода всюду пихать классы? Объекты нужны для связи данных и методов, которые их обрабатывают. Если метод чистый, то это обычная фукция и классы тут не нужны. Каждой задаче — свой инструмент!

Потому-то для функций не сделали автолоадера.
UFO just landed and posted this here
UFO just landed and posted this here
Видимо, использование классов вместо неймспейсов считается меньшим злом, чем приведённый вами извращения )
Да нет, просто большинство просто не знают что так можно делать :)
слава бгу и так говнокода полно
Использовать функции — говнокод? Странное заявление как минимум, от человека, который ежедневно использует функции.
В каком месте я утверждал, что использование фукнции — говнокод?
Ветка про использование функций в неймспейсах, и код про использование функции вы назвали извращением и на фразу «так не делают потому что не знают» вы ответили «слава богу, говнокода итак хватает». Вывод сам собой пришел.
А подветка про то, как извратиться, чтобы не использовать статические классы.
статические классы это пережиток прошлого.
в 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(), тогда получится просто echo my_function1(). Хотя тоже очень на любителя…
всегда думал что это работает только для объектов а не для классов
и вправда не работает — так бы давно заиспользовал

Warning: The magic method __invoke() must have public visibility and cannot be static in [...][...] on line 4

Fatal error: Uncaught Error: Call to undefined function my_function1() in [...][...]:9
Stack trace:
0 {main}
thrown in [...][...] on line 9

Не нужно метод декларировать статическим — будет работать :)
С каких это пор?
Метод __invoke будет вызван, когда Вы обращаетесь к объекту как к функции
Если Ваша "логика" верна, я бы не смог создать ф-цию test, а ниже класс test!

Для функций не нужен автолоад. Просто прописываем в composer.json:
"autoload": {
    "files": ["src/functions.php"],
}

а дальше opcache просто закэширует это дело.
В классе могут содержаться всякие приватные механики, которые не светят наружу в автокомплите IDE;
UFO just landed and posted this here
namespace {
use LongLongNamespace\Math as Math;
echo Math\Sum(1, 2);
echo Math\Sum(1, 2);
}
вот и закончилась приватная математика Cannot redeclare LongLongNamespace\Math\PrivateSum()
Ну там ещё можно попытаться использовать вариант с присвоением функции переменной:
$privateSum = function() {
    // магия здесь
}

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

// Довольно обидно, что в read-only нельзя минусить
Речь идёт про сокрытие функций внутри функции. Вопрос был поставлен, как обеспечить приватную логику, а я уточнил, что как быть, если эта приватная логика нужна в нескольких публичных методах. Твой комментарий не уместен.
ты гониш — прочитай свой комент сначала

А если этот приватный метод потребуется в нескольких публичных

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

Скажем, мы берём методы sum и sub (сложить и вычесть), но хотим складывать в какой-то важной уберфункции, которая параллельно будет что-то и логировать. Такой функцией может стать, например, приватная функция sumInternal с аргументами $a, $b, $operation (плюс, минус, умножение, etc.), а функции sum и sub будут просто вызывать её с правильными аргументами. С функциями так не выйдет, а вот с классом — без проблем.

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

и смысл прятания в чем? только в эмуляции области видимости?

  • вот у нас функция sumInternal она работает с такими аргументами
  • вот функции sum и sub более высокого уровня — которые используют функцию sumInternal

и если все три функции видны и находятся в своем неймпейсе — ничего страшного нет.
Хорошо. Мне лень продолжать спор.
Лень? Тут либо приведите аргумент, либо обосритесь.
те. автокомплит IDE задает правила написания кода теперь? пишетм код не для решения задачи — а чтобы в IDE красиво и удобно было — просто офигенно.

Все нормальные IDE разрабатываются под нормальный код и весь нормальный код нормально поддерживается нормальными IDE.
Если код не может пройти статический анализ, это верный признак говнокодного говнокодища.
Это не тот кейс, который обсуждается в статье. В статье речь идет о чистой функции — функции, которая не зависит от окружения. Зависимость от приватных полей класса — это тоже зависимость и для этого нужно использовать классы, тут я с вами согласен. Но для примера из статьи — нет.
просто они пишут для устаревших версий PHP где нет namespace
а все потому что годами пилили в стиле ООП фреймворк. а за это время PHP развился
а кода много переписать не реально (Yii, Symphony и подобные треш)
Я для себя сформировал такое правило — если функция чистая (https://ru.wikipedia.org/wiki/%D0%A7%D0%B8%D1%81%D1%82%D0%BE%D1%82%D0%B0_%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D0%B8) — то её можно делать статической. Правда даже в этом случае есть проблемы — тяжело уследить когда метод перестал быть чистым и пора отрефакторить его и его использование
Большое количество статики за пределами utils — не слишком хороший признак как мне кажется, особенно если эта статика не является creator\фабричным методом и тем более — мутирует состояние передаваемых аргументов.
А для алгоритмов более актуальным было бы применение стратегии на мой взгляд.
Наличие utils — не слишком хороший признак сам по себе :-)
UFO just landed and posted this here
UFO just landed and posted this here
Мне кажеться логичным использование статического метода, который возвращает имя таблицы в классе, реализующем интерфейс ActiveRecord.
UFO just landed and posted this here
в интерфейсе ActiveRecord объявлю метод tableName() и наследуемый клас его реализует:
public static function tableName()
{
     return 'my_table_name';
}
UFO just landed and posted this here
Sign up to leave a comment.

Articles