Первый интерфейс или сначала логика? - PullRequest
5 голосов
/ 21 июня 2011

Работая над проектами, я часто сталкиваюсь с дилеммой: сначала работать с пользовательским интерфейсом или сначала с логикой.Наличие UI сначала дает хороший обзор того, как будет выглядеть конечный продукт, в то время как логика разработки сначала обнаруживает любые возможные препятствия в технологии.

Однако, это не всегда так кристально ясно ... иногда пользовательскому интерфейсу может потребоваться заполнить данные, чтобы действительно показать, что это значит, и имитация данных может быть более сложной, чем дополнение логики ... что вам больше нравитсяподход к развитию и почему?Что является более эффективным и действенным?(Я вижу эту проблему все больше и больше с проектами iphone)

Ответы [ 7 ]

2 голосов
/ 21 июня 2011

Ни того, ни другого.

В любом случае вам придется подумать о начале проекта, решив общий подход, который вы выберете, и какие операции вы будете поддерживать.

Делайте это достаточно хорошои вы определили интерфейс между представлением и базовой логикой.Посмотрите на подход Model-View-Controller для вдохновения.

То, что вы хотите иметь на ранней стадии, - это представление о том, какие основные операции должен выполнять ваш логический код, чтобыдостичь цели.Обычно это будет простой вызов функции, но иногда это может включать в себя нечто большее.Сначала убедитесь в этом.

Затем сложная система, которая работает, основана на простой системе, которая работает.

Это означает, что вам потребуется базовый пользовательский интерфейс, который вы будете использовать для тестированияреализация базовой логики в первую очередь.Простая форма с кнопкой, которая представляет сообщение достаточно проста.Затем он может расти, вы реализуете часть функциональности, а затем добавляете простой пользовательский интерфейс, с которым вы можете протестировать его.

Проще сделать как кусочек за кусочком, так и логику и пользовательский интерфейс для небольшого кусочка.логика концептуально схожа, и будет легко отслеживать и то, и другое при реализации и тестировании.

Самая важная часть состоит в том, чтобы не связывать пользовательский интерфейс и логику, заставляя их общаться через общий интерфейс.Это позволит вам быстро вносить изменения, когда это необходимо, и улучшать внешний вид графического интерфейса пользователя до конца.

Вы сможете лучше отказаться от пользовательского интерфейса, если он вам не нравится.Все, что вам нужно сделать, это использовать тот же интерфейс, который вы знаете, как делать, потому что вы написали его и уже реализовали его.

Если в какой-то момент вы поймете, что совершили большую ошибку, выможет по-прежнему спасать части кода, опять же, потому что пользовательский интерфейс и логика отделены, и, надеюсь, логическая часть также является достаточно модульной.и держать вещи модульными.

2 голосов
/ 21 июня 2011

Перебор между обоими (логика и пользовательский интерфейс). Назад и вперед. Пользовательский интерфейс может измениться, когда вы поймете, как и что вы можете делать с логикой и какими-либо ограничениями, которые могут возникнуть. Логика может измениться, если вы измените требования к функциям, поведению или производительности простого в использовании, отзывчивого и достойного интерфейса.

Обычно я делаю как можно меньше каждого, пока у меня не появятся едва работающие макеты. Затем я использую каждый макет, чтобы проверить, где мои предположения о правильном интерфейсе и / или логике могут быть правильными или неправильными. Выберите наиболее ошибочные и начните повторять.

Apple предлагает сначала макетировать пользовательский интерфейс на бумаге. (Имейте под рукой ластик ...)

0 голосов
/ 15 марта 2012

Используйте гибкий подход и работайте над небольшим количеством итераций. Медленно собирайте каждую функциональную часть программы, чтобы не создавать монолитную часть сразу.

0 голосов
/ 21 июня 2011

Мне нравится начинать с разметки различных частей моего проекта в чем-то вроде Vizio.

Я делаю поля для различных представлений, которые ожидаю получить, и заполняю их информацией, которую, как я ожидаю, они будут содержать.

Я делаю еще один набор ящиков для ожидаемых объектов модели (логика). Я заполняю их информацией, с которой, как я ожидаю, они будут работать, и рисую линии между моделями и видами, где я думаю, что это будет необходимо.

Я делаю то же самое для графов объектов (если я планирую использовать CoreData) и для таблиц базы данных, если у меня будет внешняя база данных.

Изложение всего визуально помогает мне решить, упускаю ли я какие-либо важные функции или взаимодействия между компонентами проекта. Это также дает мне кое-что, на что я могу быстро сослаться, если позже я потеряю представление о том, что я делал. С этого момента я, как правило, работаю над моделью, пока она не сделает достаточно, чтобы заполнить часть вида, затем я работаю над видом, пока он не сможет взаимодействовать с моделью.

Я также пытаюсь определить виды или модели, которые могут быть повторно использованы для различных целей, чтобы я мог сократить общий объем работы, которую я должен выполнить.

0 голосов
/ 21 июня 2011

Обычно я сначала получаю свой интерфейс.Причина?Когда я создаю прототипы различных дизайнов, иногда моя идея приложения меняется.Если это так, то это не имеет значения - нет кода для перезаписи.

Однако иногда бывает полезно сначала получить основы, чтобы определить, будет ли приложение работать или нет.Если он не будет функционировать, то зачем тратить время на создание интерфейсов?

0 голосов
/ 21 июня 2011

Сначала я начну с основ, а это означает, что сначала нужно кодировать логику и работать. Для этого есть две причины:

  1. Если я не могу заставить логику работать правильно, красивый интерфейс бесполезен и трата моего времени
  2. Скорее всего, вы измените пользовательский интерфейс, когда будете работать над логикой, что сделает процесс пользовательского интерфейса более длинным и дорогим
0 голосов
/ 21 июня 2011

Если возможно, параллельно.

Но лично я сначала защищаю логику.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...