Попробую описать свой вопрос, нужна написать стандартизированый модульный интерфейс , на основе которога писались бы модули. Т.e. у нас есть general.pl который подгружает модули из lib "mods" при этом не нужна править сам general.pl в зависимости от работы модуля, иными словами можна взять за пример скажем 3d studio max, т.е. у нас установлен дистриб, вот скачали мы плагин который улучшает наложение шейдеров, заинсталили его, запустив 3d max плагин этот уже в деле.

ps: даже не знаю с чего начать, но идея дика заинтересовала.

Какой-то сумбур в вопросе.
Не так часто и быстро. Объясни подробнее.

Ну вот пару ссылок нашел:
http://en.wikipedia.org/wiki/Abstract_factory_pattern
http://www.rsdn.ru/article/patterns/AbstractFactory.xml
ну вот что та нашел...

DiverD, поиск на форуме неплохой, недавно работу с плагинами обсуждали

DiverD, смотри тут, правда до совсем готового решения там далеко , Но если чего наделаешь пиши. 

Такого счастья хочешь или тебе нужна реальная Абстрактная Фабрика 

Скрипт написан около трех лет назад (с тех пор я про него просто забыл -  он просто работает  ), поэтому комментарии приветствуются.

Я бы лучше:

Добавлено @ 08:32 
Или, тогда уж, *main::can=*UNIVERSAL::can;

Это сообщение отредактировал(а) tishaishii - 8.3.2007, 08:29

thnx, попробую потом отпишу

DiverD, не заморачивайся Абстрактной Фабрикой! Web-оно в 99% случаев требует более простых (более легких и более быстрых в реализации) решений.

Если хочешь посмотреть что "полегче" - начни отсюда:
http://ooad.asf.ru/Patterns_title.aspx?IdKat=9
Все эти решения,  в какой-то мере, наверно каждый у себя использовал. 

P.S. Если ты знаком с Шаблонами Проектирования, эта ссылка покажется тебе очень легким чтивом. Тогда уж, извини.

tishaishii,  спасибо за  комментарии.

Видимо реально настало время провести Refactoring (улучшение кода) для моего, уже давно работающего, программного обеспечения. 

Про use lib.

Не особо много хостинговых серверов я знаю, но на всех из мне известных есть правильно возведенная $ENV{DOCUMENT_ROOT} и оно работает. И под Perl 5.6 и под 5.8. Естественно, предпологается, что index.cgi запускается из-под web-сервера, поэтому наличие/отсутсвие $ENV{DOCUMENT_ROOT} просто не проверяется. Да и использовать FindBin не было особого желания.

По твоему коду есть два мелких комментария. 

1. В большинстве случаев метод new() есть. Поэтому вызов дополнительного can на проверку наличия этого метода не совсем оправдан. Я предпочту просто попытаться его вызвать (раз уж нужно будет это сделать потом) и отловить ошибку в случае проблем.

2. $module->new($cgi)->$method;

У sub execute() есть еще одна особенность. Она не должна  выдавать ошибок, которые к ней, к execute, не относятся. Т.е. если есть ошибка в модуле или его вызвали неверно, сказать об этом разработчику и указать, по возможности, не на себя, а на тот модуль, который эту ошибку вызвал.

Во-первых, у тебя нет проверки на "объекность" модуля (у меня ее тоже не было, кстати), поэтому эта строка может вызвать ошибку времени выполнения (прямо в этой строке, в sub execute {} ), хотя реально "ответсвинен за ошибку" тот модуль, который мы вызывали (пытаемся вызвать).

Во-вторых, ИМХО, такая реализация менее читаема.

Если ты подразумевал такой строчкой реализацию механизма распределенного управления (distributed control) (вместо централизованного управления - см. М. Фаулер, UML-2, основы, главу 4, про диаграммы последовательностей), то такая реализация к нему не приводит. Все равно сначала вычисляется new(), ссылка на объект возвращается в execute() и оттуда снова выполняется $method.

Постарался учесть это все в коде, который привожу ниже (только sub execute). Несмотря на то, что сразу поставил на рабочий проект, отладить по-нормальному просто не было времени.

Ой, не знаю про что ты написал. Там куча каких-то умных формулировок.
Но я однозначно против eval всуе: eval { $anObj = new $module ($cgi); };
И так и не понял, откуда берётся метод can у любого модуля. Ну нет у него такого метода по-умолчанию.

Zuzu не я не для веба пишу, решил написать бота работающего по средсвам irc, что бы к ниму можна было писать плагины ( модули ) в определенном стандарте, что бы скажем кидал эти модули в папку plugins и при старте бота они автоматом подгружались и можны было с ними работать..

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

ps: по идеи не сложна, в голове что та крутиться но выдать не могу=))

DiverD, не парься для IRC есть такая тема с поддержкой плагинов POE::COMPONENT::IRC

я знаю про POE и другой CPAN но мне не нужны модули=)

Забудем про парадигмы управления (описанные, в частности, М.Фаулером). Оно нам на самом деле здесь ни к чему. Извини, на самом деле слегка скатился во флэйм. Просто я, когда "игрался" с реализациями (на Perl) механизмов  распределенного управления, допустил аналогичную ошибку. Вот и понесло...



Все модули, которые находятся в каталоге mod - объектно-ориентированные. По сути, это классы. Или, в терминах Perl, процедура new()  каждого пакета (package) возвращает ссылку, приведенную (blessed) к этому пакету. Я думаю, очевидно, что в этом случае порожденный объект будет иметь (по крайней мере) еще и методы "родительского" класса UNIVERSAL, который является родительским классом по-умолчанию (perldoc perltoot, UNIVERSAL: The Root of All Objects). Поэтому вызов метода can() корректен для любого объекта. 

Если не секрет, почему тебя смущает eval {} ? Были какие-то случаи? Я всегда считал eval - этаким механизмом перехвата ошибок. Об этом, в частности, написано в документации. (perldoc -f eval)

Меня в твоем коде больше смущает вызов функции, как процедуры пакета ( &UNIVERSAL::can($module, 'new')) ), для проверки наличия new() как метода создаваемого объекта. Т.е. проверяется именно наличие процедуры new() в пакете $module. При этом:

Во-превых,  происходит (может у меня в голове?) некое торможение из-за одновременного использования двух различных стилей (процедурного и объектно-ориентированного) для, по идее, одной сущности - нашего вызываемого метода из нашего объекта. Как говорится, либо объекты, либо процедуры. Лично я стараюсь без особой необходимости не мешать их друг с другом.

Во-вторых, про объектно-ориентированную суть $module мы так ничего и не узнаем.

Добавлено @ 11:32 


Все достаточно просто. 

1. Есть каталоги

mod - для модулей
www  - для кортя сервера

2. В каталог mod помещаются файлы, названные одноименно с именем пакета (класса)



3. В каталог www помещается файл-контроллер (index.cgi)

4. Вызов нужного модуля происходит при "нажатии" на ссылку типа:

index.cgi?module=order&method=show

5. Желающие могут "завернуть URL" с помощью .htaccess (чтобы спрятать внутренний механизм реализации, например)

6. Чтобы предотвратить вызов (контроллером) "неправильных" методов из "неправильных" объектов, они распологаются либо не в каталоге mod, либо имя файла не совпадает с именем пакета. 





Это сообщение отредактировал(а) Zuzu - 11.3.2007, 14:24

Zuzu
ясн=)
проста именно программно немножка не понимаю, пытаюсь представить этокий конструтор в голове но не сильн получается