Ценность таких статей, я считаю, даже не в том, что это очередное, казалось бы, очевидное предупреждение из разряда "мойте руки перед едой", "будьте осторожны, работая с прокси-моделями" или "внимательнее читайте документацию". Ценность в том, что такие статьи должны (будут теперь) гуглиться по фразе "edit: editing failed" и спасать отчаявшихся :)
Хорошо, а что тогда вы называете необходимость для регрессии? Что означаеет ваше утверждение о том, что 3 точки - необходимый минимум для нелинейной регрессии?
Полностью согласен. Кстати, это работало бы и для автора тоже. Если бы ему нужно было доказать, что он нашёл уязвимость 2 месяца назад, то уже 2 месяца назад он мог бы написать текст с кратким описанием и залить в любой комментарий на хабре его хеш.
Кстати, раз уж пошла такая пьянка, я тоже кое-что нашёл, и мог бы раскрыть уже сегодня, 24.09.2024, но не буду, а пока:
допустим у меня есть чекбокс и текстовое поле, которое должно быть доступно для редактирования (enabled) только если галочка стоит; а если она не стоит, то текстовое поле должно быть пустое. Так вот, где эта логика должна быть прописана, в M, V или C?
допустим, у меня одна и та же информация отображается одновременно и в таблице, и в списке; если в таблице выбрана какая-то строка - где должна информация об этом выделении храниться, в M, V или C?
Ещё пара замечаний "на полях" после (очередного) прочтения этой шикарной статьи:
Модули должны взаимодействовать друг с другом лишь на уровне абстрактных интерфейсов (Dependency Inversion Principle).
Формально говоря, это, конечно, "по классике" входит в DIP, но только потому, что лишней буквы в SOLID не нашлось. Взаимодействие на уровне абстрактных интерфейсов, а не реализаций - в чём тут инверсия то? На мой взгляд, это самая большая проблема такой идеи, как SOLID.
Вместо Предоставляемого Интерфейса (Provided Interface) используются Требуемые Интерфейсы (RequiredInterface).
А вот именно это - как раз и есть главная часть Dependency Inversion Principle, именно тут и инверсия направления стрелочек появляется на диаграммах.
Слушайте, ну это какой-то треш, а не статья, как по мне! Мерить сложность в строках данных, которых 77000 - это такое себе. А говорить про Excel, как про "инструмент, в котором можно сделать что угодно", хотя в нём нельзя нормально прозумить туда-сюда график - это надо сильно постараться натянуть сову на глобус!
Тут можно сказать лишь одно: архитектура, в которой один модуль (Вид или Контроллер), должен «лезть» внутрь другого модуля (доменной модели) и искать там для себя данные или объекты для изменения очень нехорошо «пахнет». Получается что Вид и Контроллер зависят от деталей реализации доменной модели, и если структура этой самой модели изменится, то придется переделывать весь пользовательский интерфейс.
В порядке размышлений. А может быть в этом ничего плохого нет? В моих задачах Вид всё-таки является отражением в интерфейсе именно доменной Модели, которая, в свою очередь, должна отражать реальность. Поэтому если мы решили переделать доменную Модель, чаще всего и Вид изменяется тоже.
В этом случае кажется допустимым, чтобы какой-то Вид непосредственно привязывался к какой-то структурной части Модели, а не требовал обязательно вынести интерфейс к этой части в Фасад.
Я просто стараюсь придерживаться того же самого подхода, какой был проявлен в самом тексте. На мой взгляд, куча эмоций именно там. А что касается вашего вопроса, то конкретно мне он постоянно вредит своими рекомендациями, которые или заставляют меня тратить мыслетопливо на противодействие проталкиваемой политической повестке, или призваны заманить меня поддаться и пропрокрастинировать "всего-лишь ещё 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).
Я когда объясняю суть транзистора детям, вспоминаю свой собственный путь к пониманию и всегда начинаю с очень простой абстракции - выключателя света в комнате, потом плавно перехожу к тому, что хорошо бы выключателем рулить не пальцем, а электричеством, и потом ещё плавнее перехожу к тому, чтобы рулить зарядом (напряжением) или током. Поэтому, по моему опыту, заходить лучше через полевой транзистор в режиме ключа, его дети понимают быстрее.
Спасибо за статью, очень люблю эту тему. Рекомендую интересующимся не только вбить уравнения куда-то, но и попробовать их решить самостоятельно (численно), заодно и подумать, как именно правильно решать, чтобы было консервативно по импульсам и энергии.
По деталям: вот тут, кажется, надо мельчить шаг, чтобы не происходило такого гравитационного "отталкивания" :)
На первый поверхностный взгляд, автор исходной статьи сначала пытается пришить к рассматриваемому вопросу грубыми нитками концепцию ООП, а потом удивляется, что она не очень хорошо пришивается.
Не имея потребности в незаконном обогащении, чувствую, однако, определённый дискомфорт от того, что кто-то может отправить мне перевод и доставить проблемы. Может быть имеет смысл написать у себя в соцсетях "приму в дар переводы по номеру телефона от незнакомых лиц, спасибо заранее"? Может хотя бы тогда необходимость организации обратного перевода станет проблемой того, кто её породил? Ещё раз: я не против вернуть, мне чужого не надо, но почему за чужую ошибку должен платить я?
Ценность таких статей, я считаю, даже не в том, что это очередное, казалось бы, очевидное предупреждение из разряда "мойте руки перед едой", "будьте осторожны, работая с прокси-моделями" или "внимательнее читайте документацию". Ценность в том, что такие статьи должны (будут теперь) гуглиться по фразе "
edit: editing failed" и спасать отчаявшихся :)Хорошо, а что тогда вы называете необходимость для регрессии? Что означаеет ваше утверждение о том, что 3 точки - необходимый минимум для нелинейной регрессии?
а что именно вы называете "достаточностью" для регрессии?
Я хочу нелинейную регрессию, например, полиномом 4 степени. Тоже хватит 3 точек?
Почему эта статья относится к дата-сайнс или к дата-майнинг?
Спасибо, интересно! Но тут должен был быть lisinyt из ютуба с голосом Дроздова, тогда был бы полный ASMR :)
Полностью согласен. Кстати, это работало бы и для автора тоже. Если бы ему нужно было доказать, что он нашёл уязвимость 2 месяца назад, то уже 2 месяца назад он мог бы написать текст с кратким описанием и залить в любой комментарий на хабре его хеш.
Кстати, раз уж пошла такая пьянка, я тоже кое-что нашёл, и мог бы раскрыть уже сегодня, 24.09.2024, но не буду, а пока:
md5: 686a2cccec2d3a53fbfce858cb697a39
sha1: 96bfd73c21a28ebdbd5acbcc63732888da30da97
На "подумать" для желающих:
допустим у меня есть чекбокс и текстовое поле, которое должно быть доступно для редактирования (enabled) только если галочка стоит; а если она не стоит, то текстовое поле должно быть пустое. Так вот, где эта логика должна быть прописана, в M, V или C?
допустим, у меня одна и та же информация отображается одновременно и в таблице, и в списке; если в таблице выбрана какая-то строка - где должна информация об этом выделении храниться, в M, V или C?
Ещё пара замечаний "на полях" после (очередного) прочтения этой шикарной статьи:
Формально говоря, это, конечно, "по классике" входит в DIP, но только потому, что лишней буквы в SOLID не нашлось. Взаимодействие на уровне абстрактных интерфейсов, а не реализаций - в чём тут инверсия то? На мой взгляд, это самая большая проблема такой идеи, как SOLID.
А вот именно это - как раз и есть главная часть Dependency Inversion Principle, именно тут и инверсия направления стрелочек появляется на диаграммах.
Слушайте, ну это какой-то треш, а не статья, как по мне! Мерить сложность в строках данных, которых 77000 - это такое себе. А говорить про Excel, как про "инструмент, в котором можно сделать что угодно", хотя в нём нельзя нормально прозумить туда-сюда график - это надо сильно постараться натянуть сову на глобус!
В порядке размышлений. А может быть в этом ничего плохого нет? В моих задачах Вид всё-таки является отражением в интерфейсе именно доменной Модели, которая, в свою очередь, должна отражать реальность. Поэтому если мы решили переделать доменную Модель, чаще всего и Вид изменяется тоже.
В этом случае кажется допустимым, чтобы какой-то Вид непосредственно привязывался к какой-то структурной части Модели, а не требовал обязательно вынести интерфейс к этой части в Фасад.
Я просто стараюсь придерживаться того же самого подхода, какой был проявлен в самом тексте. На мой взгляд, куча эмоций именно там. А что касается вашего вопроса, то конкретно мне он постоянно вредит своими рекомендациями, которые или заставляют меня тратить мыслетопливо на противодействие проталкиваемой политической повестке, или призваны заманить меня поддаться и пропрокрастинировать "всего-лишь ещё 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).
Я когда объясняю суть транзистора детям, вспоминаю свой собственный путь к пониманию и всегда начинаю с очень простой абстракции - выключателя света в комнате, потом плавно перехожу к тому, что хорошо бы выключателем рулить не пальцем, а электричеством, и потом ещё плавнее перехожу к тому, чтобы рулить зарядом (напряжением) или током. Поэтому, по моему опыту, заходить лучше через полевой транзистор в режиме ключа, его дети понимают быстрее.
Спасибо за статью, очень люблю эту тему. Рекомендую интересующимся не только вбить уравнения куда-то, но и попробовать их решить самостоятельно (численно), заодно и подумать, как именно правильно решать, чтобы было консервативно по импульсам и энергии.
По деталям: вот тут, кажется, надо мельчить шаг, чтобы не происходило такого гравитационного "отталкивания" :)
На первый поверхностный взгляд, автор исходной статьи сначала пытается пришить к рассматриваемому вопросу грубыми нитками концепцию ООП, а потом удивляется, что она не очень хорошо пришивается.
Не имея потребности в незаконном обогащении, чувствую, однако, определённый дискомфорт от того, что кто-то может отправить мне перевод и доставить проблемы. Может быть имеет смысл написать у себя в соцсетях "приму в дар переводы по номеру телефона от незнакомых лиц, спасибо заранее"? Может хотя бы тогда необходимость организации обратного перевода станет проблемой того, кто её породил? Ещё раз: я не против вернуть, мне чужого не надо, но почему за чужую ошибку должен платить я?