Или копать в сторону zlib из phpMyAdmin - самый простой путь. И юзается во многих приложениях...
А еще можно использовать exec (если хостер позволяет ;))
Примеры? Пожалуй, TreeStructure - как пример. Добавление/удаление Items/Nodes (одинаковые методы - только вот разные таблицы, которые можно переопределить при наследовании). Сюда попадают все нециклические деревья: категории/статьи, категории/картинки, категории/видео и т.д... Вот вам и наследование... =)
Аха, и количество функций растет, перекрывая десятки раз то, что уже было написано. Где же оптимальность процедурного подхода?
Впрочем, холливар =)
Интересно конечно, но API для своего кода, я так понимаю - нельзя посмотреть, ибо CORE закрыт.
ЗЫ: а что такое
$_SESSION['password']=='d41d8cd98f00b204e9800998ecf8427e' ? '' : $_SESSION['password']
В CUser::authenticate() ? :-D
После этого ВТРОЙНЕ интересно, почему код закрыт. Чесслово... Странные штучки-дрючки )
Тормозит он дико из-за неверной архитектуры БД. Можете посмотреть на досуге - сам сталкивался. А еще не забываем о том, что он с графикой работает - это ресурсоемкие операции. (если мы про админко и операции с изображениями).
Насчет расширений... А вот тут уже вопрос не ООПрограммирования и не ООПроектирования. Тут архитектурное проектирование задействовано.
Я что-то очень сомневаюсь, что они на процедурном напишут =)
А по теме "доабстрагировались" - не означает, что на каждую сущность системы надо по 20 оберток писать. Я к адаптерной системе в 2 обертки пришел. Ничего - шустренько работают системы (профайлинг показывает, что основные 90% - это СУБД). Не стоит говорить о ООП как о сильно тормозящем системы подходе. Системы можно тормозить еще и циклами :)
Devider, Снова вы на конкретные реализации привязываетесь... Вам ли не все равно, как будут кешироваться конфиги: пофайлово, поштучно или вообще генериться в нативный php-код? )
Учитесь абстрагироваться от кода - это для меня важнейшее качество ООП-подхода. Почитайте банду четырех - вообще летать будете, когда начнете применять паттерны ;)
Напомнило "Я пони. Обоснуйте". Доказать можете, что ооп здесь не нужен? Чтобы вас уверовать в жизнь - приведу пример своей реализации системы конфигурации:
A_ConfgInterface - интерфейс
A_ConfigAPI - Адаптер для работы с конфигами
A_ConfigFabricanto - фабрика объектов конфига.
Приступим? =)
<?php $Config = new A_ConfigAPI(); $Config->extract('configName', 'database', 'tablename'); // АPI запускает фабрику объектов с сигналом 'database', просматривая перед этим наличие кеша. Ложит в свой стек имя полученого конфига, регистрирует в диспетчере $Config->extract('configName2', 'fs', 'app::configs::users'); // То же самое. Только фабрика инстанциирует другой объект работы с конфигом, который так же имплементирует A_ConfigInterface $singleConfig = $Config->get('configName'); $allConfigs = $Config->getMerged('configName', 'configName2', 'confgName3',...); $Config->cache($allConfigs);
Что получили?
1. Стандартный интерфейс работы с конфигурацией в системе. Не нужно помнить как работает система конфигурирования в ядре, а как - в приложении
2. Стандартный интерфейс для хранения и кеширования конфигураций
3. Стандартный интерфейс доступа к конфигам
4. Расширяемость за счет фабрики (XML/YAML/FTP/Oracle...)
5. Центральный валидатор конфигураций - A_ConfigAPI
Могу долго так продолжать... А в процедурном секса нас ждет, чтобы такое реализовать - мама не горюй (
Devider, я все-равно не понимаю, нахрена костыли...
Не проще сделать так:
<?php// На этапе инициализации$UserConfig = new ConfigObject();Dispacher::registerObject($UserConfig, 'userConfig');$UserConfig->setSource('database', 'configTable');$UserConfig->read();// На этапе использования, где-нибудь в классе Users$this->_configs = Dispatcher::getObject('userConfig');// Все, готово к использованию. Улыбаемся и машем машем и улыбаемся
Чем полезен такой подход:
При serialize(Dispatcher::getInstance()) можно и нужно проверять типы объектов, хранимых внутри. Ложить все конфиги в единый файл (почти нативное кеширование получается). При wakeup - просто заполнять объект данными из массива.
В случае с глобальным конфигом - нужно еще понимать, что у тебя в глобальной перменной можно кешировать, а что нет... Как понять? На уровне объектов - все просто:
<?php if( $object implements Serializable && $object->cacheEnabled()) { serialize($this->_data['userConfig']); // __sleep, разумеется}
Финита
-------------
Название топика, если что: "Зачем нужны классы в php". Тут никто не спорит о том, какой подход лучше.. Скорее - как можно применять ;)
А состыкуется это примерно следующим: я как-то дописывал систему, в котором были глобальные переменные $CONFIG, $Config, $_Config, $_config... Ей-богу не вру. Вот как в такой каше разобраться? При учете, что кода кило на стописят, как минимум...
Спорим, не обойдется без массива? =)
Самое страшное заключается в том, что мощнейшую волну быдлокода нужно ожидать с выходом шестерки... Ой чего с неймспейсами и лямбдами будут творить - даже представить страшно (
Один из вариантов развития - использование неймспейсов в качестве оболочки для функций (читай - "альтернативы" статическим классам). Вот когда нужно будет показывать уличную магию, чтобы понять как это работает :-D
Что значит "тру"? ООП - он или есть, или его нет. Если нужно гарантировать один экземпляр класса - чем не путь? Земеттье, я употребляю исконно "ООП-термины". А как насчет геттеров/сеттеров? Они не нарушают Ъ концепции? Ведь данные в итоге оказываются "вне объекта". Тоже не Ъ? Другое дело - использование мощи ООП или пародия "для удобства".
Если уж на то пошло - ткну в противоречие между наследованием и инкапсуляцией. Слышали о таком? =)
UPD: что-то на ум упало... А ведь 99% разрабов начинают использовать классы и объекты как "контейнеры" для функций. Чтобы с именованием не путаться... Надо опрос устроить - сколько человек так начало свой путь к ООП ;)
