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

[tf]

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

есть к примеру класс, в нем есть функциональная часть
логическая часть
к примеру

class UpdateCache {

    //функциональная часть
    static protected function save($type {
    }
    static protected function deleteAll() {
    }
    ....

    //логическая часть
    static public function update($id) {
        switch($id) {
            // простынка такая
            case 'catalog':
                ....
                break;
            case 'section':
                ....
                break;
            ....
        }
    }

}

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

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

 

[grigori]

А можешь объяснить, зачем нужен трехслойный вызов статическими методами друг друга для того чтобы выполнить один метод синглтона?
В чем великая цель этого наворота?

 

[tf]

код я убрал, кусками он наверное не нужен
если ты о self::update('catalog'); - делать тоже самое что при вызове пункта - сугубо настройка действий
>>один метод синглтона
там пишется простой лог действий, при уничтожении объекта - завершении работы скрипта, пишется все в базу

 

[grigori]

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

 

[A1x]

а если вместо свича применить паттерн "стратегия"

class UpdateCache {

    //функциональная часть
    static protected function save($type {
    }
    static protected function deleteAll() {
    }
    ....

    //логическая часть
    static public function update($id) {
        $className = $id.'Strategy';
        $strategy = new $className;
        $strategy->doSomething();
    }

}

соответственно вместо разрастания свича просто добавляются новые классы стратегий

 

[grigori]

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

-~{}~ 12.08.09 01:15:

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

-~{}~ 12.08.09 01:18:

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

-~{}~ 12.08.09 01:24:

tf
после редактирования понять, что именно делает код, и как ты пытаешься его разделить, стало невозможно

 

[tf]

grigori, насчет $this или self вызывать, ту наверное не играет роли, хотя $this добавляет гибкости в отстутствии static:: в 5.3
если возникнет необходимость, можно будет переписать на $this, сиглентон был добавлен из за необходимости не дублировать лог

статические методы ненужными в принципе

я не слушал спора тупоконечниками с остроконечниками

но, с самой логической частью как лучше поступить?
A1x, спасибо, посмотрю паттерны на предмет switch, if решений

-~{}~ 12.08.09 02:30:

grigori, если это как то поможет
http://phpclub.ru/paste/index.php?show=2326
http://phpclub.ru/paste/index.php?show=2327

 

[grigori]

я не продолжаю спор, не цепляюсь к статическим методам

половину твоего класса можно переписать простыми функциями, которых можно добавить сколько угодно

для меня это значит, что ты строишь не иерархию для работы, а Тадж Махал индусо-подобным методом, который сам себя похоронит

Логическая часть не должна наследовать функционал, имхо это противоречит идее ООП.
Интерфейс определяет структуру, базовый класс реализует интерфейс, определяя базовую логику. Дочки расширяют родителя, реализуя функционал.
Разве не так?

 

[tf]

аля updateCatalog ?
может быть это лучше, это выросто из двух case, сейчас представляет такую простыню.
значит клиент скорее жив чем мертв?

 

[grigori]

>если это как то поможет
да, очевидно, что можно написать справочник вызовов по параметру, который вынести в XML или массив,
оставив логику в одном нормальном классе

 

[tf]

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

 

[tf]

.

 

[grigori]

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

 

[tf]

вызов идет из модуля, и там все до безобразия просто

public function updateData($send) {
    cmfUpdateCache::update('section', $this->getId());
}

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

 

[grigori]

да, я бы переписал методы cmfUpdateCache, развернув deleteTag в цикл addLog по списку параметров, а потом объединил в несколько сильно разных методов с вынесением списков

может, кто-то предложит что-то другое

 

[tf]

я наверное перепишу синглентон сразу на save, он у меня лог писать будет
косяк с __destruct, наверное пока придется оставить(

или переписать тотже синглентон на регист и его использовать, а внутри класса просто работать c $this
в register_shutdown_function добавить нормальный вызов очистки регистра и через него кидать лог в базу
в итоге будет Register::updateCache('section'); и не будет хака с объектами "кто быстрей умрет"

 

[grigori]

давай перенесем в теорию или основной
тема совсем не оффтопная

 

[tf]

да я не против)

-~{}~ 12.08.09 05:20:

в итоге получилось очень даже мило, простынку сейчас не охото трогать, но потом ее заменю на xml
http://phpclub.ru/paste/index.php?show=2328

 

[x-yuri]

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

grigori, а можешь рассказать подробнее о полях и их синхронизации, т.е. при чем они к паттерну "Стратегия"?

 

[A1x]

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

ну до эвала тут далеко, просто динамически определяется имя класса
разве как-то можно иначе реализовать "стратегию"?

"стратегию" как раз рекомендуют как вариант избавиться от контрольных структур типа ифов и свичей

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

Если это что-то вроде тегированного кеша - у Котерова были неплохие статьи - http://dklab.ru/chicken/nablas/47.html