Блог

Я продолжаю видеть этот формат в последних кодах и даже здесь:

 class Class {
    function this() {}
}
  

вместо

 class Class {
    [public/private/protected] function this() {}
}
  

1. Разве не рекомендуется всегда
   укажите область действия функции?
2. Разве первый подход не является старым?
3. Как при первом подходе определяются private и protected функции?

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

Не рекомендуется ли всегда указывать область действия функции?

Вы должны определить область действия функции, если собираетесь использовать их как private или protected.

Разве первый подход не является старым?

Что такое старое и новое, если они все еще принимаются PHP.

Как при первом подходе определяются private и protected функции?

вы не можете при первом подходе использовать ключевые слова.

1. Да, вероятно.
2. Трудно количественно определить, насколько новым или старым является метод. Возможно, это было менее нежелательно в прошлом, когда классы были относительно новыми в PHP.
3. «Методы класса могут быть определены как public, private или protected. Методы, объявленные без какого-либо явного ключевого слова visibility, определяются как public.»

Стандарт кодирования PSR-2 явно требует, чтобы модификатор видимости использовался как для свойств, так и для методов.

Однако использование public не требуется, потому что PHP 5 и 7 обратно совместимы с версией 4, которая имела только общедоступную видимость для всего, так что это настройка по умолчанию.

Однако, если опустить это, возникнут вопросы — как это сделали вы. Люди очень хороши в обнаружении шаблонов и ошибок в шаблонах. Что бы вы подумали о фрагменте кода, который использует protected or private везде (потому что вы должны), но случайно опускает public . Это ошибка? Это было сделано намеренно? Какого рода секретное поведение должно быть вызвано этим? Или это все еще PHP4-код, который скрывает некоторые неприятные проблемы с совместимостью? Как разработчик, вы не хотите задавать эти вопросы, и вы не хотите искать ответы.

public необязательно, но PSR-2 решил потребовать этого. Придерживайтесь стандартной рекомендации.

Также обратите внимание, что было предложение отказаться от использования var модификатора свойств и полностью заменить его на public . В предложении также приведен анализ кода из 10 000 лучших пакетов на Packagist, в котором говорится, что 94% всех классов в этой кодовой базе используют public исключительно, остальные 6% классов, использующих var , происходят из четырех более крупных пакетов, которые, скорее всего, все еще пытаются быть совместимыми с PHP4, причем лидирует «Simpletest» (платформа модульного тестирования, ориентированная на PHP 4).

Такого статического анализа кода на предмет модификаторов видимости для методов, о которых я знаю, не существует, но тенденция отчетливо видна: избавиться от старых PHP4-измов.

1. Да, это так. Всегда рекомендуется указывать видимость функции / свойства.
2. Да, это так. Версия без модификаторов видимости существовала до PHP4. В PHP5 были введены модификаторы видимости. Из-за обратной совместимости с устаревшим кодом версия без модификаторов видимости по-прежнему принимается и обрабатывается так, как если бы существовал public модификатор видимости.
3. PHP4 ничего не знал о видимости, поэтому вы не можете определить private or protected члены с этим синтаксисом без модификаторов видимости.

PHP родился как (ленивый, типизированный как утка) язык сценариев, и люди все еще используют его таким образом. Большинство PHP-программистов не имеют представления о том, что такое ООП, я очень хорошо знаю эту проблему, потому что я начинал с PHP, и это стоило мне большой работы позже. Около 90% PHP-кода, который вы видите, беспорядочный и устаревший с точки зрения объектной ориентации, удобочитаемости, инкапсуляции и т.д… По крайней мере, 50% — это чистое дерьмо. 🙁

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

Однако в PHP4 не было операторов области видимости, таких как private или protected. В то время вы обычно объявляли метод, добавляя один или несколько символов подчеркивания к имени метода, чтобы указать, что он не предназначен для вызова из внешних классов.

1. Да, это рекомендуется
2. Да, это так, с точки зрения ООП
3. Соглашения об именовании, которые, как мы надеемся, должны были быть поняты клиентами

Прежде всего, совместимость с PHP4.

Некоторые разработчики (вроде меня) опускают модификаторы доступности, потому что они имеют мало отношения к языкам сценариев. Настоящие языки ООП, такие как Python или Javascript, не имеют атрибутов private or protected и не нуждаются в этом. В PHP это немного по-другому, но не имеет смысла всегда применять этот синтаксический сахар. Я лично возьму за правило резервировать его для полезных приложений.

Многие PHP-программисты не знают об изначальной цели «инкапсуляции», поскольку она неприменима к некомпилированному коду за пределами видимости логики. На самом деле это добавляет немного больше хрупкости в PHP, поскольку выдает ошибки во время выполнения, а не во время компиляции (как в C ).
И я не могу удержаться, чтобы не сказать это снова: многие программисты также применяют это исключительно как культовую идиому программирования для имитации Java-подобного синтаксиса (чтобы восполнить воспринимаемый PHPs / прошлый недостаток конструкций ООП).