трудности с ooп

[grigori]

x-yuri
я университетов не кончал, названия паттернов не знаю, теоретические споры вести не смогу.

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

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

 

[A1x]

Автор оригинала: grigori
x-yuri
я университетов не кончал, названия паттернов не знаю, теоретические споры вести не смогу.

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

 

[tf]

Если это что-то вроде тегированного кеша

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

 

[x-yuri]

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

понятно. Да, это плохое решение, потому что много классов разделяют одну обязанность - изменение общих полей. Но в данном случае можно не использовать общие поля: создать под каждый case по классу с методом, который будет возвращать список, который нужно будет добавить в журнал. А не изменять общее поле.

Но только я бы так не делал в данном случае. Как по мне, так весь этот код в одном классе нормально себя чувствует. Но если хочется, можно создать отдельный класс для хранения списка (addLog, save, deleteAll, deleteTag, deletePage, deleteUrl). Выносить метод update имеет смысл потому, что это фактически настройки класса, т.е. чтобы настройки не мешались с кодом. Вынос через наследование - самый простой вариант решения этого вопроса

 

[grigori]

A1x
ух ты, респект, вот это да! вот бы мне так в моей деревне ...

x-yuri
все-таки я за более глубокий рефакторинг, прослойки вроде deleteTag тут излишни

 

[AmdY]

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

 

[tf]

я не считаю правильным их связывать

class product_edit_db extends driver_db_edit {
    public function updateData($send) {
        cmfRegister::updateCache('product', $this->getId());
    }    
}

class product_attach_product_db extends driver_db_list_product_attach {
    public function updateData($send) {
        cmfRegister::updateCache('product', $this->getId());
    }  
}

 

[AmdY]

как всё сложно.
ты бы создал класс product в который через плагины можно подключать edit и list, а не наоборот, тогда бы всё крутилось в одном месте.

 

[Adelf]

конечный вариант с xml можно будет посмотреть?

 

[tf]

а смысл туда набивать list edit section attach image param и comment?
и какой у него должен быть функционал?

напишу если так надо, но это на следующей недели, но зачем?

 

[Adelf]

напишу если так надо, но это на следующей недели, но зачем?

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

 

[tf]

считай будет один большой цикл и
у удаление тегов, удаление блоков, и удаление страниц по урлу
это типо пока

-~{}~ 18.08.09 01:57:

это у модели Catalog должен быть метод updateCache, а не наоборот.

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

 

[AmdY]

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

 

[tf]

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

пример покажи)
у меня всем этим занимаются модули, и о каких файлах ты имееш введу, формы?
модули разеделы на слои (похоже сейчас я их плагинами называю) news_part_edit_controller (занимается связами), news_part_edit_modul, news_part_edit_db (обновлениями, предоставление данных)

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