Простите, но сочувствую вам, что вы в подобной статье нашли столько поводов для негатива и ненависти, что это даже удивляет. Никто не создавал «превосходную степень», не «выставлял минусы плюсами». Речь идет о сухих фактах, а как они могут обернуться для человека, это уже вопрос индивидуальный. «Нож может как спасать жизнь, так и лишать ее».
Не знаю где у вас возникли проблемы, но большая часть перечисленных моментов многих вполне устраивает и они извлекают из них свои плюсы.
Так что скорее я с вами всё же не соглашусь.
В большей или меньшей степени любой человек имеет психические деформации.
Программист — это живой человек, в какой-то степени инженер, «писатель», техник и т.д. Естественно что если существует такое многообразие сторон профессии, то и в смежных профессиях будут подобные эффекты. Однако взять и что-то однозначно отделить невозможно. В статье не идет приписывание «только программистам», но речь идет о том «что бывает с программистами» и почему.
Не каждый инженер имеет особенности «художественного писателя», не всем топ-менеджерам свойственна гиперконцентрация, многие «гуманитарии» могут быть подвержены в определенной степени «инженерному гламуру», но именно подобный набор вполне свойственен программистам.
Не совсем выразился.
«Шоколадка Нестле» и «Шоколадка Альпенгольд». Каждая имеет минимальное число повторений и одинаковый приоритет, соответственно для выбора между ними используется рандом.
Это просто значит что у вас есть дефольтное значение. Возможно, ваша жена никогда не готовила блюда с более чем десятком яиц и вы не покупали их «про запас».
Они имеют место быть, но скорее не как профессиональное качество, а уже как индивидуальные особенности во взаимосвязи с перечисленным.
Детальное обдумывание решений это как раз про «поиск причинно-следственных связей», потому как идет анализ «что, как и зачем».
Раздражение от других людей, которые что-то не умеют, это уже более личное. Люди, которые не планируют как программисты это совершенно обыденное явление. Да и кстати сами программисты не всегда хорошо планируют, они более часто именно анализируют.
Делается просто: создаешь массив переменных которые уже встречались как валидные, для каждой переменной ведешь параметр сколько раз она повторялась и пускаешь по циклу с небольшим рандомом.
Список можно пополнять переменными из ее рассказов что она ела у друзей и что ей понравилось, а также что она могла увидеть по телевизору.
В целом работает. Не забывай ставить низкий приоритет на элементы, которые не подходят под ее режим питания, вроде «На диете я!» )
Небольшое дополнение к последнему пункту топика:
хотя в треде бага и указано, что он закрыт, однако баг сам по себе всё еще существует, однако эксплуатировать его можно немного в другой форме. Дополню более наглядным примером то, что предложил автор в топике:
P.S.: Всё же каждый инструмент должен быть использован по назначению.
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете» (с) С. Макконнелл
Вы правы. Модели предназначены именно для реализации комплексной бизнес-логики, а при выборки значительных размеров, как-правило речь идет о статистических данных, уже должны быть реализованы на более низком уровне.
Использование Domain Object в данном случае может легко превратиться в «забивание гвоздей микроскопом», не говоря уже что вы советуете ее применить даже там, где ее использование часто излишне.
Например даже если вы, как предполагаете, сможете перенести всю дополнительную логику в методы модели, а все данные передавать через параметры метода, то в конце концов вы рискуете получить серьезный «говнокод» вроде
$model->method($param1, $model2, $item3, $controller4)
или же излишнюю унификацию вроде $model->method($all_possible_params);
Каждой логике должно быть своё место, и желание «инкапсулировать всё что можно» как раз часто и приводит к неправильному пониманию и применению ООП.
Вполне живой пример:
if ($user->isAuth()) {
// some profile data
// some statistics data
// display profile form
} else {
// some another html
// display login form
}
Если следовать вашей логике, то мы должны инкапсулировать это логику внутрь Domain Object и сделать что-то вроде
$user->displayForm();
Однако при таком подходе о нормальном MVC можно забыть.
Так что знать про такой хороший подход как Domain Object конечно хорошо, но и его стоит применять с умом.
Пожалуйста укажите ссылку на страницу в приведенной вами книге, которая описывает приведенные вами аргументы, книга сама по себе достаточно объемна и боюсь что вы можете искаженно трактовать ее через призму своего опыта.
Касательно «выноса условий в модель» вы совершенно неправы. Так как do something может содержать работу не только с данными самой модели, но и привлекать сторонние ресурсы (например другие модели, созданные в данном контроллере), которые нельзя инкапсулировать внутрь модели.
Также отдельно хотелось бы услышать что-то менее голословное касательно того, почему использования интерфейса итератора для работы с моделями является «деградацией ООП». То что это используется многими, ясно написано прямо в начале статьи "… продемонстрировать стандартные подходы к решению данной проблемы". Никто не претендовал на открытие Америки.
Судя по листингу, никакого доступа к именно модели данных тут не происходит, а перебирать поля из базы не является проблемой.
Возможна ли какая-то реализация во view с вызовом метода?
Например что-то вроде:
<ul>
{% for user in users %}
<li>{{ user.formattedUsername('first_name last_name') }}</li>
{% endfor %}
</ul>
Простите, может быть я не совсем понял ваш пример, но если вам понадобится выбрать большое число записей, то каким образом вы решаете вопрос использования моделей для каждой записи? Просто в приведенном коде это не отображено.
Извиняюсь, попутал с $this->_current_data.
В $this->_result действительно хранятся выбранные записи из базы, еще не преобразованные в массив, однако это самая минимальная жертва производительности и объему выделяемой памяти, и само собой, это гораздо менее накладно, чем хранить массив объектов.
Если посмотрите на код внимательнее, то увидите что в this->_result постоянно хранится только обычный массив атрибутов одной строки выборки, на основе которого по запросу выдается модель. Даже не модель.
Порядок эффективности сильно зависит от того, как вы реализуете модель (работа с атрибутами, объектами, методы и т.д.), потому конкретные тесты вы должно проводить уже на своем участке кода. Если же взять что-то известное, например Yii:
Без итератора: 12 моделей = 28MB потребление памяти для период массовой выборки, дальше пропорциональное увеличение примерно по 2МБ на каждую загруженную модель.
С итератором: 12 моделей = 7MB на модель и итератор, и увеличение числа записей на 1 пропорциональное одной записи в обычном массиве.
По скорости быстродействия итератор выигрывает при использовании clone за счет меньшего числа операций чем в массовой выборке. Если использовать new, то разница существенно ниже.
(Спасибо что прочитали P.S. в статье.) — Данная статья не про то, как надо писать ORM, где и как хранить атрибуты. Речь лишь о способе использования моделей с массовой выборкой.
Тесты проводил.
— Выгода от создания 1 объекта модели вместо 20 копеечная, так как вы заменили new Model() + setAttributes() на clone + setAttributes() + обвязку итератора. Получается, кода выполняется даже больше. clone точно так же, как и new, выделяет память. Где выигрыш?
— Поясните пожалуйста как вы у вас получается что исполнение кода 20-ти моделей у вас меньше, чем исполнение кода одной модели с установкой атрибутов?
Как я и привел в первой реализации, можно создавать вообще только одну модели (без клона), только если она не меняется, если же меняется, то клон всегда быстрее самого new.
В остальном же ваш комментарий чем-то можно резюмировать «Объекты и ORM — зло, пишите нативно». Точно такая же работа происходит в любом языке программирования, везде есть свои затраты и все это прекрасно понимают. Про «золотую пулю» также было сказано в статье, что если вам надо просто — пишите нативно, нужен сложный поддерживаемый код — можете использовать модели.
К тому же, опять же как уже было сказано в статье, всегда за такими участками кода, так как любые обработки из БД с большой выборкой часто потребляют хорошую часть ресурсов — желательно иметь слой кеша.
Если у вас есть какие-то другие «правильные» решение, хотелось бы их услышать.
Этот метод о другом. Он не решает проблему с памятью, а просто откладывает ее. При большой выборке, когда произойдет обход всех записей, вы получите полную коллекцию в $this->_cache, которая по сути будет являться той же самой массовой выборкой.
Не знаю где у вас возникли проблемы, но большая часть перечисленных моментов многих вполне устраивает и они извлекают из них свои плюсы.
Так что скорее я с вами всё же не соглашусь.
Программист — это живой человек, в какой-то степени инженер, «писатель», техник и т.д. Естественно что если существует такое многообразие сторон профессии, то и в смежных профессиях будут подобные эффекты. Однако взять и что-то однозначно отделить невозможно. В статье не идет приписывание «только программистам», но речь идет о том «что бывает с программистами» и почему.
Не каждый инженер имеет особенности «художественного писателя», не всем топ-менеджерам свойственна гиперконцентрация, многие «гуманитарии» могут быть подвержены в определенной степени «инженерному гламуру», но именно подобный набор вполне свойственен программистам.
«Шоколадка Нестле» и «Шоколадка Альпенгольд». Каждая имеет минимальное число повторений и одинаковый приоритет, соответственно для выбора между ними используется рандом.
Детальное обдумывание решений это как раз про «поиск причинно-следственных связей», потому как идет анализ «что, как и зачем».
Раздражение от других людей, которые что-то не умеют, это уже более личное. Люди, которые не планируют как программисты это совершенно обыденное явление. Да и кстати сами программисты не всегда хорошо планируют, они более часто именно анализируют.
Список можно пополнять переменными из ее рассказов что она ела у друзей и что ей понравилось, а также что она могла увидеть по телевизору.
В целом работает. Не забывай ставить низкий приоритет на элементы, которые не подходят под ее режим питания, вроде «На диете я!» )
хотя в треде бага и указано, что он закрыт, однако баг сам по себе всё еще существует, однако эксплуатировать его можно немного в другой форме. Дополню более наглядным примером то, что предложил автор в топике:
P.S.: Всё же каждый инструмент должен быть использован по назначению.
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете» (с) С. Макконнелл
Например даже если вы, как предполагаете, сможете перенести всю дополнительную логику в методы модели, а все данные передавать через параметры метода, то в конце концов вы рискуете получить серьезный «говнокод» вроде
$model->method($param1, $model2, $item3, $controller4)
или же излишнюю унификацию вроде $model->method($all_possible_params);
Каждой логике должно быть своё место, и желание «инкапсулировать всё что можно» как раз часто и приводит к неправильному пониманию и применению ООП.
Вполне живой пример:
Если следовать вашей логике, то мы должны инкапсулировать это логику внутрь Domain Object и сделать что-то вроде
Однако при таком подходе о нормальном MVC можно забыть.
Так что знать про такой хороший подход как Domain Object конечно хорошо, но и его стоит применять с умом.
Касательно «выноса условий в модель» вы совершенно неправы. Так как do something может содержать работу не только с данными самой модели, но и привлекать сторонние ресурсы (например другие модели, созданные в данном контроллере), которые нельзя инкапсулировать внутрь модели.
Также отдельно хотелось бы услышать что-то менее голословное касательно того, почему использования интерфейса итератора для работы с моделями является «деградацией ООП». То что это используется многими, ясно написано прямо в начале статьи "… продемонстрировать стандартные подходы к решению данной проблемы". Никто не претендовал на открытие Америки.
Возможна ли какая-то реализация во view с вызовом метода?
Например что-то вроде:
В $this->_result действительно хранятся выбранные записи из базы, еще не преобразованные в массив, однако это самая минимальная жертва производительности и объему выделяемой памяти, и само собой, это гораздо менее накладно, чем хранить массив объектов.
Порядок эффективности сильно зависит от того, как вы реализуете модель (работа с атрибутами, объектами, методы и т.д.), потому конкретные тесты вы должно проводить уже на своем участке кода. Если же взять что-то известное, например Yii:
Без итератора: 12 моделей = 28MB потребление памяти для период массовой выборки, дальше пропорциональное увеличение примерно по 2МБ на каждую загруженную модель.
С итератором: 12 моделей = 7MB на модель и итератор, и увеличение числа записей на 1 пропорциональное одной записи в обычном массиве.
По скорости быстродействия итератор выигрывает при использовании clone за счет меньшего числа операций чем в массовой выборке. Если использовать new, то разница существенно ниже.
Тесты проводил.
— Выгода от создания 1 объекта модели вместо 20 копеечная, так как вы заменили new Model() + setAttributes() на clone + setAttributes() + обвязку итератора. Получается, кода выполняется даже больше. clone точно так же, как и new, выделяет память. Где выигрыш?
— Поясните пожалуйста как вы у вас получается что исполнение кода 20-ти моделей у вас меньше, чем исполнение кода одной модели с установкой атрибутов?
Как я и привел в первой реализации, можно создавать вообще только одну модели (без клона), только если она не меняется, если же меняется, то клон всегда быстрее самого new.
В остальном же ваш комментарий чем-то можно резюмировать «Объекты и ORM — зло, пишите нативно». Точно такая же работа происходит в любом языке программирования, везде есть свои затраты и все это прекрасно понимают. Про «золотую пулю» также было сказано в статье, что если вам надо просто — пишите нативно, нужен сложный поддерживаемый код — можете использовать модели.
К тому же, опять же как уже было сказано в статье, всегда за такими участками кода, так как любые обработки из БД с большой выборкой часто потребляют хорошую часть ресурсов — желательно иметь слой кеша.
Если у вас есть какие-то другие «правильные» решение, хотелось бы их услышать.