Тут можно сказать лишь одно: архитектура, в которой один модуль (Вид или Контроллер), должен «лезть» внутрь другого модуля (доменной модели) и искать там для себя данные или объекты для изменения очень нехорошо «пахнет». Получается что Вид и Контроллер зависят от деталей реализации доменной модели, и если структура этой самой модели изменится, то придется переделывать весь пользовательский интерфейс.
В порядке размышлений. А может быть в этом ничего плохого нет? В моих задачах Вид всё-таки является отражением в интерфейсе именно доменной Модели, которая, в свою очередь, должна отражать реальность. Поэтому если мы решили переделать доменную Модель, чаще всего и Вид изменяется тоже.
В этом случае кажется допустимым, чтобы какой-то Вид непосредственно привязывался к какой-то структурной части Модели, а не требовал обязательно вынести интерфейс к этой части в Фасад.
Я просто стараюсь придерживаться того же самого подхода, какой был проявлен в самом тексте. На мой взгляд, куча эмоций именно там. А что касается вашего вопроса, то конкретно мне он постоянно вредит своими рекомендациями, которые или заставляют меня тратить мыслетопливо на противодействие проталкиваемой политической повестке, или призваны заманить меня поддаться и пропрокрастинировать "всего-лишь ещё 5 минуток". Да, вы можете надо мной смеяться, но я для себя ощущаю это как существенный и объективный вред.
ListView отображает список переменных (слева), а TextView показывает значение выбранной переменной (справа)… Моделью для этих видов служит экземпляр класса «Inspector»… Отдельный класс «Inspector» является посредником или фильтром для того чтобы обеспечивать доступ к любому свойству любого объекта. Использование промежуточных объектов между View и "actual" models является типичным способом изолировать поведение отображения от модели приложения
Вот тут у меня есть такой частный вопрос. Где-то есть какая-то переменная-индекс, которая хранит текущий выбранный элемент в этом ListView. Вы как считаете, она где? Только внутри самого ListView? Внутри упомянутого посредника Inspector? Внутри той domain-модели, на которую ссылается Inspector? Это может стать важным для организации master-detail связей с использованием подобных ListView.
Спасибо, отличная статья! Пожалуй, это лучшая статья по MVC, которая мне встречалась. Большинство других источников пишут (сами того не подозревая) про "MVC-в-веб", "MVC-в-java", "MVC-в-yii". Ваша статья выходит уровнем выше. Практически нигде и никогда пользователь не оперирует напрямую моделью. Однако можно консоль с доступом к объектной модели считать прямой связью пользователя и модели (но если неприятно, можно консоль считать другим контроллером), мы пишем gui на python, нам это актуально. Иногда некоторые части нашего кода, в которые меня заносит, выглядят как карго-культ MVC. Прямо чётко видно, что их начинал писать кто-то, кто понимал суть MVC, а потом он ушёл, а продолжатели взяли внешние признаки, шелуху, а идею не поняли. И получается именно что карго-культ MVC вместо самого MVC. И ведь люди не со зла это делали, а просто не понимали, как правильно, а как неправильно. Причём важнее понимать, как неправильно, - потому что тогда можно пойти к коллеге и посоветоваться, как правильно. Нужен какой-то очень простой критерий, который позволил бы любому человеку, который работает с GUI, быстро понять, что он делает что-то не так. И у меня есть идея. Надо поставить ВСЕМ разработчикам конкретную задачу: вся функциональность, которая пишется, должна работать БЕЗ View (в нащем случае gui - без создания виджетов). То есть прямо должен быть какой-то метод (мы его потом в тестах можем вызывать), который выполняет 100% возможных действий пользователя, вызывая какой-то код без создания виджета. И этот метод (раз View нет, то нет и работающих обработчиков gui-событий) - это точно не метод контроллера. По-моему, соблюдение этого критерия достаточно просто проверить. Да, это может привести к тому, что код попадёт в контроллер вместо модели, но это и обнаружить легче, и исправить потом.
Но при этом Модель в «MVC схеме» вовсе не тождественна доменной модели (которая может быть сколь угодно сложной и состоять из множества объектов), а является всего лишь ее интерфейсом и фасадом.
Любопытно, ведь это по факту то, что принято называть ViewModel? Получается MVVM ближе к исходному понимаю создателей MVC?
Вместо того чтобы нужным образом всего лишь интерпретировать и адаптировать имеющиеся доменные данные с помощью моделей-посредников их начинают копировать в эти модели-посредники
Я бы сказал, что это вопрос двух разных ролей, которые в общепринятом (не значит "правильном" или "исходном"!) понимании назначаются модели. Модель - как хранитель данных и обеспечение всей бизнес-логики этих данных. И модель - как источник данных для Представления и всех прочих. Естественным образом кажется, что первое - это настоящая Model, а второе - ViewModel, и именно вторая должна стремиться к тому, чтобы по возможности хранить только ссылки, а не копии. Собственно, об этой путанице вы дальше и пишете.
От блокировки ютуба лично я, разумеется, в ближнесрочной перспективе пострадаю и качество моей работы и жизни ухудшится. Но я считаю, что на проблему надо всегда стараться смотреть шире. Почему-то считается, что ютуб - это однонаправленный процесс, в котором единственную активную роль играет пользователь. В этом идеальном мире есть неразумный ютуб, и разумный пользователь, который всегда обладает достаточной рациональностью и волей, чтобы получать ту информацию, которая ему нужна, и не получать ту, которая ему не нужна. В этом красивом мире пользователь пользуется ютубом для достижения своих целей, при этом у ютуба нет никаких свои целей и возможности их преследовать. Слушайте, ну это же наивно! Когда ты используешь ютуб, всегда ВСЕГДА одновременно ютуб использует тебя. А ещё твою маму, твою бабушку, твоего соседа по лестничной площадке. Вы точно не хотите ничего делать с тем, кого и для каких целей использует ютуб?
[...] кнопки перехода на композиции могут так же являться кнопками перемотки вперед/назад текущей композиции. Итого, имея одно и то же представление, мы можем изменить его поведение просто заменой контроллера [...] оба контроллера используют одно и то же представление
Мне не нравится так думать. Если кнопка перехода между треками получает (с точки зрения пользователя) ещё и функциональность перемотки вперёд/назад внутри одной композиции, то её внешний вид должен измениться, чтобы отразить изменившуюся функциональность. В этом случае я скажу, то всё-таки представление тоже изменилось вместе с контроллером.
В MVC мы можем заменять не только контроллеры у представления, но и представления у одного контроллера
Как раз этот пример, мне кажется, иллюстрирует противоположное. Нажатие на кнопку "влево" в представлении "плитка" будет делать совсем не то, что в представлении "таблица".
На всякий случай, я - из десктопа и соответственно из DL-MVVM мира (DL - data layer).
Я когда объясняю суть транзистора детям, вспоминаю свой собственный путь к пониманию и всегда начинаю с очень простой абстракции - выключателя света в комнате, потом плавно перехожу к тому, что хорошо бы выключателем рулить не пальцем, а электричеством, и потом ещё плавнее перехожу к тому, чтобы рулить зарядом (напряжением) или током. Поэтому, по моему опыту, заходить лучше через полевой транзистор в режиме ключа, его дети понимают быстрее.
Спасибо за статью, очень люблю эту тему. Рекомендую интересующимся не только вбить уравнения куда-то, но и попробовать их решить самостоятельно (численно), заодно и подумать, как именно правильно решать, чтобы было консервативно по импульсам и энергии.
По деталям: вот тут, кажется, надо мельчить шаг, чтобы не происходило такого гравитационного "отталкивания" :)
На первый поверхностный взгляд, автор исходной статьи сначала пытается пришить к рассматриваемому вопросу грубыми нитками концепцию ООП, а потом удивляется, что она не очень хорошо пришивается.
Не имея потребности в незаконном обогащении, чувствую, однако, определённый дискомфорт от того, что кто-то может отправить мне перевод и доставить проблемы. Может быть имеет смысл написать у себя в соцсетях "приму в дар переводы по номеру телефона от незнакомых лиц, спасибо заранее"? Может хотя бы тогда необходимость организации обратного перевода станет проблемой того, кто её породил? Ещё раз: я не против вернуть, мне чужого не надо, но почему за чужую ошибку должен платить я?
Разве это имеет отношение к truthy и falsy? На первый взгляд тут просто вычисление значения логического выражения, и использование тождества "x == True === x"?
Как будто есть очевидный ответ на ваш вопрос. Например, стали эффективнее те, кто писал рефераты и дипломы для студентов. Другими словами, стали эффективнее те и в тех задачах, которые сводились к подстановке наиболее вероятных слов. Не хочу выглядеть так, будто я пишу это свысока - в моей работе тоже такого полно. Но надо понимать, что чем более эффективным вас делает чатжпт, тем больше это говорит о том, чем именно вы занимаетесь.
Любопытно, что автор статьи упоминает блокчейн, но не упоминает 3д-печать, как ещё один пример хайпа. Вообще-то это просто 3д-принтер, чтобы по-быстрому сломанную пластиковую штуку наладить, которую отдельно не продают. Но назови это - аддитивные технологии, и можно стричь бабло и сидеть в анатомическом кресле, рисуя презентации. Правда, при этом в 5 метрах от твоего кабинета будет течь слив в унитазе, но напечатать заменить сломанную пластиковую деталь из него на своих принтерах ты не сможешь - это стейкхолдерам не продать...
Но теперь мы можем попросить git помочь: сортировать ветки по objectsize, authordate, committerdate, creatordate, или taggerdate опцией --sort, или установить значение опции по умолчанию параметром конфигурации branch.sort
Понимаю, что сейчас напишу очень спорный комментарий, но мнение своё выскажу. На дворе 21 век, мы через голосовые интерфейсы общаемся с генеративными сетями, вытаскивающими для нас информацию из поисковиков - но при этом с гитом нам всё равно предлагают общаться через консоль? Реально вы серьёзно? Не для автоматизации рутинных действий и последовательностей команд в "моё утро начинается с кофе и гит фетч ребейз", а вот для всего остального? И мне действительно предлагают помнить или искать эти опции у сортировки по разным атрибутам? Или может всё-таки просто мышкой сортировать и фильтровать табличные данные, к чему (к работе со структурированными табличными данными) должен быть автоматически привычен любой сегодня человек? Оно ведь ещё и запомнит, по какому столбцу я сортировал и порядок сортировки, безо всяких параметров конфигурации...
Смешались в кучу кони, люди... Автора можно похвалить за объёмный труд, но рекомендовать для изучения материала эту статью я бы не стал из-за отсутствия системности. Несколько вещей, которые бросились в глаза:
Английский текст в таблицах, зачем? Вы же на русском языке статью пишете?
Нельзя говорить, что лучшие алгоритмы имеют константную сложность, а худшие алгоритмы - квадратичную. Квадратичный алгоритм факторизации был бы, мягко говоря, нехудшим.
Зря нет акцента на том, что каждая структура данных - под свою задачу. Когда человеку нужен вектор, а когда список? Зачем у вас и односвязные и двусвязные списки, когда какой выбирать?
Очень зря, я считаю, в одну кучу мешаются структуры данных (data structures) и абстрактные типы данных (abstract data types). Стеки и очереди мешаются со списками, а множества и словари - с хеш-таблицами. Бардак.
Бессистемность в коде. Очереди и связные списки вы на питоне написали сами, а что ж на set то прохалтурили? В питоне не только с множествами просто и приятно!
Не указано сравнительное потребление памяти той или иной структурой
Вообще не понятно, что такое куча, и зачем она
Кому и зачем вообще все эти сортировки нужны?
Бессистемность в целом: какие-то самые общие слова про некоторые структуры данных, вообще не упомянуты некоторые очень важные структуры данных, но - внезапно! - столько текста про несчастного Дейкстру. Это действительно для шпаргалки надо? Или просто текст про Дейкстру был уже написан и выкидывать жалко его было?
Очень неприятно приносить категорически отрицательные комментарии. Но статью считаю местами совершенно неправильной и методически вредной. Вот здесь практически всё или неверно, или вводит в заблуждение того, кто хочет разобраться:
В порядке размышлений. А может быть в этом ничего плохого нет? В моих задачах Вид всё-таки является отражением в интерфейсе именно доменной Модели, которая, в свою очередь, должна отражать реальность. Поэтому если мы решили переделать доменную Модель, чаще всего и Вид изменяется тоже.
В этом случае кажется допустимым, чтобы какой-то Вид непосредственно привязывался к какой-то структурной части Модели, а не требовал обязательно вынести интерфейс к этой части в Фасад.
Я просто стараюсь придерживаться того же самого подхода, какой был проявлен в самом тексте. На мой взгляд, куча эмоций именно там. А что касается вашего вопроса, то конкретно мне он постоянно вредит своими рекомендациями, которые или заставляют меня тратить мыслетопливо на противодействие проталкиваемой политической повестке, или призваны заманить меня поддаться и пропрокрастинировать "всего-лишь ещё 5 минуток". Да, вы можете надо мной смеяться, но я для себя ощущаю это как существенный и объективный вред.
Вот тут у меня есть такой частный вопрос. Где-то есть какая-то переменная-индекс, которая хранит текущий выбранный элемент в этом ListView. Вы как считаете, она где? Только внутри самого ListView? Внутри упомянутого посредника Inspector? Внутри той domain-модели, на которую ссылается Inspector? Это может стать важным для организации master-detail связей с использованием подобных ListView.
Спасибо, отличная статья! Пожалуй, это лучшая статья по MVC, которая мне встречалась. Большинство других источников пишут (сами того не подозревая) про "MVC-в-веб", "MVC-в-java", "MVC-в-yii". Ваша статья выходит уровнем выше.
Практически нигде и никогда пользователь не оперирует напрямую моделью. Однако можно консоль с доступом к объектной модели считать прямой связью пользователя и модели (но если неприятно, можно консоль считать другим контроллером), мы пишем gui на python, нам это актуально.
Иногда некоторые части нашего кода, в которые меня заносит, выглядят как карго-культ MVC. Прямо чётко видно, что их начинал писать кто-то, кто понимал суть MVC, а потом он ушёл, а продолжатели взяли внешние признаки, шелуху, а идею не поняли. И получается именно что карго-культ MVC вместо самого MVC.
И ведь люди не со зла это делали, а просто не понимали, как правильно, а как неправильно. Причём важнее понимать, как неправильно, - потому что тогда можно пойти к коллеге и посоветоваться, как правильно. Нужен какой-то очень простой критерий, который позволил бы любому человеку, который работает с GUI, быстро понять, что он делает что-то не так. И у меня есть идея.
Надо поставить ВСЕМ разработчикам конкретную задачу: вся функциональность, которая пишется, должна работать БЕЗ View (в нащем случае gui - без создания виджетов). То есть прямо должен быть какой-то метод (мы его потом в тестах можем вызывать), который выполняет 100% возможных действий пользователя, вызывая какой-то код без создания виджета. И этот метод (раз View нет, то нет и работающих обработчиков gui-событий) - это точно не метод контроллера. По-моему, соблюдение этого критерия достаточно просто проверить. Да, это может привести к тому, что код попадёт в контроллер вместо модели, но это и обнаружить легче, и исправить потом.
Любопытно, ведь это по факту то, что принято называть ViewModel? Получается MVVM ближе к исходному понимаю создателей MVC?
Я бы сказал, что это вопрос двух разных ролей, которые в общепринятом (не значит "правильном" или "исходном"!) понимании назначаются модели. Модель - как хранитель данных и обеспечение всей бизнес-логики этих данных. И модель - как источник данных для Представления и всех прочих. Естественным образом кажется, что первое - это настоящая Model, а второе - ViewModel, и именно вторая должна стремиться к тому, чтобы по возможности хранить только ссылки, а не копии. Собственно, об этой путанице вы дальше и пишете.
От блокировки ютуба лично я, разумеется, в ближнесрочной перспективе пострадаю и качество моей работы и жизни ухудшится. Но я считаю, что на проблему надо всегда стараться смотреть шире. Почему-то считается, что ютуб - это однонаправленный процесс, в котором единственную активную роль играет пользователь. В этом идеальном мире есть неразумный ютуб, и разумный пользователь, который всегда обладает достаточной рациональностью и волей, чтобы получать ту информацию, которая ему нужна, и не получать ту, которая ему не нужна. В этом красивом мире пользователь пользуется ютубом для достижения своих целей, при этом у ютуба нет никаких свои целей и возможности их преследовать.
Слушайте, ну это же наивно! Когда ты используешь ютуб, всегда ВСЕГДА одновременно ютуб использует тебя. А ещё твою маму, твою бабушку, твоего соседа по лестничной площадке. Вы точно не хотите ничего делать с тем, кого и для каких целей использует ютуб?
Мне не нравится так думать. Если кнопка перехода между треками получает (с точки зрения пользователя) ещё и функциональность перемотки вперёд/назад внутри одной композиции, то её внешний вид должен измениться, чтобы отразить изменившуюся функциональность. В этом случае я скажу, то всё-таки представление тоже изменилось вместе с контроллером.
Как раз этот пример, мне кажется, иллюстрирует противоположное. Нажатие на кнопку "влево" в представлении "плитка" будет делать совсем не то, что в представлении "таблица".
На всякий случай, я - из десктопа и соответственно из DL-MVVM мира (DL - data layer).
Я когда объясняю суть транзистора детям, вспоминаю свой собственный путь к пониманию и всегда начинаю с очень простой абстракции - выключателя света в комнате, потом плавно перехожу к тому, что хорошо бы выключателем рулить не пальцем, а электричеством, и потом ещё плавнее перехожу к тому, чтобы рулить зарядом (напряжением) или током. Поэтому, по моему опыту, заходить лучше через полевой транзистор в режиме ключа, его дети понимают быстрее.
Спасибо за статью, очень люблю эту тему. Рекомендую интересующимся не только вбить уравнения куда-то, но и попробовать их решить самостоятельно (численно), заодно и подумать, как именно правильно решать, чтобы было консервативно по импульсам и энергии.
По деталям: вот тут, кажется, надо мельчить шаг, чтобы не происходило такого гравитационного "отталкивания" :)
На первый поверхностный взгляд, автор исходной статьи сначала пытается пришить к рассматриваемому вопросу грубыми нитками концепцию ООП, а потом удивляется, что она не очень хорошо пришивается.
Не имея потребности в незаконном обогащении, чувствую, однако, определённый дискомфорт от того, что кто-то может отправить мне перевод и доставить проблемы. Может быть имеет смысл написать у себя в соцсетях "приму в дар переводы по номеру телефона от незнакомых лиц, спасибо заранее"? Может хотя бы тогда необходимость организации обратного перевода станет проблемой того, кто её породил? Ещё раз: я не против вернуть, мне чужого не надо, но почему за чужую ошибку должен платить я?
Разве это имеет отношение к truthy и falsy? На первый взгляд тут просто вычисление значения логического выражения, и использование тождества "x == True === x"?
Красавцы ребята!
Как будто есть очевидный ответ на ваш вопрос. Например, стали эффективнее те, кто писал рефераты и дипломы для студентов. Другими словами, стали эффективнее те и в тех задачах, которые сводились к подстановке наиболее вероятных слов. Не хочу выглядеть так, будто я пишу это свысока - в моей работе тоже такого полно. Но надо понимать, что чем более эффективным вас делает чатжпт, тем больше это говорит о том, чем именно вы занимаетесь.
По-моему, вы очень здорово ухватили одну из сутей. Оно не может в маловероятное творчество, потому что максимизирует вероятность.
Спасибо за термин, я для себя буду его использовать так: перевёрнутый перцептрон от статистики близости слов на стероидах в виде больших данных.
Любопытно, что автор статьи упоминает блокчейн, но не упоминает 3д-печать, как ещё один пример хайпа. Вообще-то это просто 3д-принтер, чтобы по-быстрому сломанную пластиковую штуку наладить, которую отдельно не продают. Но назови это - аддитивные технологии, и можно стричь бабло и сидеть в анатомическом кресле, рисуя презентации. Правда, при этом в 5 метрах от твоего кабинета будет течь слив в унитазе, но напечатать заменить сломанную пластиковую деталь из него на своих принтерах ты не сможешь - это стейкхолдерам не продать...
мы не допускаем к разработке интерфейсов людей, которые набирают меньше 906090 баллов на https://cantunsee.space/
Понимаю, что сейчас напишу очень спорный комментарий, но мнение своё выскажу. На дворе 21 век, мы через голосовые интерфейсы общаемся с генеративными сетями, вытаскивающими для нас информацию из поисковиков - но при этом с гитом нам всё равно предлагают общаться через консоль? Реально вы серьёзно? Не для автоматизации рутинных действий и последовательностей команд в "моё утро начинается с кофе и гит фетч ребейз", а вот для всего остального? И мне действительно предлагают помнить или искать эти опции у сортировки по разным атрибутам? Или может всё-таки просто мышкой сортировать и фильтровать табличные данные, к чему (к работе со структурированными табличными данными) должен быть автоматически привычен любой сегодня человек? Оно ведь ещё и запомнит, по какому столбцу я сортировал и порядок сортировки, безо всяких параметров конфигурации...
Смешались в кучу кони, люди... Автора можно похвалить за объёмный труд, но рекомендовать для изучения материала эту статью я бы не стал из-за отсутствия системности. Несколько вещей, которые бросились в глаза:
Английский текст в таблицах, зачем? Вы же на русском языке статью пишете?
Нельзя говорить, что лучшие алгоритмы имеют константную сложность, а худшие алгоритмы - квадратичную. Квадратичный алгоритм факторизации был бы, мягко говоря, нехудшим.
Зря нет акцента на том, что каждая структура данных - под свою задачу. Когда человеку нужен вектор, а когда список? Зачем у вас и односвязные и двусвязные списки, когда какой выбирать?
Очень зря, я считаю, в одну кучу мешаются структуры данных (data structures) и абстрактные типы данных (abstract data types). Стеки и очереди мешаются со списками, а множества и словари - с хеш-таблицами. Бардак.
Бессистемность в коде. Очереди и связные списки вы на питоне написали сами, а что ж на set то прохалтурили? В питоне не только с множествами просто и приятно!
Не указано сравнительное потребление памяти той или иной структурой
Вообще не понятно, что такое куча, и зачем она
Кому и зачем вообще все эти сортировки нужны?
Бессистемность в целом: какие-то самые общие слова про некоторые структуры данных, вообще не упомянуты некоторые очень важные структуры данных, но - внезапно! - столько текста про несчастного Дейкстру. Это действительно для шпаргалки надо? Или просто текст про Дейкстру был уже написан и выкидывать жалко его было?
Очень неприятно приносить категорически отрицательные комментарии. Но статью считаю местами совершенно неправильной и методически вредной. Вот здесь практически всё или неверно, или вводит в заблуждение того, кто хочет разобраться: