Я новичок в ООП / PHP.Какова практичность видимости и расширяемости в классах?

Question

Я явно новичок в этих понятиях. Я просто не понимаю, почему вы ограничиваете доступ к свойствам или методам. Кажется, вы просто написали бы код в соответствии с намеченными результатами. Зачем вам создавать приватный метод вместо того, чтобы просто не вызывать этот метод? Это для итеративного создания объекта (если я правильно это заявляю), ситуации с несколькими разработчиками (не путайте работу других людей), или просто чтобы вы случайно не испортили свою собственную работу?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

Все сводится к инкапсуляции. Это означает скрывать внутреннюю часть класса и просто заботиться о том, что он делает. Если вы хотите иметь класс обработки кредитной карты, вам не важно, как он обрабатывает кредитную карту. Вы просто хотите иметь возможность: $creditCardProcessor->charge(10.99, $creditCardNumber); и ожидать, что это сработает.

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

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

Другая сторона класса это его интерфейс . Интерфейс - это открытые методы, которые разработчик класса намеревался вызывать из внешнего кода. Это означает, что вы должны иметь возможность вызывать любой публичный метод, и он будет работать правильно.

Answer 4

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

Сокрытие данных облегчает концептуализацию и реализацию программы.

Answer 5

Все дело в инкапсуляции. Методы являются частными, которые выполняют внутреннюю работу, демонстрируя изящные функции, которые облегчают работу. Например. у вас может быть функция $ product-> insert (), которая использует 4 внутренние функции для проверки одноэлементного объекта БД, обеспечения безопасности запроса и т. д. другие структуры или потоки, которые вы, разработчик, создали.

Answer 6

ситуация с несколькими разработчиками (не испортить чужую работу) или просто так что ты не испортишь свою собственную работу случайно?

В основном это две вещи. Обнародование метода гласит: «Это то, как класс должен использоваться его клиентами», а гласность говорит, что «это деталь реализации, которая может измениться без предупреждения и о которой клиенты не должны заботиться» И заставляет клиентов следовать этому совет.

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

Answer 7

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

Он не должен быть настолько строгим, чтобы различать частное / публичное / что угодно (я имею в виду применение языка). Например, в Python это достигается соглашением об именах. Вы знаете, что не следует связываться с чем-либо, помеченным как не публичное.

Answer 8

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

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