Но опять же: допустим возникает новый тип документа, который надо обработать. пишем плугин. написали. что дальше? писать класс для него? а если документов с 50?Автор оригинала: Frol
объявляем этот самый PluginInterface со списком основных методов.
дальше делаем на каждый тип документа свой класс, в котором реализуем PluginInterface.
а реализовываем его с помощью "набора функций".
Ввожу в курс дела снова и снова.Автор оригинала: Frol
тут и ООП нет, чтоб в нем понимать.
ООП не единственный метод решения задачи.
мы сами еще не понимаем, что тут решается.
а Вы нас в курс дела не вводите.
Frol, читай сообщение поста, плз.Автор оригинала: Frol
sbazz
тем более ты не знаешь, что не может быть в одно время более чем одной функции с именем start.
Кэширование?У меня обработка одного html - 0.8-1 с. preg_match_allей много.. Ну и файлики html по 250 кб - 300 кб.
Функция есть такая по вызову других функций с передачей им параметров из заданного массива.Что ты подрузумеваешь под call_user_function_array?
Да, Вы правы, мне хотелось бы именно первый вариант.Автор оригинала: Нечто
sbazz
Вы хотите динамическую подгрузку плагинов по требованию или они все одновременно грузятся? Видимо, первое. Поэтому, врядли Вам нужно наследование и ООП вообще. Можно, конечно использовать статику в качестве неймспейсов, но это на любителя.
Попробуйте сделать в классе ядра функцию plugin(), которая бы подключала файл по указанному в параметре имени плагина и делала call_user_function_array() с указанными параметрами.
Если сделаете такой механизм, то потом сами поймете, что Вам еще нужно.
Кэширование не поможет - файликов таких много. И разных.Автор оригинала: Нечто
Кэширование?
Функция есть такая по вызову других функций с передачей им параметров из заданного массива.
Вместо 'plugin_' подсставляется имя плагина.Есть, допустим, 2 плугина с такими функциями. include один, вызываем. include другой, вызываем и получаем сообщение о переопределении plugin_start и прочих. Или я тебя не понял или ты меня?