Рассуждение за защищенными переменными PHP5

Question

Можете ли вы объяснить причину, по которой я хотел бы использовать «защищенный» или «открытый» для некоторых переменных класса и методов в PHP5? Я только что нашел случай, когда я думал, что мне нужно «защищено», и выбрал «публичный» или «частный» в зависимости от намерения. Даже работая в командах, мне все еще не удалось найти случай (исходя из моих сегодняшних знаний) того, почему «защищенный» необходим для переменных и методов класса.

Answer 1

Например, класс fDate библиотеки Flourish предоставляет множество функций, но не все, что мне нужно.Поэтому я расширил свой собственный класс.

Вскоре я обнаружил, что его основная внутренняя переменная, fDate :: $ date (время в секундах с 1970 года), была приватным свойством.Это сделало невозможным для меня доступ к нему в моем подклассе ThriveDate.Как только сопровождающий Flourish изменил его на свойство protected, я смог его использовать и, таким образом, адекватно расширить fDate.

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

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

Answer 2

А как на примере реальной жизни:

<?
// burguers.php

/* abstract */ class BurguerClass {
  // nobody knows about these secret function
  private function addSecretRecipeSauce() { ... }  

  // these one can can change in subclasses
  // cannot be called globally
  protected /* virtual */ function addBread() { ... }  
  protected /* virtual */ function addSalad() { ... }  
  protected /* virtual */ function addMeat() { ... }
  protected /* virtual */ function addExtraIngredients() { ... }

  // these one it can be access globally
  public /* virtual */ function makeBurguer() {
    $this->addBread();
    $this->addSalad();
    $this->addMeat();
    $this->addExtraIngredients();
    $this->addSecretRecipeSauce();
  }  
}

/* concrete */ class CheeseBurguerClass extends BurguerClass {
  protected /* virtual */ function addCheese() { ... }

  public /* override */ function makeBurguer() {
    $this->addBread();
    $this->addSalad();
    $this->addMeat();
    $this->addExtraIngredients();
    // we add this one:
    $this->addCheese();
  } 
}

/* concrete */ class RanchStyleBurguerClass extends BurguerClass {
  protected /* override */ function addExtraIngredients() { ... }
}

/* concrete */ class EastCoastVegetarianStyleBurguerClass extends BurguerClass {
  protected /* override */ function addMeat() {
    // use soy "meat"
  }
  protected /* override */ function addExtraIngredients() { ... }
}

function burguers_main() {
    $Cheesburguer = new CheeseBurguerClass();

    // can be access
    $Cheesburguer->makeBurguer();
}

// execute it
burguers_main();

?>

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

Вы говорите своим сотрудникам, как «addBread», «addSalad», «addMeat», «addExtraIngredients» и что операции могут быть изменены новыми, но не могут быть проданы отдельно, только могут использоваться в операции «makeBurguer» .

Но вы не обучаете своих сотрудников операции addSecretRecipe.

Answer 3

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

Это не является строго необходимым, вы также можете сделать каждое свойство public, но тогда вы потеряете все элементы управления, которые получают к нему доступ и / или изменяют его.Также другие могут запутаться, для чего нужны все эти «публичные свойства», к которым у них есть доступ.

С другой стороны, вы можете сделать каждое свойство private, но тогда и каждый подкласс не сможетполучить доступ к нему больше.

Answer 4

ООП не заканчивается организацией вашего кода в классы (так как структурированное программирование не заканчивается разделением кода на функции). PHP является языком сценариев, поэтому при использовании его в качестве языка ООП мы должны сами настроить ограничения.

Мне очень повезло, когда я впервые встретился с ООП, языком был Java, а книгой был Брюс Эксель - Мышление на Java (его можно купить в Amazon или других магазинах, также можно бесплатно скачать предыдущие выпуски здесь) : http://www.mindviewinc.com/Books/downloads.html). Я могу порекомендовать эту книгу даже для программистов на PHP. Если вы не начинающий, вы все поймете и примете его в PHP. Я пытаюсь программировать на PHP, как если бы это была Java (по крайней мере, часть ООП; в Java нет таких крутых ассоциативных массивов, как в PHP).

Кроме того, частные, защищенные и публичные категории не слишком точны. Public следует разделить на «метод API» и «можно вызывать из других классов» (см. «Дружественный»), защищенный должен различать «должен быть перезаписан» и «должен быть реализован».

Выучи ООП, оно того стоит.

Есть еще одна вещь, которую я хотел бы сказать, базовый шаблон ООП: используйте геттеры / сеттеры, не используйте публичные свойства, если вы используете публичные свойства, вы просто бросаете их, чтобы качать. Скажем, есть флаг состояния, теперь у него есть 2 возможных значения состояния, но если вы хотите расширить его, необходимо пересмотреть весь код, который его использует. Используйте setState () и getState (), первые функции которых просты ( $ this-> state = $ param; и return $ this-> state ), но не будет проблема с расширением значения состояния, тогда вам следует переписать только эти методы, даже в том случае, если состояние является производным значением (например, его значение вычисляется из большего количества флагов).

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

Итак, мои советы:

• используй ООП, это твой друг;
• использовать PHP как JAVA (строгий язык ООП), а не как в FORTRAN.

Answer 5

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

Answer 6

при разработке классов разве не нормально иметь частные и публичные переменные или свойства.

Да, мой опыт ООП очень ограничен, имея доступ к разработке ООП в CA-Visual Objects, Clipper, VB и ASP.

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

Конечно, в VB и ASP они были определены с помощью методов Get, Let и Set, но вы все равно можете получить к ним доступ напрямую.

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

Answer 7

Насколько я понимаю, частные методы и свойства не могут быть видны расширяющимся классам; тогда как Защищенные методы и свойства могут быть видны, но используются только тем классом, в котором они определены.

http://php.net/manual/en/language.oop5.visibility.php