Должно ли графическое оформление графического интерфейса считаться «обманом?»

У меня есть друг, у которого немного больше опыта программирования. Мы говорили о всех различных технологиях программирования, которые мы используем, и Interface Builder подошел к разговору.

Не имея опыта программирования, за исключением того, чему я сам научился, я лично считаю, что IB и все его функции ( IBOutlets, IBActions) помогают программистам моего уровня квалификации (и, соответственно, всех уровней квалификации) завершать свои проекты за меньшее время.

Его взгляд на IB немного восторженный. Он считает, что кодеры, использующие Interface Builder, «обманывают» в том факте, что им не нужно выкладывать интерфейсы вручную.

Вопрос:

Следует ли использовать конструктор GUI для разметки элементов интерфейса "обманом" (поскольку большинство программ изначально требовало разметки интерфейсов вручную в коде)? Почему?

Это не обман. Такие программы, как IB, являются инструментами. Используйте правильный для работы. Там нет необходимости быть догматичным об этом.

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

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

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

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

Это только обман, если вы жертвуете чем-то, чтобы попасть туда. Большинство макетов GUI просто генерируют код, который вы в любом случае создадите (и часто приходится редактировать вручную, так как макета недостаточно).

Так что в принципе нет.

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

Обман это название игры. При принятии любого решения о разработке всегда следует выбирать самый простой путь. Называйте это обманом, называйте это "быть продуктивным"; это не имеет значения. Вы должны выбрать инструмент, который поможет вам выполнить работу с минимальными усилиями (конечно, не забывайте о техническом обслуживании и масштабируемости).

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

Конечно нет. Делать это полностью вручную, однако, является очевидным случаем сделать ненужную работу для себя.

(Обычно я выкладываю его с помощью компоновщика, и если требуется какая-либо тонкая настройка, он, как правило, - но не всегда - выполняется вручную).

Это, конечно, не обман, хотя я бы немного меньше уважал разработчика, который не мог бы выложить GUI без него. IMO, его использование ничем не отличается от использования предоставленного системой типа данных - зачем реализовывать свой собственный связанный список или хэш-карту, если вы можете использовать один из системной библиотеки?

Я должен был реализовать пользовательский интерфейс в Java Swing пару месяцев назад. Я никогда не использовал его, поэтому написал все вручную, чтобы лучше понять, как это работает. Теперь, когда я знаю базовый API, я никогда больше не буду писать его вручную, если смогу помочь!

Как утверждает @Bryan Oakley , это всего лишь инструмент, а не «обман». Все зависит от того, что именно выкладываете. Если от руки это становится невероятно трудоемким упражнением, тогда вам действительно нужно искать другие альтернативы, которые делают вас более продуктивными.

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

В последнее время с использованием шаблона MVVM, с различием View и ViewModel, становится немного яснее, когда вы будете использовать графические инструменты. Фил Хаак кратко обсуждает это в эпизоде ​​Github для Windows подкаста Herding Code, когда его спрашивают о переходе от веб-разработки к разработке приложений. Имеет больше смысла делать ViewModel с кодированием «вручную», и позволить дизайнеру построить View графически (и соответственно подключить ViewModel).

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