Почему общественное частное лицо так важно?

Люди продолжают говорить мне, что перед всеми свойствами и методами класса я должен использовать модификаторы public, private или protected access. Я действительно не понимаю, почему. Я новичок, так что медведь со мной, но, как я вижу, это так:

Я единственный, кто будет работать над моим кодом. Не команда.
Я уже знаю, что все значит, плюс использование редактора, который сообщает мне все объявленные vars и свойства, я знаю, что не буду наступать на мои используемые переменные.

Одно из объяснений, которое я получаю, это то, что он "защищает или скрывает" ваш код от людей, которые могли его видеть..... но в PHP нет способа, которым я знаю, чтобы пользователь мог видеть ваш код в первом где я его скрываю? Если они МОГУТ видеть мой код, то они либо хакер, либо они находятся в моей учетной записи, поэтому я не могу их остановить.

Я могу понять, работал ли я с огромным кодом в команде, но для небольших вещей это кажется ненужным.

Ответ 1

Ты не "скрываешь" свой код от кого-то, этот вздор.

Какие свойства protected и private делают, это сказать PHP, как вы собираетесь их использовать. Когда вы создаете класс, вы обычно должны иметь представление о том, как вы хотите, чтобы этот класс использовался. У вас будут public части, с которыми может взаимодействовать другой код, и другие части, к которым вы не хотите напрямую обращаться к другому коду. Как правило, вы хотите ограничить части public класса небольшим набором хорошо определенных методов, которые не будут меняться. Потому что, как только вы используете их в других частях вашего кода, их изменение становится болью. Все элементы private и protected должны быть доступны только внутри самого класса, поэтому его изменение будет меньше проблемой позже.

Если вы единственный, кто работает над кодом, вы можете сказать это так же просто, как просто не использовать "частные части". Но вы собираетесь делать ошибки, и вы забудете, какая часть принадлежит, когда со временем. Маркировка этих свойств явно как protected или private позволяет PHP не нарушать ваши собственные "условия использования". Это разница между ментальной нотой "не трогайте это" и фактически помещая что-то в замок.

Ответ 2

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

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

Обратите внимание, что для того, чтобы это было полезно вообще, вы не можете просто иметь тривиальные сеттеры для всего, как public function setX($x) { $this->x = $x; } - который побеждает всю цель. Ваш объект должен быть таким же "черным ящиком", как вы можете это сделать, и это частично означает, что внешний код должен иметь возможность видеть и изменять как можно меньше его внутреннего состояния. Пусть класс управляет своим собственным состоянием и имеет методы, которые берут другой материал, необходимый им для выполнения своей работы. (Полупрозрачное исключение здесь было бы типом, основной целью которого было бы перебросить данные вокруг, но даже там вы должны ограничивать доступ ко всему, что не относится к этим данным, и сеттеры для таких данных в идеале могли бы его проверить и т.д.)

Ответ 3

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

Итак, для вашей конкретной ситуации на данный момент я бы сказал, что все, что вы делаете в данный момент, скрывает это от вашего будущего я, так что вы не будете похожи на "Хм... Я сделал этот класс для одного из моих проектов 2 лет назад, и я буду использовать его сейчас", а затем попытаться объединиться с внутренними элементами таким образом, чтобы они не были запутаны, что может вызвать проблемы по причине, о которой вы, возможно, не сможете вспомнить.

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

Ответ 4

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

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

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