Comments 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;
}
}
}
+3
Ах-ха-хах! )))
0
Только к этому по-идее надо карту доменного объекта накатать, ага. Н на практике преобразователь строк setPostId в post_id может понадобиться, коль уж с БД работать нужно.
0
> $accessor = strtolower( substr($matches[1], 0, 1) ) . substr($matches[1], 1);
ай яй яй ))
ай яй яй ))
0
>> Вобщем-то все методы доступа используются исключительно для самодокументации кода и не несут никакой логической составляющей
Это открытие в ООП.
Это открытие в ООП.
0
конкретный пример реализованной логики указанием метода доступа можно? :)
"играясь" методами доступа мы лишь говорим как сделать можно, а как нельзя, или лучше не делать. Если Вы считаете это "логикой приложения", тогда да - приношу извинения…
"играясь" методами доступа мы лишь говорим как сделать можно, а как нельзя, или лучше не делать. Если Вы считаете это "логикой приложения", тогда да - приношу извинения…
-1
Да, контракты я считаю логикой создания архитектуры приложения. Самодокументируемость тут ни при чём.
+2
Публичные методы обязаны сохранять инварианты объекта, приватные - нет. Это важное отличие.
Хотя на практике разделение private/protected/public грубое и неудобное. В Java есть ещё один тип доступа (без указания ключевых слов), в C++ - friends. Но всё это - компенсация того факта, что на самом деле методы вообще не должны бы быть связаны с объектами.
Хотя на практике разделение private/protected/public грубое и неудобное. В Java есть ещё один тип доступа (без указания ключевых слов), в C++ - friends. Но всё это - компенсация того факта, что на самом деле методы вообще не должны бы быть связаны с объектами.
+1
AlexeyTokar "конкретный пример реализованной логики указанием метода доступа можно? :)"
Можно, смотрите Singleton
Можно, смотрите Singleton
0
Хе. Не, это же самодокументирование! Ну не надо создавать этот объект, или лучше не создавать!
...Такое ощущение, что нас быстро научат хорошему. Записываемся в очередь.
...Такое ощущение, что нас быстро научат хорошему. Записываемся в очередь.
0
Да уж. В соседней ветке меня уже просвятили, что сессия, оказывается, хранится ТОЛЬКО на стороне сервера и поэтому у пользователя нет никакого доступа к данным, сохраненным в ней.
То ли еще будет?
То ли еще будет?
0
То есть? К идентификатору сессии? Или к её содержимому? Как это выглядело в контексте? Может статься, что Ваш собеседник и прав в чём-то.
+1
А как обстоит ситуация на самом деле?
0
При некоторых условиях можно получить данные, хранящиеся в сессии, т.к. она хранится в директории, открытой на чтение-запись с правами веб-сервера, поэтому, если пользователь сможет разместить на этом сервере свой скрипт, то он прочитает все данные, хранящиеся в сессиях пользователей этого веб-сервера.
Но в принципе, я тогда был не прав в некоторых аспектах.
Но в принципе, я тогда был не прав в некоторых аспектах.
0
1. правильно extends
2. стоить связать инкапсуляцию и getter/setter по смыслу
2. стоить связать инкапсуляцию и getter/setter по смыслу
0
>Protected — объявляет метод или свойство защищенными. Тоесть такими, которые не могут быть доступны из объекта, реализующего класс, но вполне может быть использовано в дочерних классах.
Это как?
Это как?
0
ндя.. неудачно выразился... имелись ввиду методы класса-родителя.. ну вы то поняли :)
0
т.е. наследник внутри себя может оперировать этими свойствами, но когда вы попытаетесь инстанцировать объект наследника и обратиться к свойству через указатель, то ничего у вас не выйдет.
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.
0
тьфу. "с методом" зачеркнуть ) Спать пора.
0
я бы сказал следующий пример более нагляден:
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
0
null он вернёт.
0
eгу. потому что pyfчение свойства $a в данный момент = null
0
прошу прощения:
*значение
*значение
0
Не только. Потому что echo ничего не возвращает.
0
:-D
да. чисто машинально отписал :) но, имхо, Вы придираетесь
да. чисто машинально отписал :) но, имхо, Вы придираетесь
0
Имхо, нет. Потому как люди, которые знают, для чего нужны спецификаторы, и так знают, и никаким самодокументированием их с панталыку не сбить. А люди, которые не знают, могут быть введены в заблуждение.
Ну и получается, что цели у Вас могло быть минимум три:
1) научить всех, что такое спецификаторы доступа;
2) написать своё мнение, что это такое, чтобы Вам пообъясняли;
3) показать, что Вы знаете, что это такое.
:-)))
В первом случае любая придирка поможет новичкам, во втором Вам лично, в третьем, пожалуй, тоже.
Ну и получается, что цели у Вас могло быть минимум три:
1) научить всех, что такое спецификаторы доступа;
2) написать своё мнение, что это такое, чтобы Вам пообъясняли;
3) показать, что Вы знаете, что это такое.
:-)))
В первом случае любая придирка поможет новичкам, во втором Вам лично, в третьем, пожалуй, тоже.
0
а Вы во всем ищите скрытый подтекст? ;)
возможно иногда стоит читать и воспринимать материал именно так как он написан, а не пытаться вникнуть между строк? ;)
возможно иногда стоит читать и воспринимать материал именно так как он написан, а не пытаться вникнуть между строк? ;)
0
0
нисколько. то что некорректно объяснил, еще не значит что просил читать между строк...
0
Есть еще такая штука, что доступ к защищенным методам и свойствам объекта возможен из 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'
0
Ну а почему ему не быть корректным? метод то public, только определение static добавили
0
Это не настолько очевидно, как может показаться с первого взгляда )) Мы ведь обращаемся к закрытому свойству объекта $obj (как бы извне).
0
обращаемся к публичному методу :) тут уже всё на совести разработчика, к чему давать к чему не давать )
0
по-моему Вы не уловили суть создание экземпляра класса :)
хотя я и не уверен что код корректен, но если это так - спасибо за новое открытие для меня :)
хотя я и не уверен что код корректен, но если это так - спасибо за новое открытие для меня :)
0
да, каюсь, невнимательно просмотрел код. Но имхо это больше походит на чудеса ООП php, чем на стандарты ООП :)
0
Да все ОК, нормальный ООП. Почему же метод не должен иметь доступ к скрытым полям класса? :) Ну и что, что он статический...
+1
я тоже так сначала подумал, но потом присмотрелся вот на эту конструкцию:
$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;
не прокатит
0
Я заметил это, да. Действительно, чисто внешне код выглядит странно. Но если подумать, то все получается вполне логично :) Другое дело, что ситуация какая-то весьма искусственная.
0
Так доступ-то ограничивается не объектом, а классом. В данном случае за пределы класса мы не выходим, поэтому и видим защищённые переменные.
0
Нет, это не чудеса PHP )) В Java точно такая же ситуация.
0
Еще для доступа к свойствам возможен такой прием:
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()
0
Только осваиваю ООП.. Не понял зачем делать свойства private. Не могли бы Вы привести пример, где это может быть полезно?
0
где угодно, когда состояние нужно сохранить, но не допускать прямого вмешательства извне объекта... примеров множество можно найти в любом ООП коде :)
0
То есть это больше защита от дурака? :)
0
вобщем-то да :) перечитайте вот эту ветку каментов - тут ан эту тему даже холивар начался :)
0
Sign up to leave a comment.
Articles
Change theme settings
Методы доступа. Наиболее популярные ситуации