Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Вот еще lazy-getter для сомневающихся :)
protected function __call( $method, $value ) {
if ( preg_match( '/^get(.+)$/', $method, $matches ) ) {
$accessor = strtolower( substr($matches[1], 0, 1) ) . substr($matches[1], 1);
if ( isset($this->{$accessor}) ) {
return $this->{$accessor};
} else {
return false;
}
}
}
protected function __call( $method, $value ) {
if ( preg_match( '/^get(.+)$/', $method, $matches ) ) {
$accessor = strtolower( substr($matches[1], 0, 1) ) . substr($matches[1], 1);
if ( isset($this->{$accessor}) ) {
return $this->{$accessor};
} else {
return false;
}
}
}
>> Вобщем-то все методы доступа используются исключительно для самодокументации кода и не несут никакой логической составляющей
Это открытие в ООП.
Это открытие в ООП.
конкретный пример реализованной логики указанием метода доступа можно? :)
"играясь" методами доступа мы лишь говорим как сделать можно, а как нельзя, или лучше не делать. Если Вы считаете это "логикой приложения", тогда да - приношу извинения…
"играясь" методами доступа мы лишь говорим как сделать можно, а как нельзя, или лучше не делать. Если Вы считаете это "логикой приложения", тогда да - приношу извинения…
Да, контракты я считаю логикой создания архитектуры приложения. Самодокументируемость тут ни при чём.
Публичные методы обязаны сохранять инварианты объекта, приватные - нет. Это важное отличие.
Хотя на практике разделение private/protected/public грубое и неудобное. В Java есть ещё один тип доступа (без указания ключевых слов), в C++ - friends. Но всё это - компенсация того факта, что на самом деле методы вообще не должны бы быть связаны с объектами.
Хотя на практике разделение private/protected/public грубое и неудобное. В Java есть ещё один тип доступа (без указания ключевых слов), в C++ - friends. Но всё это - компенсация того факта, что на самом деле методы вообще не должны бы быть связаны с объектами.
AlexeyTokar "конкретный пример реализованной логики указанием метода доступа можно? :)"
Можно, смотрите Singleton
Можно, смотрите Singleton
Хе. Не, это же самодокументирование! Ну не надо создавать этот объект, или лучше не создавать!
...Такое ощущение, что нас быстро научат хорошему. Записываемся в очередь.
...Такое ощущение, что нас быстро научат хорошему. Записываемся в очередь.
Да уж. В соседней ветке меня уже просвятили, что сессия, оказывается, хранится ТОЛЬКО на стороне сервера и поэтому у пользователя нет никакого доступа к данным, сохраненным в ней.
То ли еще будет?
То ли еще будет?
То есть? К идентификатору сессии? Или к её содержимому? Как это выглядело в контексте? Может статься, что Ваш собеседник и прав в чём-то.
А как обстоит ситуация на самом деле?
При некоторых условиях можно получить данные, хранящиеся в сессии, т.к. она хранится в директории, открытой на чтение-запись с правами веб-сервера, поэтому, если пользователь сможет разместить на этом сервере свой скрипт, то он прочитает все данные, хранящиеся в сессиях пользователей этого веб-сервера.
Но в принципе, я тогда был не прав в некоторых аспектах.
Но в принципе, я тогда был не прав в некоторых аспектах.
1. правильно extends
2. стоить связать инкапсуляцию и getter/setter по смыслу
2. стоить связать инкапсуляцию и getter/setter по смыслу
>Protected — объявляет метод или свойство защищенными. Тоесть такими, которые не могут быть доступны из объекта, реализующего класс, но вполне может быть использовано в дочерних классах.
Это как?
Это как?
ндя.. неудачно выразился... имелись ввиду методы класса-родителя.. ну вы то поняли :)
т.е. наследник внутри себя может оперировать этими свойствами, но когда вы попытаетесь инстанцировать объект наследника и обратиться к свойству через указатель, то ничего у вас не выйдет.
class someClass
{
protected $someVal;
}
class someClassElse extends someClass
{
function someFunc()
{
//здесь можно обратиться к $this->someVal
}
}
$obj = new someClass;
$obj->someVal = 'что-нить'; //А вот тут - никак.
$objelse = new someClassElse;
$objelse->someVal = 'что-нить'; //А вот тут - тоже никак, пока в someClassElse не переопределите свойство с методом public.
class someClass
{
protected $someVal;
}
class someClassElse extends someClass
{
function someFunc()
{
//здесь можно обратиться к $this->someVal
}
}
$obj = new someClass;
$obj->someVal = 'что-нить'; //А вот тут - никак.
$objelse = new someClassElse;
$objelse->someVal = 'что-нить'; //А вот тут - тоже никак, пока в someClassElse не переопределите свойство с методом public.
тьфу. "с методом" зачеркнуть ) Спать пора.
я бы сказал следующий пример более нагляден:
class A {
protected $a;
}
class B extends A {
public function b() {
echo $this->a;
}
}
$a = new A();
$a->a; //не можем обратиться
$b = new B();
$b->b(); // вернет значение свойства $a класса A
null он вернёт.
eгу. потому что pyfчение свойства $a в данный момент = null
прошу прощения:
*значение
*значение
Не только. Потому что echo ничего не возвращает.
:-D
да. чисто машинально отписал :) но, имхо, Вы придираетесь
да. чисто машинально отписал :) но, имхо, Вы придираетесь
Имхо, нет. Потому как люди, которые знают, для чего нужны спецификаторы, и так знают, и никаким самодокументированием их с панталыку не сбить. А люди, которые не знают, могут быть введены в заблуждение.
Ну и получается, что цели у Вас могло быть минимум три:
1) научить всех, что такое спецификаторы доступа;
2) написать своё мнение, что это такое, чтобы Вам пообъясняли;
3) показать, что Вы знаете, что это такое.
:-)))
В первом случае любая придирка поможет новичкам, во втором — Вам лично, в третьем, пожалуй, тоже.
Ну и получается, что цели у Вас могло быть минимум три:
1) научить всех, что такое спецификаторы доступа;
2) написать своё мнение, что это такое, чтобы Вам пообъясняли;
3) показать, что Вы знаете, что это такое.
:-)))
В первом случае любая придирка поможет новичкам, во втором — Вам лично, в третьем, пожалуй, тоже.
Есть еще такая штука, что доступ к защищенным методам и свойствам объекта возможен из static-методов того же класса (если идет обращение к private-свойствам), или классов-наследников и классов-родителей (если идет обращение к protected-свойствам).
Иными словами, следующий код корректен:
class A
{
private $a = 'protected var';
private function __construct()
{}
public static function outputA()
{
$obj = new A();
echo $obj->a;
}
}
A::outputA(); // выведет 'protected var'
Иными словами, следующий код корректен:
class A
{
private $a = 'protected var';
private function __construct()
{}
public static function outputA()
{
$obj = new A();
echo $obj->a;
}
}
A::outputA(); // выведет 'protected var'
Ну а почему ему не быть корректным? метод то public, только определение static добавили
Это не настолько очевидно, как может показаться с первого взгляда )) Мы ведь обращаемся к закрытому свойству объекта $obj (как бы извне).
обращаемся к публичному методу :) тут уже всё на совести разработчика, к чему давать к чему не давать )
по-моему Вы не уловили суть создание экземпляра класса :)
хотя я и не уверен что код корректен, но если это так - спасибо за новое открытие для меня :)
хотя я и не уверен что код корректен, но если это так - спасибо за новое открытие для меня :)
да, каюсь, невнимательно просмотрел код. Но имхо это больше походит на чудеса ООП php, чем на стандарты ООП :)
Да все ОК, нормальный ООП. Почему же метод не должен иметь доступ к скрытым полям класса? :) Ну и что, что он статический...
я тоже так сначала подумал, но потом присмотрелся вот на эту конструкцию:
$obj = new A();
echo $obj->a;
в статическом методе, т.е. она почему то аналогична строчке: echo $this->a; но $this в статике использовать нельзя :)
В любом другом месте вызов
$obj = new A();
echo $obj->a;
не прокатит
$obj = new A();
echo $obj->a;
в статическом методе, т.е. она почему то аналогична строчке: echo $this->a; но $this в статике использовать нельзя :)
В любом другом месте вызов
$obj = new A();
echo $obj->a;
не прокатит
Я заметил это, да. Действительно, чисто внешне код выглядит странно. Но если подумать, то все получается вполне логично :) Другое дело, что ситуация какая-то весьма искусственная.
Так доступ-то ограничивается не объектом, а классом. В данном случае за пределы класса мы не выходим, поэтому и видим защищённые переменные.
Нет, это не чудеса PHP )) В Java точно такая же ситуация.
Еще для доступа к свойствам возможен такой прием:
class A {
private $var1='1';
protected $var2='2';
public $var3='3';
public function __get($name) {
$prop=new ReflectionProperty(__CLASS__,$name);
if ($prop->isPublic()) {
return $this->$name;
}
}
}
$obj=new A;
var_dump($obj->var3);
Т.е. исскуствено ограничиваем доступ к защищенным свойствам через __get()
class A {
private $var1='1';
protected $var2='2';
public $var3='3';
public function __get($name) {
$prop=new ReflectionProperty(__CLASS__,$name);
if ($prop->isPublic()) {
return $this->$name;
}
}
}
$obj=new A;
var_dump($obj->var3);
Т.е. исскуствено ограничиваем доступ к защищенным свойствам через __get()
Только осваиваю ООП.. Не понял зачем делать свойства private. Не могли бы Вы привести пример, где это может быть полезно?
где угодно, когда состояние нужно сохранить, но не допускать прямого вмешательства извне объекта... примеров множество можно найти в любом ООП коде :)
То есть это больше защита от дурака? :)
вобщем-то да :) перечитайте вот эту ветку каментов - тут ан эту тему даже холивар начался :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Методы доступа. Наиболее популярные ситуации