Области видимости

#php

В каких случаях следует применять области видимости?
public static protected private
    

Ответы

Ответ 1

Области видимости помогают вам определить, что относится к "потрошкам" реализации,
а что нет. Публичная область видимости говорит всем остальным: смотрите, я предоставляю
вот этот функционал:

class RepositoryFactory 
{
    public function getRepository(string clazz)
    {
        ...
    }
}


Все методы, которые относятся к внутренностям проекта, должны быть private или protected
- это не защита от хокиров, это способ скрыть ненужное от тех, кто использует ваш класс

class RepositoryFactory
{
    private function checkClassExistence(string clazz) 
    {
        ...
    }
}


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

Разница между protected и private заключается лишь в том, что protected можно переопределить
в классе-наследнике, таким образом тот же RepositoryFactory может проводить какие-то
свои внутренние проверки прежде чем предпринимать какие-то действия - и эти проверки
могут быть расширены или сужены в классе-наследнике. Чтобы предоставить такую возможность
наследникам, метод объявляется как protected:

class RepositoryFactory
{
    protected function isValidRepositoryClazz(string clazz) 
    {
        ...
    }
}


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

Модификатор static не является модификатором области видимости и управляет контекстом,
в котором существует поле или метод. В обычном случае мы оперируем в контексте конкретного
экземпляра класса, в случае употребления static мы оперируем в контексте самого класса;
таким образом статические методы не имеют this и могут быть вызваны из любой части
программы, а статические переменные существуют только в единственном экземпляре во
всей программе (в отличие от полей экземпляра, привязанных к конкретному экземпляру).


Ответ 2

Мой ответ является небольшим дополнением к другим. Это всего лишь попытка провести
ассоциацию с объектами в реальном мире, на основе которого и было задумано ООП. Прошу
рассматривать повествование с учётом этой позиции.



Существует множество различных формальных объяснений, зачем нужно ограничивать самого
себя в доступе к тем или иным членам и методам класса, но вопросы об этой необходимости
с завидной регулярностью всплывают один за другим. Тогда, возможно, при объяснении
сути следует пойти иным путём.

Если предметом обсуждения является некий объект, то почему бы не представить ему
прототип, существующий в реальном мире. Пусть это будет автомобиль.

Область видимости "public"

Представьте, что на заводе вдруг решили сделать абсолютно все детали машины доступными
водителю без необходимости залезать далеко в недра механизма. Двигатель застучал? Только
руку протяни, да затяни какой-нибудь торчащий на виду болт, - все дела. Масло закончилось?
Лей прямо в салоне в какую-нибудь выглядывающую из бардачка трубку. Отвалился глушитель?
Зачем лезть под машину и что-то приваривать, когда можно просто прицепить шланг одним
концом к выходной трубе, а другой высунуть в форточку. Все болты, все гайки, пружины
и прочие детали, всё это торчит наружу, весело поблескивая на солнце или хмурясь вместе
с водителем в непогожий день.

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

Область видимости "private"

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

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

Область видимости "protected"

Однако часть работ по восстановлению и даже модернизации автомобиля, подкованные
мастера выполнить могут. Например, повесят дезодорант на лобовое стекло в салоне. Эта
маленькая специализирующая деталь существенно изменит настроение водителя к лучшему,
поскольку сделает управление автомобилем ещё более удобным и комфортным. Также специальной
правке могут подвергнуться и руки самого водителя, если они, по мнению техников, растут
совсем не из того места, что потребно при осуществлении безопасного дорожного движения.

Ключевое слово "static"

Однажды переиграв в компьютерные игры, юный водитель может вдруг решить, что он grand
thief auto и начать залезать в чужие автомобили, как если бы они были его. При этом
нарушителя не будет интересовать то, что документы оформлены на совсем иных людей.
Он просто пользуется машинами тогда, когда хочет. И если в реальной жизни такое поведение
может привести к серьёзным последствиям, в мире кода это вполне допустимый творцом
приём. А уж когда и чем ограничить поведение подопытного творец обычно решает не сильно
напрягаясь и за очередной чашкой свежемолотого кофе.


Ответ 3

В таких же, как и в других языках. public для морды объекта/класса, то есть то, что
доступно пользователям и наследникам, protected в случае, если не нужен доступ извне
объектов/класса, но необходимо иметь доступ в наследниках, private для всего остального.
static это члены на уровне класса, а не объекта, к примеру какие-либо вспомогательные
методы, поля, целые классы, объекты которых не требуется создавать и т.д. А вообще
это все в начальное литературе по ооп гораздо лучше расписано.