В Yii выборка самых-самых простых моделей, унаследованных от CActiveRecord, с 1-2 varchar полями, займет у вас порядка 20-30MB на массив из 10 записей.
Порядок потребления памяти к общему числу загруженных моделей полагаю вы можете сами оценить.
Потому даже сами разработчики Yii как правило не рекомендуют использовать массовую выборку в среднем более чем на 10 записях.
DAO и модели, если меня не подводит разум, совершенно разные вещи.
DAO обеспечивает общую абстракцию к БД, а не к конкретным таблицам и тем более логике моделей.
С оглядкой на AR в Yii, который так же возвращает массив моделей при выборке нескольких записей, т.е. не подходит для больших выборок, порой приходится использовать и подобные решения. Собственно даже в Yii подобный итератор реализуется довольно просто, разница от приведенного кода будет не очень большой.
Честно говоря ожидал увидеть какие-то сравнения и бенчмарки, а не просто описание мана. Не убедило.
По опыту скажу что на отдельным местах, особенно при большой выборке, mysqli выигрывает и по скорости и по потреблению памяти, так что «не убедило».
Удобство в отдельных функциях — да, но никак не «используйте везде».
Полагаю что всё же наоброт.
Я не говорю про то, как и где можно что-то перезаписать. Как я сказал в этом комментарии, при использовании подхода:
foreach ($items as $key=>$item) {
$items[$key] += 2;
}
увеличивается потребление памяти.
Еще раз: ничего про присвоение переменных за скобками цикла я не говорил.
А то что написали вы — очевидно, правда с уточнением, что остается только переменная $key, которая была записана в последней итерации. Массив $items уже был. Ничего «багнутого» тут нет.
Со своей стороны я могу только пожелать вам успехов в реализации подобного подхода.
Уверен, что если вы изобрели новый прекрасный метод разработки решающий все те проблемы для борьбы с которыми и используют ООП подход, то весь цивилизованный и разумный мир последует за вами.
Если следовать вашей логике, сохраняя поток «метафор», то в реальной жизни в принципе не нужны коробки разных размеров, можно взять одну коробку одного размера, приделать ей моторчик, колеса и ручку сверху, а потом этой коробкой заменять автомобиль, портфель, грузовик (просто побольше коробок взять) и дом. Ведь универсально же.
Не буду втягиваться диалог корректности этой метафоры, но в данном случае я скорее буду полагаться на опыт большого числа инженеров.
То что ваши задачи позволяли пока вам универсально решать всё при помощи «коробки», еще не значит что вам не встретятся задачи, где ее будет либо недостаточно, либо она будет избыточна.
Я всячески приветствую критику, однако всё же она должна быть конструктивной, чтобы не быть голословной.
Если вам есть что предложить/поправить/внести своё — предлагайте, давайте вместе делать материал более качественным и полезным для читателей. На мой взгляд это куда более грамотный подход нежели просто отписаться «у вас всё не так, как думаю я».
Как я уже говорил, это лишь небольшие метафоры, если снабдить это иллюстрациями, добавить разбавить слегка кодом и примерами — то смысл в этой статье теряется напрочь, потому что получится книга, которую указали вот в этом комментарии. Еще раз замечу — это не статья чтобы изучать паттерны, это лишь небольшое ознакомление с тем, что они иногда описывают в реальном мире.
1. State
Во многих метафорах не говорится о том что выделять в отдельных объект, потому что это уже более предметная область. Так то ведь можно такой state даже в синглтон загнать. Главная цель была именно понять что паттерн делает, а именно меняет состояние объекта.
2. Chain of responsibility
К сожалению не смог найти метафору попроще. Возможно предложите вы — поправлю.
3. Strategy
Возьмите классический пример — валидатор. Вы используете только метод validate, а на основе параметров, вроде ('not_empty') паттерн сам производит действия, но метод который вы используете извне, везде только validate. Так что как и было сказано в описании — задаются лишь параметры, а стратегию (конкретный метод) реализует уже сам паттерн.
4. Command
Возможно некорректно выразился. У вас в пылесосе, по своей сути, точно такой же механизм как в выключателе света — соединитель/разъединитель двух проводков. Имелось ввиду именно это.
Какой именно пример вы имеете ввиду насчет зарплаты? Опять же если есть что-то попроще и понятнее — исправить статью не сложно.
5. Decorator.
А чем лучше пример с пиццей? Просто не совсем могу понять ваш ход мыслей.
6. Proxy
Чем пример с заместителем будет лучше? Полагаю если вы попробуете описать тот же принцип просто применив слово заместитель, то ничего не изменится. Могу конечно ошибаться, жду пример если это не так.
Тогда бы получилось не совсем корректно. Hierarchical visitor должен пройти по каждому элементу один раз, а у нас сейчас с лицензиями человека могут «футболить» по отдельным кабинетам несколько раз )
Порядок потребления памяти к общему числу загруженных моделей полагаю вы можете сами оценить.
Потому даже сами разработчики Yii как правило не рекомендуют использовать массовую выборку в среднем более чем на 10 записях.
DAO обеспечивает общую абстракцию к БД, а не к конкретным таблицам и тем более логике моделей.
По опыту скажу что на отдельным местах, особенно при большой выборке, mysqli выигрывает и по скорости и по потреблению памяти, так что «не убедило».
Удобство в отдельных функциях — да, но никак не «используйте везде».
Я не говорю про то, как и где можно что-то перезаписать. Как я сказал в этом комментарии, при использовании подхода:
foreach ($items as $key=>$item) {
$items[$key] += 2;
}
увеличивается потребление памяти.
Еще раз: ничего про присвоение переменных за скобками цикла я не говорил.
А то что написали вы — очевидно, правда с уточнением, что остается только переменная $key, которая была записана в последней итерации. Массив $items уже был. Ничего «багнутого» тут нет.
Уверен, что если вы изобрели новый прекрасный метод разработки решающий все те проблемы для борьбы с которыми и используют ООП подход, то весь цивилизованный и разумный мир последует за вами.
Не буду втягиваться диалог корректности этой метафоры, но в данном случае я скорее буду полагаться на опыт большого числа инженеров.
То что ваши задачи позволяли пока вам универсально решать всё при помощи «коробки», еще не значит что вам не встретятся задачи, где ее будет либо недостаточно, либо она будет избыточна.
Объясните пожалуйста, если не сложно.
Если вам есть что предложить/поправить/внести своё — предлагайте, давайте вместе делать материал более качественным и полезным для читателей. На мой взгляд это куда более грамотный подход нежели просто отписаться «у вас всё не так, как думаю я».
Как я уже говорил, это лишь небольшие метафоры, если снабдить это иллюстрациями, добавить разбавить слегка кодом и примерами — то смысл в этой статье теряется напрочь, потому что получится книга, которую указали вот в этом комментарии. Еще раз замечу — это не статья чтобы изучать паттерны, это лишь небольшое ознакомление с тем, что они иногда описывают в реальном мире.
Во многих метафорах не говорится о том что выделять в отдельных объект, потому что это уже более предметная область. Так то ведь можно такой state даже в синглтон загнать. Главная цель была именно понять что паттерн делает, а именно меняет состояние объекта.
2. Chain of responsibility
К сожалению не смог найти метафору попроще. Возможно предложите вы — поправлю.
3. Strategy
Возьмите классический пример — валидатор. Вы используете только метод validate, а на основе параметров, вроде ('not_empty') паттерн сам производит действия, но метод который вы используете извне, везде только validate. Так что как и было сказано в описании — задаются лишь параметры, а стратегию (конкретный метод) реализует уже сам паттерн.
4. Command
Возможно некорректно выразился. У вас в пылесосе, по своей сути, точно такой же механизм как в выключателе света — соединитель/разъединитель двух проводков. Имелось ввиду именно это.
Какой именно пример вы имеете ввиду насчет зарплаты? Опять же если есть что-то попроще и понятнее — исправить статью не сложно.
5. Decorator.
А чем лучше пример с пиццей? Просто не совсем могу понять ваш ход мыслей.
6. Proxy
Чем пример с заместителем будет лучше? Полагаю если вы попробуете описать тот же принцип просто применив слово заместитель, то ничего не изменится. Могу конечно ошибаться, жду пример если это не так.