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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

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

Главным образом эти две вещи. Создание общедоступного метода говорит "это то, как класс должен использоваться его клиентами", делая его конфиденциальным: "Это детализация, которая может измениться без предупреждения и какие клиенты не должны заботиться" И заставляет клиентов следовать этому совет.

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

Ответ 7

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

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

Ответ 8

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

Это то же самое с свойствами класса. Да, вы можете писать все-публичные классы, но в чем это удовольствие?