Перевод «protected» на русский
Одна из теорий утверждает, что это происходит из-за того, что женщины каким-то образом защищены от аутизма.
The judges themselves are also protected from any political interference.
Что касается самих судей, то они также защищены от любого политического вмешательства.
Foreign workers are also protected against racially-motivated termination of their employment contract.
Иностранные трудящиеся в равной степени защищены от произвольного расторжения трудового договора по мотивам расовой дискриминации.
Share Password protected files through public links with expiration date.
Предоставление файлов, защищенных паролем, по общедоступным ссылкам с датой истечения срока действия.
This suggests that people were still protected from Ebola 40 years later.
Это говорит о том, что люди и спустя 40 лет по-прежнему были защищены от Эболы.
Ironically, Freud was protected from asphyxia at birth.
Как ни странно, Фрейд был защищен от асфиксии при рождении.
The company says partners following Facebook «best practices» were automatically protected.
Компания заявляет, что партнеры, следующие за Facebook, «лучшие практики» были автоматически защищены.
The Cave and Basin wasn’t really protected.
Порт и береговой посёлок, по существу, не были серьёзно защищены.
Возможно неприемлемое содержание
Примеры предназначены только для помощи в переводе искомых слов и выражений в различных контекстах. Мы не выбираем и не утверждаем примеры, и они могут содержать неприемлемые слова или идеи. Пожалуйста, сообщайте нам о примерах, которые, на Ваш взгляд, необходимо исправить или удалить. Грубые или разговорные переводы обычно отмечены красным или оранжевым цветом.
Методы доступа. Наиболее популярные ситуации
Статья в первую очередь расчитана на начинающих разработчиков, либо для тех, кто только начинает переходить от процедурного стиля программирования к ООП, посему матерых гуру просьба не вгонять в минуса 🙂
Права доступа к свойствам и методам — это на первый взгляд всего лишь три слова: private, protected и public. Но что скрывается за ними? Какие преимущества это дает в разработке? И как их правильно использовать? Здесь, как и во всех других аспектах программирования, без практики не разобраться…
Одна из трех основных концепций ООП — наследование (другие две: инкапсуляция и полиморфизм). Вобщем-то именно для нее и были реализованы права доступов. Основанная идея наследования: Дочерний объект, при наследовании (extend) родителя перенимает себе все родительские методы и свойства, а так же может обзавестись своими собственными. Понимая эту базу, можно перейти в всему что находится ниже…
Private — объявляет метод или свойство доступным только в том классе в котором он присутствует. Тоесть к private методам и свойствам мы не можем обращаться ни из объектов, ни из дочерних классов.
Protected — объявляет метод или свойство защищенными. Тоесть такими, которые не могут быть доступны из объекта, реализующего класс, но вполне может быть использовано в дочерних классах.
Public — публичный. Классы и методы, объявленные public, могут быть доступны как внутри самого класса, так и в дочерних классах и в объектах, реализовавших класс.
Сразу хочу заметить, что при наследовании, методы доступа изменяться могут только к более лояльным. тоесть в следующей последовательности, но не обратно: private → protected → public
Так же методы могут быть final тоесть такими, которые невозможно переопределить в классах потомках.
Вобщем-то все методы доступа используются исключительно для самодокументации кода и не несут никакой логической составляющей, так что и без них жизнь только тяжела, но не невозможна, что доказывает РНР4, в котором все методы и свойства были публичными…
Практика
Иногда случаются ситуации, когда этих методов доступа недостаточно. Тоесть, например, мы можем хотеть иметь доступ из объекта на чтение какого-то свойства, но при этом не иметь возможности в него писать. Самое простое решение: объявить свойство public и добавить комментарий /* только для чтения */, но про комментарий можно ненароком забыть и испортить логику поведения программы, вклинившись с нестандартным значением посреди выполнения. тогда приходит время использовать геттеры (getter\’s). Геттер — не что иное, как метод класса, реализующий исключительную возможность читать не публичные свойства из объекта. Вот пример:
class A private $a = 7;//мы не можем читать и писать в это свойство из объекта, реализующего этот класс
public function getA() < //публичный метод будет доступен объекту для обращения
return $this->a; //внутри класса мы можем получать доступ к приватным свойствам
>
>
$obj = new A();
echo $obj->getA();//мы получили значение приватной переменной $a
Похожим способом ведут себя и сеттеры (setter\’s), когда нам необходимо иметь возможность установить значение переменной, но не читать ее напрямую, так как она, к примеру, должна быть преобразована прежде чем быть использованной. Пример метода сеттера:
//.
public funtion setA($value) < //метод будет доступен для объекта
$this->a = $value; //приватное свойство $a может быть установленное внутри класса, но не доступно для прямого влияния из объекта
>
//.
Еще одним вариантом реализации доступа к методам, когда метод должен быть отовсюду доступен только для чтения, является введение \«псевдо-свойства\»:
class A public function getValue() static $value;
if (empty($value)) $value = //. тут значение создается по каким-то известным параметрам и повлиять извне на него мы никак не сможем
>
в примере выше, класс А будет обладать псевдо-свойством $value. Псевдо — потому что оно реализуется исключительно через метод, а доступ к нему возможен только на чтение. Еще можете заметить что я использовал паттерн \«ленивой инициализации\», что бы отложить создание свойства до последнего момента и заодно как бы \«закешировать\» его. Где это можно применить, хорошо проиллюстрировано в соседнем топике об ООП в РНР.
Хорошей практикой является сокрытие всех свойств методом private и, в зависимости от нужд, создавать для них сеттеры или геттеры, но нужно быть внимательным, что если для свойства существует и сеттер и геттер, а дополнительной логики обработки данных нет, то не проще ли их убрать, а свойство сделать публичным? 🙂
Урок №157. Наследование и cпецификатор доступа protected
На предыдущих уроках мы говорили о том, как работает наследование в языке C++. Во всех наших примерах мы использовали открытое наследование.
На этом уроке мы рассмотрим детально этот тип наследования, а также два других типа: private и protected. Также поговорим о том, как эти типы наследований взаимодействуют со спецификаторами доступа для разрешения или ограничения доступа к членам.
Оглавление:
- Спецификатор доступа protected
- Когда следует использовать спецификатор доступа protected?
- Типы наследований. Доступ к членам
- Наследование типа public
- Наследование типа private
- Наследование типа protected
- Финальный пример
- Заключение
Спецификатор доступа protected
Мы уже рассматривали спецификаторы доступа private и public, которые определяют, кто может иметь доступ к членам класса. В качестве напоминания: доступ к public-членам открыт для всех, к private-членам доступ имеют только члены того же класса, в котором находится private-член. Это означает, что дочерние классы не могут напрямую обращаться к private-членам родительского класса!
class Parent
int m_private ; // доступ к этому члену есть только у других членов класса Parent и у дружественных классов/функций (но не у дочерних классов)
int m_public ; // доступ к этому члену открыт для всех объектов
Примечание: public = «открытый», private = «закрытый», protected = «защищенный».
В языке C++ есть третий спецификатор доступа, о котором мы еще не говорили, так как он полезен только в контексте наследования. Спецификатор доступа protected открывает доступ к членам класса дружественным и дочерним классам. Доступ к protected-члену вне тела класса закрыт.
class Parent
int m_public ; // доступ к этому члену открыт для всех объектов
int m_private ; // доступ к этому члену открыт только для других членов класса Parent и для дружественных классов/функций (но не для дочерних классов)
int m_protected ; // доступ к этому члену открыт для других членов класса Parent, дружественных классов/функций, дочерних классов
class Child : public Parent
m_public = 1 ; // разрешено: доступ к открытым членам родительского класса из дочернего класса
m_private = 2 ; // запрещено: доступ к закрытым членам родительского класса из дочернего класса
m_protected = 3 ; // разрешено: доступ к защищенным членам родительского класса из дочернего класса
Parent parent ;
parent . m_public = 1 ; // разрешено: доступ к открытым членам класса извне
parent . m_private = 2 ; // запрещено: доступ к закрытым членам класса извне
parent . m_protected = 3 ; // запрещено: доступ к защищенным членам класса извне
В примере, приведенном выше, вы можете видеть, что член m_protected класса Parent напрямую доступен дочернему классу Child, но доступ к нему для членов извне — закрыт.
Когда следует использовать спецификатор доступа protected?
К protected-членам родительского класса доступ открыт для членов дочернего класса, а это означает, что если вы позже измените что-либо в protected-члене (тип данных, значение и т.д.), то вам придется внести изменения как в родительский, так и во все дочерние классы. Поэтому использование спецификатора доступа protected наиболее полезно, когда вы будете наследовать только свои же классы и количество дочерних классов будет небольшое. Таким образом, если вы внесете изменения в реализацию родительского класса, и вам понадобится обновить все дочерние классы, то вы сможете сделать эти обновления сами и это не займет много времени (так как дочерних классов будет немного).
Создание private-членов предоставляет лучшую инкапсуляцию и изолирует родительские классы от изменений, вызванных дочерними классами. Но цена этому — дополнительное создание открытого или защищенного интерфейса (способа взаимодействия других объектов с классами и их членами, т.е. геттеры и сеттеры). Это дополнительная работа, которая не стоит того, если вы сами работаете со своими же классами (чужие классы не обращаются к вашему классу) и количество дочерних классов небольшое.
Типы наследований. Доступ к членам
Существует три типа наследований классов:
public;
private;
protected.
Для определения типа наследования нужно просто указать нужное ключевое слово возле наследуемого класса:
Что означает protected
Написание статьи о protected привело к написанию этой. Я понял для какого из случаев предназначены модификаторы доступа private , public и protected .
- private — Модификатор доступа, обозначющий, что программист будет использовать элементы класса только внутри непосредственно основного своего класса.
- public — Модификатор доступа, обозначающий, что программист будет использовать элементы класса либо в других частях программы, либо в других классах.
- protected — Модификатор доступа, обозначающий, что программист будет использовать элементы класса либо внутри непосредственно своего основного класса, либо непосредственно в своём потомке-классе.
Сейчас я попробую описать то же самое используя художественный стиль (может кому-то пригодиться).
Класс-наследник имеет поля и функции-члены базового класса, но не имеет права обращаться к собственным ( private ) полям и функциям базового класса. Вот и выходит так, что у основного класса есть такая часть, которую от сердца ему не оторвать: все наследники о ней знают, но использовать её не могут, так как родитель отказался передавать ту часть по наследству. Такая часть — это private .
Да вот мучает совесть родителя, не может родитель оставить детей без наследства, решает передать некоторую часть того, что у него есть, всем своим потомкам. Передаётся эта тайна от родителя к потомку, но скрыта она от всех посторонних и доступна исключительно детям собственным класса. Такая часть — это protected .
А чтобы не вспоминали родителя словом плохим, родитель передаёт еще часть наследства своим потомкам, и эта часть наследства озвучивается публично. Коли о наследстве озвучивается публично, то та часть, о которой озвучивается, может попасть не в руки потомков и использовать её сможет любой шарлатан. Такая часть — public .
Так вот обстоят дела с наследованием.
Иногда задают вопрос: » Если мы наследуем класс, наследуются ли приватные поля (члены)? . Ответ — да. Это легко проверить.
//Приватные поля наследуются clang Листинг #1
using namespace std ;
int a , b , c ; //По умолчанию private.
class B : public A //Применили наследование и на основе класса A создали класс B
class C //Независимый класс
cout < < sizeof ( A ) < < endl ; //Вывели на экран размер объекта от класса A
cout < < sizeof ( B ) < < endl ; //Вывели на экран размер объекта от класса B
cout < < sizeof ( C ) < < endl ; //Вывели на экран размер объекта от класса C
Посмотрим в код. С одной стороны у нас один класс с приватными переменными и два класса: один однозначно пустой, а второй неопределённого состояния: ни то пустой, ни то с наследством. Несложно догадаться, что пустой у нас класс C , а вот класс B в неопределённом для многих из нас, новичков, состоянии. Чтобы проверить, были ли унаследованы поля, можно сравнить размеры классов. Если класс B не унаследовал ничего, то размер его будет равен размеру пустого класса, а если унаследовал, то размер его будет равен размеру класса A .
В зависимости от системы результаты на экран могут быть вывдены разные, но в любом случае получится, что A == B, а размер C скорее всего будет сильно меньше (в моём случае А==12, B==12, C==1). Это обозначает однозначно, что поля потомок к себе получил. Несмотря на то, что использовать мы их не можем, они в потомке оказались. Вот мы и проверили, что приватные поля наследуются, висят в памяти. А ещё можем сделать вывод, что кроме пожирания памяти и не делают ничего, и использовать их нельзя. Одним словом — Паразиты.
- Приватные элементы наследуются. Хотя всё равно могут быть несогласные. Важно понимать, что под наследованием могут иметь в виду сам механизм наследования, а не получаемый от наследования эффект.
- Конструкторы и деструкторы не наследуются.
- Все перегруженные операции наследуются.
- начиная С++11 конструкторы (с рядом исключений) можно наследовать явно, путем применения using-декларации.