Изучать архитектуру графического интерфейса сложно. Я давно их использую и исследую, и понимаю, как это может быть неприятно.
Я предлагаю прочитать эту статью Мартина Фолвера и эту . Я приведу некоторые принципы и практики, которые я использую при обучении и исследованиях. И вам нужно написать много кода, чтобы вы могли лучше понять вещи, которые вы изучаете.
Вот несколько важных вещей из моего опыта.
- Некоторые шаблоны / архитектуры были разработаны и / или усовершенствованы с помощью специальных технологий .
Некоторые из этих технологий больше не используются, поэтому естественно, что эти шаблоны / архитектуры развиваются или создаются новые, используя более старые в качестве основы (для идейных принципов), чтобы приспособиться к этому.
MVP и MVC являются примером этого. Первоначальный MVC был создан в семидесятых, поэтому в это время контроллер получил пользовательский ввод для решения конкретных проблем, которые у них были тогда. После этого фреймворки и библиотеки, которые мы сегодня используем для реализации этих шаблонов, изменились. Также изменилась сложность приложения. У MVC были некоторые проблемы, которые остались неясными, как их решить. Это объясняется в вышеприведенных статьях более подробно. MVP пришел после этого, используя MVC в качестве базы. Вот оригинальная статья о MVP. На докладчика была возложена обязанность иметь логику приложения для обработки более сложных случаев.
Да, мы делаем это. Мы все используем фреймворки и библиотеки для реализации вещей, и это не плохо. И да, мы разрабатываем шаблоны, чтобы помочь нам с этими технологиями, к лучшему или к худшему. После этого мы склонны обобщать эти шаблоны, чтобы использовать их в другой технологии, но иногда это сложно.
Примером этого является Модель презентации . Он основан на хорошем механизме DataBinding . Это отличный шаблон, и вы можете разрабатывать приложения с его помощью очень быстро, просто если вам не хватает DataBinding , это будет тяжелым дыханием и сильно замедлит так что может быть не стоит использовать его по технологическим причинам, а не архитектурным . Это жизнь разработчика:)
Итак, следующая вещь:
- Не узнайте о шаблонах / архитектурах из технологий, которые их применяют.
Учитесь на том, откуда пришли эти образцы. Узнайте об их истории. Примите во внимание сложность приложений и технологии, доступные на момент их создания.
Поймите, в чем заключается их идея, а затем перейдите к конкретным технологиям. Шаблоны / Архитектура являются основой для создания вещей. Измените и примите их, если вам нужно. Не стесняйтесь экспериментировать
- Шаблоны не решают всех проблем
Вам нужно менять, модифицировать и смешивать шаблоны, чтобы вы могли решить свои проблемы. Вы должны понимать их хорошо, чтобы вы могли найти их пределы. Когда вы достигнете предела, сделайте то, что должен сделать каждый хороший разработчик: Сделайте свое собственное решение проблем . Это то, что люди сделали. Вот почему у нас есть MVP, потому что у людей были проблемы с MVC, и они изменили его на что-то другое.
Если бы у нас был шаблон, который решал бы все наши проблемы, у нас не было бы больше. Но их у нас много.
Люди концентрируются на одних частях шаблона больше, чем на других. Это касается модели во всех моделях MV *. Люди склонны игнорировать, насколько это важно. Они проектируют Анемичные Модели , перемещая логику в Службы и Представителей.
AnemicModel - это не концепция Модель , которую люди пришли к выводу, которая имеет данные и поведение и моделирует такие вещи, как Vector в математическом выражении или операция BankTransfer . Это просто данные, которые другие компоненты изменяют и злоупотребляют.
Тогда у людей возникают проблемы с пониманием того, как делиться вещами между своими докладчиками. Если они понимают, что такое ApplicationModel и DomainModel , у них не будет этих проблем.
Тем не менее, все люди думают о «Ведущем» как о том, что управляет шоу, поэтому они вкладывают в него столько логики, что не имеют ничего общего с этим.
Код становится уродливым, грязным и трудным для понимания и изменения.
- Поймите, какую технологию вы используете. Некоторые технологии разрабатываются для конкретных нужд: мобильные, настольные, интернет и т. Д.
Развертывание фреймворка и библиотек: hard . Иногда они делают использование шаблонов более сложным. Понимать технологию и мотивы, стоящие за ней, логику и контекст, в котором она была разработана.
Иногда технологии, используемые для мобильных приложений, отличаются от технологий, используемых для настольных компьютеров и в Интернете. Это естественно.
Иногда новые технологии могут смешивать вещи, и чистая реализация шаблона может быть затруднена, но если вы получите представление о шаблонах, вы можете использовать конкретную технологию, соответствующую вашим потребностям .
И очень важный:
- Не пытайтесь уместить проблемы до решение , соответствовать решения до проблемы
Технологии, шаблоны, архитектуры и т. Д. Являются решениями до проблем . Понять проблемы, которые они решают. Поймите ваши проблемы и используйте эти решения для решения ваших проблем, изменяя и расширяя их.
Часто люди принимают что-то вроде MVP и пытаются использовать его для решения всех своих проблем. Это не работает таким образом. Иногда у вас есть проблема, которая не подходит для MVP. В этом случае вы либо изменяете шаблон, либо используете другой.
Вот список ресурсов, которые вы можете использовать.