динамическое подключение методов

[algo]

texrdcom
По этому поводу было много флейма. В результате была выработана некая точка зрения на множественное наследование... совпадающая с моей )
Цитирую немного из одного обсуждения.

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

Если избавиться от такого ошибочного взгляда, а принять, что классы могут представлять собой Части Типов, то возникает иной вариант множественного наследования - подмешивания (mixins). В этом случае конкретный класс получается в виде реализации некоторого минимального набора базовых методов и подмешивания производных реализаций, расширяющих поведение данного класса до полного определения Типа.

Иначе говоря, хочу я например, иметь в классе некую часть типа, например - аспект поведения (хочу чтоб объект был Синглтоном)..
Помните - народ мучался ? Как бы унаследовать синглтон.. А если унаследовать синглтон, то больше ни от чего не унаследуешь (нет множ. наследование), поэтому приходится в каждом классе писать код ДУБЛИРУЮЩИЙ.

С подмешиванием все проще.. Подмешаем в класс функционал синглтона.. Подмешаем контекст..

texrdcom - есть workaround, да. C дублированием кода вместо элегантного подмешивания.

 

[uninside]

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

-~{}~ 09.01.06 23:34:

я бы с радостью использовал classkit, дык на серваке dl() выключен

 

[svetasmirnova]

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

 

[algo]

Угу, согласен.. В первую очередь, сделай профайлинг.
То ли это место, которое стоит оптимизировать.. Например, инклюды с акселератором делаются очень быстро.

 

[uninside]

у меня есть две версии проекта:
1)спроектированная без ООП
+ тут труда не составляет подключать новый функции
- приходится тянуть уйму глобальных переменных, которые хоть и доступны, но не желательно чтобы ими пользовались из плагинов (точнее могли менять). здесь и возникло желание переписать под ооп, тем более когда сервак перевели на пхп5.
2)проектируемая на основе ООП
+ все закрытые переменные идут или с ядром или в недоступной для наследников родительской части плагинов
- геморойно динамически апдейтить классы плагинов
--------------------------
в чем суть: так как плагины должны быть все в обязательном порядке проинициализированы (потому что не известно заранее, который понадобиться), то у меня возникла идея подгружать весь основной код, отвечающий за работу плагина, только по мере надобности.
Вызов происходит примерно по такой схеме

$a=new MAIN();
$func="def";
$a->$func="MAIN_func";
if(method_exists($func,$a))
	$a->$func("1234");
else
{
	$a->$func="MAIN_func";
	$f=$a->$func;
	echo $f($a,"1234");
}

function MAIN_func(&$this,$other_para)
{
    var_dump($this);
	return "ok";
}

Как видите, все происходит просто, но, есть одно больное НО.
функция то глобальная. можно было б использовать create_function, но это как-то брутально слишком
собственно все.

-~{}~ 10.01.06 00:05:

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

 

[svetasmirnova]

Грубое решение: спать хочу. Методы меняешь на отдельные классы, реализующие один интерфейс. Примерно так:

interface modulePart {
public function doIt();
}

class concretePart1 implements modulePart {
public function doIt() {
// code
}
}

Далее в основном модуле. Либо хранишь concreteParts в массиве, либо делаешь их динамически подгружаемыми свойствами. И переписываешь основную часть на что-то типа:

$a = new MainClass;
if(isset($a->concretePart) && $a->concretePart instanceof modulePart)
    $a->concretePart->doIt("1234");
else
{
    $a->defaultPart->doIt("1234");
}

-~{}~ 10.01.06 01:24:

А с геттерами,сеттерами ещё лучше будет:

class MainClass {

private $parts = array();

public function __set($varname, $value) {
$this->parts[$varname] = $value;
}

public function __get($varname) {
return (isset($this->parts[$varname]) ? $this->parts[$varname] : $this->defaultPart);
}

//other code
}

И основной код:

$a = new MainClass;
$part = $a->concretePart;
$part->doIt('1234');

 

[texrdcom]

Вот проще используем : http://ua2.php.net/manual/ru/ref.runkit.php
Вот так получаем множественное наследования и убеждаемся что ООП в PHP5 - круто
Тестировал apache 1.33 php5.1.1 windows xp все ок

<?php
class myParent {
  function parentFunc() {
   echo "Parent Function Output\n";
  }
}

class myChild {
}

runkit_class_adopt('myChild','myParent');
myChild::parentFunc();
?> 
// Причем функцию runkit_class_adopt('myChild','myParent');
// Можно вызывать и в конструкторе сыновьего класса и все работает окей 
// также таких наследуемых классов может быть сколько угодно

В данном расширении есть куча методов довольно интерестных!
Но поймите что все сыновьи классы переписывают методы родителей потому если выстраивать очень большую ирархию классов будет очень трудно даже самому разобрать отладить систему!. Многие книги про ООП пишут что наследования утрудняет возможность повторного использования кода! Так что буде бдительны!.
p/s
Смотри на php.net форум код подправил

 

[uninside]

svetasmirnova Пасиб!. В дальнейших размышлениях я как раз тоже к этому и пришел.

texrdcomем, у меня ограничение - я не могу подключать сторонние модули, а runkit не включен.

 

[texrdcom]

uninside
Меняй хостера или проси его подлкючить - нафига такой хостер нужен если он что то не разрешает это ведь не самопальный модуль!

 

[uninside]

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