Предметную область количественно оценить достаточно сложно. Оценить можно модель, например по количеству внутренних связей между элементами. Модель предметной области не из каких таблиц не состоит, это не даталогическая диаграмма базы данных. Если под моделью предметной области понимать базу данных, с оберткой для работы, то можно прийти к очень плохому решению с раздутыми контроллерами, и уйти от концепции активной модели. Но, сдается мне, что речь в статье идет о веб-программировании, а там это похоже распространено.
Да, но в больших проектах контроллеры напару с вюхами приходится повторно использовать. Например, почему бы не использовать навороченную логику грида с сортировкой, фильтрацией и другими плюшками для выбора значений. Своего рода продвинутый комбобокс, только на отдельной странице.
Сделайте отдельный контрол, и ваша проблема решится. Тут нет никакой связи с MVC, да и вообще с паттернами проектирования.
Небольшое замечание по статье. Как мне кажется, суть MVC эти (безусловно красивые) схемы не отражают. Вот первая схема… зачем там пользователь? Он что, делает контроллеру ментальный запрос? Как можно смешивать на одной схеме материальное и не материальное. MVC это составной паттерн проектирования, и в нем не предусмотрено взаимодействие с пользователем (точнее, описание пользователя, как элемента схемы), ну никак. Хотя, я вот тут смотрю на английскую вики, и вижу, что она со мной не согласна.
Прочитал обе статьи. Так и не понял, в чем же проблема, и как вы предлагает ещё решить.
Логика «зашита» во вьюшках, нельзя повторно использовать контроллеры (!!!)? Да зачем… Контроллер — всего лишь соединительный элемент. Хотите повторно использовать какую-то сложную логику? Сделайте в контроллере Стратегию, и пусть логику используют хоть все контроллеры, два ещё и разную логику, в зависимости от ситуации.
Что до компонентной архитектуры… Компоненты тоже должны взаимодействовать.
Давно уже ничего не писал в VS, но по-моему там хватает "#pragma once"… Думаю, что при изучении C++ проблемы переносимости кода и скорости компиляции вас не слишком заинтересуют.
А вообще CodeBlocks или SublimeText2 в сочетании с clang или gcc, и будет вам счастье с C++11 и без меню с большими буквами (привет, VS12!).
Скорее всего, будет что-то вроде: «Джарвис, сделай мне трёхмерную модель...».
Само понятие «язык программирования», на этом уровне скорее всего сотрётся, а наиболее важную роль будет играть окружение. Собственно оно и сейчас играет не последнюю роль (IDE, фрэймворки, библиотеки и так далее).
Люди образованные, к которым, безусловно, должны относиться и выпускники ВУЗов, понимают, что религия всегда использовалась человечеством в тех случаях, когда некие природные явления не имели объяснения с точки зрения существующей базы знаний об окружающем мире.
Сейчас религия, как и СМИ, чаще всего используется для манипуляции общественным сознанием. Скорее всего, у религии есть какое-то другое применение, но я его не замечал.
После прочтения статьи вспомнился случай, произошедший во время первого года моего обучения в ВУЗе. У нас не было кафедр теологии, никто не устраивал студенческих крёстных ходов и не учил креститься к школе. Но на одну из пар истории преподаватель пригласила священника (если я не ошибаюсь, то это соответствовало изучаемой теме). Студенты первого курса технического факультета спросили священника «как вы можете доказать, что бог и ангелы существуют, и всему, что написано в библии, можно верить?». Священник не ответил ничего адекватного, были какие-то попытки вроде «ну я же в них верю и люди тоже…». После первого подобного ответа священника никто не слушал и ни о чём не спрашивал.
Думаю, что сейчас ситуация не изменилась. Ну а для того, чтобы ввести дисциплину «православие» (назовём её так, для краткости), необходимо добавить её в стандарт, указать какие компетенции она формирует у бакалавра-магистра и так далее. Предпосылки конечно же есть, но вряд ли всё зайдёт настолько далеко.
PS
а на заголовок статьи хочется ответить: «just for lulz».
Думаю, что стоит добавить:
— полный пример сериализации с последующей записью в файл и чтения из файла с последующей десериализацией для Qt 4.8
— пример сериализации/десериализации структуры вроде
Не могу понять, чем же ваш пост отличается от моего по смыслу…
Но, разу уж вы его написали, то быть может приведете примеры популярных языков программирования, которые поддерживают и интерфейсы и множественное наследование?
Утрировать не стоит.
Нет в языке интерфейсов, значит будет применяться upcasting. Без расслоения и прочих ужасов. И абсолютно никаких различий между интерфейсом и абстрактным классом.
Есть интерфейсы, значит будут использоваться они. Тогда действительно будет различие, но на уровне реализации ООП в рамках рассматриваемого языка.
Три с половиной раза написать «чем абстрактный класс отличается от интерфейса»… это сильно. Так чем же простите, с точки зрения реализации? Просто удобный сахарок. Да и то, удобство весьма сомнительно.
Azure SDK для Django выглядит неплохо, но вряд ли заменит PyCharm.
Интересно, что по данным разработчика, в поставку входит Django 1.4, но на скриншотах 1.3.
Вероятно, стоило перевести статью более литературно, а не так дословно. Всё-таки такие понятия как информация, знания и данные различаются по смыслу. Так же различаются понятия класса и объекта.
Например, сразу бросилось в глаза:
Принцип DRY требует, чтобы такие части информации встречались в вашем коде один, и только один раз.
The DRY principle states that these small pieces of knowledge may only occur exactly once in your entire system.
После прочтения оригинала, мне показалось, что под термином «piece of knowledge», автор статьи понимает как формализацию знаний о том, как что-то сделать, в виде алгоритма, выраженного на ЯП, так и некоторую информацию, представленную в виде данных, к которым можно обращаться, используя некоторую переменную. Таким образом, смысл цитаты можно свести к тому, что не надо повторять одинаковые фрагменты кода и дублировать данные без необходимости.
Согласен, во всём надо знать меру. Понимание «как лучше» приходит с опытом.
Вот и интересно — какой код вы считаете достойным помещения в Controller? Код, блокирующий кнопки на это, увы, не тянет — это не «решение, как вся система должна реагировать».
К сожаленью, я не в силах ответить на ваш вопрос. Нужен контекст. Какая-то система, в которой с равным успехом можно применить оба решения. Это будет разбор частного случая.
Для данного примера, контроллер действительно не имеет смысла. Я считаю, что он не имеет смысла и для примера, приведённого в книге Эрика Фримена «Паттерны проектирования». Выбрав такой простой пример, я рассчитывал максимально сосредоточиться на деталях реализации MVC под PyQt, а не на разработки идеальной архитектуры программы сложения двух чисел.
Ничего не мешает. В классе CplusDView (в нашем примере) можно смело обрабатывать эвенты и выполнять все те действия, которые делает контроллер. Мне кажется это несколько нелогичным – представление выполняет не слишком свойственные ему функции. События оно может обрабатывать, но не решать, как вся система должна на них реагировать.
Так можно дойти до классического кода начинающих программистов Delphi. Думаю, вам знакома ситуация, когда весь код написан в обработчике события клика по кнопке.
Согласно архитектуре MVC представление должно быть наблюдателем
В контексте данного примера, представление должно быть каким-то образом уведомлено о том, что модель изменилась. При изменении, модель уведомляет всех зарегистрированных наблюдателей. Если представление не будет зарегистрировано в качестве наблюдателя, то оно не сможет адекватно отреагировать на изменение состояния модели.
По факту, в приведенном коде контроллер не делает ничего.
…кроме того что согласовывает работу представления и модели.
Вопрос — в каких ситуациях в контроллере будет осмысленный код?
Например, когда в зависимости от действий пользователя, будет необходимо как-то изменить представление – заблокировать несколько кнопок допустим.
Возможно, что и ничего.
Дело в том, что пример реализации классической версии MVC для PyQt я писал по просьбе знакомых, которые не нашли ничего подобного в интернете. Если честно, то не нашёл и я. Именно поэтому решил, что статья, в которой присутствует типовая реализация паттерна и основные этапы процесса создания приложения на PyQt, будет полезна. Следствием такого решения является эта публикация.
Сделайте отдельный контрол, и ваша проблема решится. Тут нет никакой связи с MVC, да и вообще с паттернами проектирования.
Небольшое замечание по статье. Как мне кажется, суть MVC эти (безусловно красивые) схемы не отражают. Вот первая схема… зачем там пользователь? Он что, делает контроллеру ментальный запрос? Как можно смешивать на одной схеме материальное и не материальное. MVC это составной паттерн проектирования, и в нем не предусмотрено взаимодействие с пользователем (точнее, описание пользователя, как элемента схемы), ну никак. Хотя, я вот тут смотрю на английскую вики, и вижу, что она со мной не согласна.
Логика «зашита» во вьюшках, нельзя повторно использовать контроллеры (!!!)? Да зачем… Контроллер — всего лишь соединительный элемент. Хотите повторно использовать какую-то сложную логику? Сделайте в контроллере Стратегию, и пусть логику используют хоть все контроллеры, два ещё и разную логику, в зависимости от ситуации.
Что до компонентной архитектуры… Компоненты тоже должны взаимодействовать.
Данных же.
Можете добавить еще один пункт… Что-нибудь про термины предметной области.
А вообще CodeBlocks или SublimeText2 в сочетании с clang или gcc, и будет вам счастье с C++11 и без меню с большими буквами (привет, VS12!).
Само понятие «язык программирования», на этом уровне скорее всего сотрётся, а наиболее важную роль будет играть окружение. Собственно оно и сейчас играет не последнюю роль (IDE, фрэймворки, библиотеки и так далее).
Сейчас религия, как и СМИ, чаще всего используется для манипуляции общественным сознанием. Скорее всего, у религии есть какое-то другое применение, но я его не замечал.
После прочтения статьи вспомнился случай, произошедший во время первого года моего обучения в ВУЗе. У нас не было кафедр теологии, никто не устраивал студенческих крёстных ходов и не учил креститься к школе. Но на одну из пар истории преподаватель пригласила священника (если я не ошибаюсь, то это соответствовало изучаемой теме). Студенты первого курса технического факультета спросили священника «как вы можете доказать, что бог и ангелы существуют, и всему, что написано в библии, можно верить?». Священник не ответил ничего адекватного, были какие-то попытки вроде «ну я же в них верю и люди тоже…». После первого подобного ответа священника никто не слушал и ни о чём не спрашивал.
Думаю, что сейчас ситуация не изменилась. Ну а для того, чтобы ввести дисциплину «православие» (назовём её так, для краткости), необходимо добавить её в стандарт, указать какие компетенции она формирует у бакалавра-магистра и так далее. Предпосылки конечно же есть, но вряд ли всё зайдёт настолько далеко.
PS
а на заголовок статьи хочется ответить: «just for lulz».
— полный пример сериализации с последующей записью в файл и чтения из файла с последующей десериализацией для Qt 4.8
— пример сериализации/десериализации структуры вроде
— пример чтения всех данных, что-то вроде:
Тогда это будет действительно полезная статья для начинающих.
Но, разу уж вы его написали, то быть может приведете примеры популярных языков программирования, которые поддерживают и интерфейсы и множественное наследование?
Нет в языке интерфейсов, значит будет применяться upcasting. Без расслоения и прочих ужасов. И абсолютно никаких различий между интерфейсом и абстрактным классом.
Есть интерфейсы, значит будут использоваться они. Тогда действительно будет различие, но на уровне реализации ООП в рамках рассматриваемого языка.
Интересно, что по данным разработчика, в поставку входит Django 1.4, но на скриншотах 1.3.
Например, сразу бросилось в глаза:
После прочтения оригинала, мне показалось, что под термином «piece of knowledge», автор статьи понимает как формализацию знаний о том, как что-то сделать, в виде алгоритма, выраженного на ЯП, так и некоторую информацию, представленную в виде данных, к которым можно обращаться, используя некоторую переменную. Таким образом, смысл цитаты можно свести к тому, что не надо повторять одинаковые фрагменты кода и дублировать данные без необходимости.
PS PyQt ещё нормально шевелится)
К сожаленью, я не в силах ответить на ваш вопрос. Нужен контекст. Какая-то система, в которой с равным успехом можно применить оба решения. Это будет разбор частного случая.
Для данного примера, контроллер действительно не имеет смысла. Я считаю, что он не имеет смысла и для примера, приведённого в книге Эрика Фримена «Паттерны проектирования». Выбрав такой простой пример, я рассчитывал максимально сосредоточиться на деталях реализации MVC под PyQt, а не на разработки идеальной архитектуры программы сложения двух чисел.
Так можно дойти до классического кода начинающих программистов Delphi. Думаю, вам знакома ситуация, когда весь код написан в обработчике события клика по кнопке.
В контексте данного примера, представление должно быть каким-то образом уведомлено о том, что модель изменилась. При изменении, модель уведомляет всех зарегистрированных наблюдателей. Если представление не будет зарегистрировано в качестве наблюдателя, то оно не сможет адекватно отреагировать на изменение состояния модели.
…кроме того что согласовывает работу представления и модели.
Например, когда в зависимости от действий пользователя, будет необходимо как-то изменить представление – заблокировать несколько кнопок допустим.
Возможно, что и ничего.
Дело в том, что пример реализации классической версии MVC для PyQt я писал по просьбе знакомых, которые не нашли ничего подобного в интернете. Если честно, то не нашёл и я. Именно поэтому решил, что статья, в которой присутствует типовая реализация паттерна и основные этапы процесса создания приложения на PyQt, будет полезна. Следствием такого решения является эта публикация.