static VS Singelton
- Автор темы Духовность™
- Дата начала
whirlwind
TDD infected, paranoid
korchasa паттерны в принципе нацелены на нефункциональные требования. Функциональные требования говорят что должна делать система. Паттерны говорят каким образом (объекты взаимодействуют), то есть, ничего не говорится о том, что (какая задача) выполняется с точки зрения конечного продукта. Реализация шаблона не есть цель разработки, если конечный продукт не является библиотекой паттернов.
это два разных скрипта, которые выполняют разные действия и по-разному вызываются
они создают одинаковые смысловые объекты, заполняют их данными (из POST или из текста полученного письма) и передают в обработку другим объектам, которые не знают, как вызывается скрипт
но я передаю смысловые обекты с определенной структурой
Fortop
Новичок
А в случае Request у тебя будет один скрипт(контроллер).
И два раннера, которые из разных мест будут заполнять одинаковый Request.
Легко догадаться, что чем больше логики в твоих скриптах тем более выгоден Request.
И наоборот, чем меньше логики, тем меньше смысла в дополнительной абстракции в виде Request
Fortop
мне не бывает надо, чтобы скрипт уборки мусора вызывался через браузер - он вызывается только по крону.
скрипт, который парсит логи почтового сервера, вызывается только почтовым сервером
а скрипты, которые отдают данные веб-пользователям, вызываются только веб-сервером
если логика сложная, я выношу ее в отдельные объекты, суть не в том
скриптов, которые бы могли выполняться как из command_prompt, так и в веб, у меня не бывает
imho это неправильно
-~{}~ 02.04.10 19:27:
короче, я резко против универсальности
IMHO, скрипт не должен отдавать страницу, обрабатывать POST и вызываться по крону
мне не бывает надо, чтобы скрипт уборки мусора вызывался через браузер - он вызывается только по крону.
скрипт, который парсит логи почтового сервера, вызывается только почтовым сервером
а скрипты, которые отдают данные веб-пользователям, вызываются только веб-сервером
если логика сложная, я выношу ее в отдельные объекты, суть не в том
скриптов, которые бы могли выполняться как из command_prompt, так и в веб, у меня не бывает
imho это неправильно
-~{}~ 02.04.10 19:27:
короче, я резко против универсальности
IMHO, скрипт не должен отдавать страницу, обрабатывать POST и вызываться по крону
triumvirat
в твоём первом примере зачем тебе инстанцировать класс, если у тебя нет ничего в конструкторе и вызовы не завязаны на состоянии ОБЪЕКТА.
применяй статик всегда, пока не понадобятся плюшки объекта, тогда можно эксперементировать с singleton(исправь, а то глаз режет).
У меня в Request сразу оба паттерна используются
p.s. После фреймворка HraKK решил накидать простой фреймворк для быстрой разработки, так что по мере готовности выложу. Мот кто посоветует простой и удобный класс для MySQL и желательно c table data getway
в твоём первом примере зачем тебе инстанцировать класс, если у тебя нет ничего в конструкторе и вызовы не завязаны на состоянии ОБЪЕКТА.
применяй статик всегда, пока не понадобятся плюшки объекта, тогда можно эксперементировать с singleton(исправь, а то глаз режет).
У меня в Request сразу оба паттерна используются
p.s. После фреймворка HraKK решил накидать простой фреймворк для быстрой разработки, так что по мере готовности выложу. Мот кто посоветует простой и удобный класс для MySQL и желательно c table data getway
weregod
unserializer
whirlwind
grigori, Ваш подход к реализации понятен, но требования к внутреннему поведению системы иногда меняются, пример из личного опыта:
Вы написали queue.mail.script, который совершает рассылку писем из очереди по cron.
Заказчик требует отказаться от cron, так как у потребителей продукта начали возникать проблемы с возможностью запуска по cron каких бы то ни было скриптов в связи с популярным выбором дешёвых тарифных планов хостингов.
Вы переиспользуете исходное решение для запуска в рамках ignore_user_abort/register_shutdown_function при отображении страниц сайта.
конечно, это моё IMHO, но что-то мне подсказывает, что цена модификации системы при подходе whirlwind может отличаться раза в 2 от цены модификации системы при Вашем подходе, + нужно помнить о багоопасности модификации системы именно в Вашем случае
кстати, личный опыт говорит о том, что описанная задача была задвинута в далёкое туду
единственное утверждение в этой теме, отталкиваясь от которого можно прийти ко всем перечисленным реализациям
grigori, Ваш подход к реализации понятен, но требования к внутреннему поведению системы иногда меняются, пример из личного опыта:
Вы написали queue.mail.script, который совершает рассылку писем из очереди по cron.
Заказчик требует отказаться от cron, так как у потребителей продукта начали возникать проблемы с возможностью запуска по cron каких бы то ни было скриптов в связи с популярным выбором дешёвых тарифных планов хостингов.
Вы переиспользуете исходное решение для запуска в рамках ignore_user_abort/register_shutdown_function при отображении страниц сайта.
конечно, это моё IMHO, но что-то мне подсказывает, что цена модификации системы при подходе whirlwind может отличаться раза в 2 от цены модификации системы при Вашем подходе, + нужно помнить о багоопасности модификации системы именно в Вашем случае
кстати, личный опыт говорит о том, что описанная задача была задвинута в далёкое туду
weregod
unserializer
с нуля цена разработки гибкой системы может отличаться в стопиццот раз от цены простой
я рассматривал цену модификации уже существующих решений в рамках некоторых абстрактных продуктов, скатившись до некоторых конкретных примеров
в общем экономическом случае лучше предусмотреть некоторую потенциальную гибкость системы, нежели в последствии решать проблемы костылями.
главное убедить буюджетодержца, что некоторые вложения здесь и сейчас будут экономически выгодны спустя время, меньшее чем ожидаемый период отбития вложений
whirlwind
TDD infected, paranoid
Вот кстати, требования первичны. Требования к системе первичны перед требованиями к отдельным элементам системы (объектам, классам). Если этого не забывать, то разработка достаточно гибкой реализации ничуть не затратнее, чем решение в лоб. Например смотрим: нужен нам враппер реквеста? Хотим абстрагироваться от формата входных данных это позволит писать контроллеры не заморачиваясь вообще в каком окружении их будут выполнять, сколько это займет 20мин -> нужен. Нужен нам сингельтон на враппере реквеста: у нас контроллеры порождаются фабрикой, которая впрыснет все что необходимо, статика усиливает связанность, а зависимости это плохо + сингельтон не дает ничего такого необходимого - нет, не нужен. Ну и тп.
гибкость должны быть до определённой, т.к. иногда реализация гибкости достигается усилиями большими и усложнением архитектуры, нежели тупое переименовывавание по проекту и чуток дописывания-переписывания. Тогда хоть понятно для чего тесты писать, чтобы после рефакторинга всё не сломалось. Тем более, опыт показывает, что даже самые гибкия решения приходится переписывать. Посмотрите сколько переписывается ZF, Symfony, Doctrine.
Гибкость должны быть тоже ограничена здравым смыслом.
Гибкость должны быть тоже ограничена здравым смыслом.
whirlwind
TDD infected, paranoid
AmdY тут не спорю. Я хотел обратить внимание на требования. Если нет хотя бы набора use case, то отталкиваться не от чего и переписывать придется хоть гибкую хоть негибкую реализацию (ну либо копипастить с багами). Потому что для любого анализа нужен vision. Например, нельзя разработать достаточно эффективный реквест, не зная где и как он будет использоваться.
weregod
Да, я понимаю и уточняю, что конкретно в моих задачах такого не бывает.
>в общем экономическом случае
Ради одной задачи в 2 года - надо ли вводить прослойку для всех вызовов?
Каждый описанный случай - или редкая задача (обработка одновременно и json, и формы), или чистое искусство (удобней для тестов), или по определению глупость (хостинг без крона, как MySQL-совместимая БД на чистом PHP).
В случае с json можно добавить фильтр/маппер/модель/парсер, который заполнит данными осмысленные объект(ы).
А класс доступа надо написать/изучить, думать о нем, дебажить, и выполнять при каждом вызове.
>цена разработки гибкой системы может отличаться в
Реально объем работы увеличивается раз в 5
AmdY,whirlwind
Именно! Мой вопрос ТСу и советчикам: вы уверены, что задачи, когда вам нужно скрипт для крона вызывать из веб, случаются чаще, чем раз в год, и что это правильно?
-~{}~ 03.04.10 03:01:
у меня вот какая аллегория родилась
вы хотите мухи и котлеты положить в один пакет, но котлеты должны остаться съедобными!
вы кладете каждую котлету и каждую муху в специальные маленькие баночки, которые вместе формируют сложную красивую 3-d мозаику
а можно просто взять 2 пакета, и для каждого типа вызова писать отдельный маленький скрипт
Да, я понимаю и уточняю, что конкретно в моих задачах такого не бывает.
>в общем экономическом случае
Ради одной задачи в 2 года - надо ли вводить прослойку для всех вызовов?
Каждый описанный случай - или редкая задача (обработка одновременно и json, и формы), или чистое искусство (удобней для тестов), или по определению глупость (хостинг без крона, как MySQL-совместимая БД на чистом PHP).
В случае с json можно добавить фильтр/маппер/модель/парсер, который заполнит данными осмысленные объект(ы).
А класс доступа надо написать/изучить, думать о нем, дебажить, и выполнять при каждом вызове.
>цена разработки гибкой системы может отличаться в
Реально объем работы увеличивается раз в 5
AmdY,whirlwind
Именно! Мой вопрос ТСу и советчикам: вы уверены, что задачи, когда вам нужно скрипт для крона вызывать из веб, случаются чаще, чем раз в год, и что это правильно?
-~{}~ 03.04.10 03:01:
у меня вот какая аллегория родилась
вы хотите мухи и котлеты положить в один пакет, но котлеты должны остаться съедобными!
вы кладете каждую котлету и каждую муху в специальные маленькие баночки, которые вместе формируют сложную красивую 3-d мозаику
а можно просто взять 2 пакета, и для каждого типа вызова писать отдельный маленький скрипт