Костян Проверяет на соответствие интерфейсу или просто в качестве информативных целей, хотя сейчас попробую
karlozzz это то, что тебе надо знать... IDE тебе будет показывать только те методы которые диктует интерфейс - всё заебись, ты пишешь методы интерфейса
karlozzz допустим мы работаем в двоем, я пишу некий класс для обработки твоих объектов в нем есть метод add [js]class Padaboo { private $karlozzzObjects = array(); public function add($obj){ if(!$obj instanceof IPadaboo)echo "ololo"; $this->karlozzzObjects[] = $obj; } public function update(){ foreach ($this->karlozzzObjects as $obj) { $obj->update(); } } }[/js] и я тебе говорю, вот делай что хочешь но что бы метод update там был [js]/** * привет karlozzz все твои объекты * должны реализовывать этот интерфейс * он должен сохранять объект */ interface IPadaboo{ public function update(); }[/js] ты пишешь свои объекты, один пишет в базу, другой пишет в файл [js]class Karlozzz implements IPadaboo{ private $name; public function __construct($name) { $this->name = $name; } public function update() { echo "пишем в базу $this->name <br/>"; } } class Karlozzz2 implements IPadaboo{ private $name; public function __construct($name) { $this->name = $name; } public function update() { echo "пишем в файл $this->name <br/>"; } }[/js] а мне тем временем обсалютно все равно что происходит в методах update я тебе дал интерфейс остальное не мои заботы [js]$padaboo = new Padaboo(); $karlozzz = new Karlozzz('адин'); $karlozzz2 = new Karlozzz2('два'); $padaboo->add($karlozzz); $padaboo->add($karlozzz2); $padaboo->update();[/js] такие и похожие ситуации встречаются когда ты работаешь с библиотеками или API т.е. когда ты разработчика в глаза не видел, а есть только интерфейс
Padaboo Спасибо за потраченное время, но это-то понятно конечно, единственное что я писал выше, это то, что кроме instanceof подобное взаимодействие и на бумажке можно написать, сравнительно небольшая (как это лучше описать...) функциональная нагрузка, чтоли у интерфейсов... Представь, что ты разработал свой объект, public function add так и осталась публично, потому что твой объект является частью структуры, а через данный метод выполняются запросы от другого объекта структуры, и что ты не делай, как не прописывай интерфейсы, я то к нему доступ буду иметь, а что если не в интерфейс посмотрю, а в реализацию и использую его, что в корне не правильно будет...
karlozzz я тебе уже написал, что нельзя скрывать паблик члены. Чё ты хочешь? Их НЕЛЬЗЯ скрывать, они на то и публичные.
karlozzz так и должен будешь использовать все это, представь что мой класс - библиотека если хочешь что бы разные объекты выдавала система напиши фабрику которая будет возвращать объект в зависимости от уровня доступа т.е. [js]$obj = $factory->getObject($user->access);[/js] я не думаю что, кто то предложит что то дельное не зная контекста использования объектов, может быть есть смысл сделать совсем по другому
Padaboo Фабрика тут не поможет, ладно, не буду никого грузить, нашел альтернативное решение, когда время будет написать, и сюда выложу
Это редактор табличных структур данных, который состоит из основного управленца (обеспечивает взаимодействие подключаемых к нему...), к которому подключается драйвер (реализует взаимодействие с данными, будь то таблица в БД, файл или виртуальная таблица), визуализатор (отвечает за вывод инофрмации (напр. статичный или аякс)) и менеджер (отвечает за конкретный вывод информирует всех о таблице, столбцах, дизайне вывода ячеек, разрешена ли сортировка, отсечение, поиск итд итп)
Для того что ты хочешь используется интерфейс в связке с абстрактным классом (хотя в этом случае интерфейс не свистит вообще а абстрактный класс его создаёт) и шаблон "Composite " с листьями
Набросок сделал... PHP: <?php public function isAccessToMethod() { $debug = debug_backtrace(); $args = func_get_args(); switch($args[0]){ case('privateObjects'): $args = array('table', 'handler', 'driver', 'driverElement'); break; case('internalObjects'): $args = array('table', 'handler', 'driver', 'driverElement', 'manager'); break; } //Для прямого доступа $access = false; //Для запрета определенных $notAccess = true; $className = $debug[2]['class']; $classInterfaces = class_implements($className, true); if (class_exists($className, true)) { foreach ($args as $v) { if (strpos('not-', $v) == 1) { $not = true; $v = substr($v, 4); } else { $not = false; } switch ($v) { case('table'): $interface = 'Table_interface_main'; break; case('manager'): $interface = 'Table_interface_manager'; break; case('handler'): $interface = 'Table_interface_handler'; break; case('driver'): $interface = 'Table_interface_driver'; break; case('driverElement'): $interface = 'Table_interface_driver_element'; break; default: exit('Not found element: '.$v.';'); } $isAccess = isset($classInterfaces[$interface]); if ($not) { $isAccess = !$isAccess; $notAccess = ($notAccess AND $isAccess); } else { $access = ($access OR $isAccess); } } } if (!$access OR !$notAccess) { exit('not Access: '.$debug[1]['class'].'->'.$debug[1]['function'].';'); } }?> Greg1978 Посмотрел этот шаблон, все таки не думаю что он подойдет...
Ах да, используется так: PHP: <?php $this->isAccessToMethod('privateObjects'); $this->isAccessToMethod('manager', 'table'); $this->isAccessToMethod('not-table', 'not-manager'); ?> итд
У меня то же что то код не выводит нормально. и всё же этот код ничего не объясняет, где полиморфное использование одного и того же типа в данном случае интерфейса. Если нужны разные методы, точнее один и тот же метод с разным алгоритмом при чём что бы он являлся доступным методом в виде интерфейса шаблон "Composite" всё таки самое оно. Может всё таки смогли бы сделать в UML, показать что собственно нужно?
Greg1978 Нет, смотри примерчик [js]<?php class a{ public $bObj; //Доступный всем public function f1(){ .. $this->bObj->test(); } //Только b public functoin f2(){ } } class b{ public $caller; public function test(){ ... $this->caller->f2(); ... } } $a = new a(); $a->bObj = new b(); $a->bObj->caller = &$a; //Отлично работает $a->f1(); //Доступ запрещен, т.к. внутренняя функция структуры, а функция isAccessToMethod, проверяет кто вызвал данную функцию и имеет ли объект к ней доступ (является ли внутренним в структуре или внешним) $a->f2(); ?[/js]>
Как, возможно, и ранее говорилось неверная архитектура. Может быть f2() не должна являться методом объекта A и перенести её в частное владение объекта B. Ведь именно объект B нуждается в этом методе который не должен быть доступен при чём всем объектам. Другими словами этим методом f2() пользуется лишь объект B. Отсюда вывод что если есть другие однотипные объекты которые используют метод f2() они должны просто наследовать от абстрактного класса допустим X в котором метод f2() только лишь объявлен но не реализован, что даёт иметь "листья" в наследовании. В проектировании ООП есть такой процесс как анализ Проектных классов их зависимости, возможности и требования. Отсюда вывод интерфейсов и свойств объектов. Кстати UML в помощь!
Greg1978 Не подойдет, я же говорю, что все уже проанализировано... возьмем к примеру метод getManager() который возвращает приватную переменную - ссылку на объект менеджера, он находится в основном управленце и требуется как визуализатору, так и драйверу, даже из глобально среды иногда требуется его вызвать...
а от кого вы что скрывать собрались? если у вас public метод он и будет public, или вы хотите что бы [js] <?php class fooClass{ public function methodA(){ } } class barClass{ private function methodB(fooClass $a){ $a->methodA(); } } $foo = new fooClass(); $bar = new barClass(); // и что бы $foo->methodA(); // нельзя было $bar->methodB($foo); // можно было? ?> [/js]
VItalijs Тема закрыта, если так интересно посмотрите предложенный выше метод, все зависит от класса - из который вызывается метод, скрывать на всякий случай, чтобы ошибок при разработке небыло
Расслабтесь, в PHP OOP "своей конструкции" В языках с более менее нормальным ООП это работает нормально, так как Вы хотите здесь. п.с. Когда я наткнулся на эту "особенность" PHP, я офигел и полдня собирал мозги в кучку, чтобы осознать что "на безрыбье и рак рыба".
Chushkin, давайте продолжим бессмысленный срач. Объясните, каким образом, вещи являющиеся темой данного разговора имеют хоть какое-то отношение к ООП?