Реализация интерфейса вызова модулей системы

Вызов модулей в моей CMS происходит следующим образом, например запрос вида index.php?mod=news&task=view&id=5 подключает модуль Новостей, далее вызывается метод, который выводит Новость с id = 5 т.е. метод view - впринципе стандартная схема..
Структура файла модуля (в нашем случае модуля News) у меня выглядит следующим образом:

PHP:

1. /** вывод списка новостей */
2. if ($task == 'list') {
3.     //
4. }
5. /** вывод отдельной новости */
6. if ($task == 'view') {
7.     //
8. }

т.е. задавая $task в строке запроса мы вызываем нужный функционал....

Так вот тоже самое можно было бы конечно реализовать и с помощью вызова функций, т.е:

PHP:

1. /** вывод списка новостей */
2. function NewsList() {
3.     //
4. }
5. /** вывод отдельной новости */
6. function NewsViewId{
7.     //
8. }

Достоинством первого метода является то что не надо думать каждый раз о том чтобы не забыть сделать обьявить очередную глобальную переменную в функции (т.е. global $var), впрочем у меня их не так много - но все же....., а с другой стороны такая локализация позволяет не думать о пространстве имен - ведь оно реализуется в каждой из функций модуля... потому можно забыть о пересечении глобальных переменных ядра системы с переменными используемыми внутри любого модуля...
Так вот вопрос в том, что же предпочесть? Кроме того, поделитесь своими решениями такого рода проблем...

 

да так и есть...

 

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

 

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

 

легко в смысле отдельная функций (или функциональность) будет лежать в отдельном файле - да согласен.... но все же: -кол-во инклудов возрастет (ибо может возникнет ситуация вызова сразу нескольких task'ов); - код принадлежащий одному модулю (так сказать определяющий его целостный функционал) раскиданный по файлам - ИМХО все-таки неудобно...

 

ну список модулей, к примеру:
help\
links\
login\
mainmenu\
menu\
system\
templates\
update\
users\
backup\
blocks\
catalog\
config\
content\
editors\
и т.д. ... ну а список функций чего приводить то...?? у каждого модуля соответственно свой набор... иногда модуль может вообще содержать класс... впринципе структура модуля не формализована - это черный ящик... со своими методоми (тасками), меня тут больше интересовала организация интерфейса вызова методов модуля...
Хотя впринципе я уже почти сам ответил на свой вопрос...

 

да, только лучше сформулировать так: "пользователь может вызвать открытую функцию конкретного модуля" - в моей системе не предполагается использование call_user_func() - т.е. пользователь не сможет подменой task'а вызывать что угодно...

 

нет контроллер запросов у меня один на самом деле...
тут речь шла про task'и - будем их называть методами конкретного модуля, так вот они как правило общедоступны... а такого рода операции как редактирование, создание, удаление и перемещение например решаются через систему управления доступом - потому даже в случае вызова злоумышленником запрещенной для него функции из конкретного модуля он ничего не получит и не сможет сделать...

 

dark-demon, я еще не пришел к окончательной реализации интерфейса вызова методов модулей, но все равно считаю что выбрасывать отдельный task в отдельный файл - это черезчур много уж файлов получается... и ИМХО мне проще когда основной функционал модуля у меня в одном файле... ибо стока много файлов - путанница... да конечно можно как-то сгруппировать функционал одного модуля по файлами при его большем размере, но все же концепция "основной функционал в одном файле " ближе к телу

 

уже думал.. проблема в том, что модули в будущем вполне возможно будут писаться другими программистами - а накладывать ограничение в виде обязательного применения ООП во всех модулях не совсем правильно ИМХО будет