Comments 16
так а что нового в статье? Реализация паттерна типовая, как работать с PyQt наверняка можно найти в гугле. Я не критики, а интереса ради. Просто с питоном не знаком, может что-то важное упустил?
так а что нового в статье?
Возможно, что и ничего.
Дело в том, что пример реализации классической версии MVC для PyQt я писал по просьбе знакомых, которые не нашли ничего подобного в интернете. Если честно, то не нашёл и я. Именно поэтому решил, что статья, в которой присутствует типовая реализация паттерна и основные этапы процесса создания приложения на PyQt, будет полезна. Следствием такого решения является эта публикация.
Согласно архитектуре MVC представление должно быть наблюдателем
Это откуда, если не секрет?
Контроллер реализует паттерн стратегия. Контроллер подключается к представлению для управления его действиями.
Это откуда, если не секрет? По факту, в приведенном коде контроллер не делает ничего. Вопрос — в каких ситуациях в контроллере будет осмысленный код?
Позволю себе предположить, что взято из приведенной книги. Реализация сразу показалась знакомой, а когда увидел ссылку на книгу все встало на свои места (ссылку на книгу упустил из виду при первом прочтении).
Забавно. И что, авторы книги всерьез полагают, что для GUI прилоежния на фреймворке типа Qt, который сам в состоянии генерировать нотификации о произошедших с ним событиях, нужен контроллер? O_O
в книге примеры не на Qt, а на java.
Если мне не изменяет склероз, то на джаве и AWT, и SWING и даже SWT также генерируют нотификации о действиях пользователя. Роль контроллера в книге все еще непонятна.
тогда Вам проще прочитать книгу. Она очень просто написана, а глава про MVC там и вовсе не большая, вечера хватит. Во всяком случае это будет самый достоверный ответ. К слову, у меня тоже остались некоторые недопонимания его роли, если вдруг действительно решите разобраться, поделитесь соображениями в личку
Согласно архитектуре MVC представление должно быть наблюдателем
В контексте данного примера, представление должно быть каким-то образом уведомлено о том, что модель изменилась. При изменении, модель уведомляет всех зарегистрированных наблюдателей. Если представление не будет зарегистрировано в качестве наблюдателя, то оно не сможет адекватно отреагировать на изменение состояния модели.
По факту, в приведенном коде контроллер не делает ничего.
…кроме того что согласовывает работу представления и модели.
Вопрос — в каких ситуациях в контроллере будет осмысленный код?
Например, когда в зависимости от действий пользователя, будет необходимо как-то изменить представление – заблокировать несколько кнопок допустим.
Например, когда в зависимости от действий пользователя, будет необходимо как-то изменить представление – заблокировать несколько кнопок допустим.
Если не секрет, а что мешает код изменения представления и написать в этом представлении? Что такого будет делать контроллер, чего не может / не хочет делать представление?
Ничего не мешает. В классе CplusDView (в нашем примере) можно смело обрабатывать эвенты и выполнять все те действия, которые делает контроллер. Мне кажется это несколько нелогичным – представление выполняет не слишком свойственные ему функции. События оно может обрабатывать, но не решать, как вся система должна на них реагировать.
Так можно дойти до классического кода начинающих программистов Delphi. Думаю, вам знакома ситуация, когда весь код написан в обработчике события клика по кнопке.
Так можно дойти до классического кода начинающих программистов Delphi. Думаю, вам знакома ситуация, когда весь код написан в обработчике события клика по кнопке.
Так можно дойти до классического кода начинающих программистов Delphi. Думаю, вам знакома ситуация, когда весь код написан в обработчике события клика по кнопке.
Знакома конечно. Но также знакома и обратная ситуация — многокилометровые простыни controller которые отправляют сообщения от модели в представление и обратно, сами при этом ничего не делая. Вот и интересно — какой код вы считаете достойным помещения в Controller? Код, блокирующий кнопки на это, увы, не тянет — это не «решение, как вся система должна реагировать».
Согласен, во всём надо знать меру. Понимание «как лучше» приходит с опытом.
К сожаленью, я не в силах ответить на ваш вопрос. Нужен контекст. Какая-то система, в которой с равным успехом можно применить оба решения. Это будет разбор частного случая.
Для данного примера, контроллер действительно не имеет смысла. Я считаю, что он не имеет смысла и для примера, приведённого в книге Эрика Фримена «Паттерны проектирования». Выбрав такой простой пример, я рассчитывал максимально сосредоточиться на деталях реализации MVC под PyQt, а не на разработки идеальной архитектуры программы сложения двух чисел.
Вот и интересно — какой код вы считаете достойным помещения в Controller? Код, блокирующий кнопки на это, увы, не тянет — это не «решение, как вся система должна реагировать».
К сожаленью, я не в силах ответить на ваш вопрос. Нужен контекст. Какая-то система, в которой с равным успехом можно применить оба решения. Это будет разбор частного случая.
Для данного примера, контроллер действительно не имеет смысла. Я считаю, что он не имеет смысла и для примера, приведённого в книге Эрика Фримена «Паттерны проектирования». Выбрав такой простой пример, я рассчитывал максимально сосредоточиться на деталях реализации MVC под PyQt, а не на разработки идеальной архитектуры программы сложения двух чисел.
Позволю себе предположить, что взято из приведенной книги. Реализация сразу показалась знакомой, а когда увидел ссылку на книгу все встало на свои места (ссылку на книгу упустил из виду при первом прочтении).
Sign up to leave a comment.
Реализация паттерна MVC для PyQt