Новости Среди приятного неожиданного оно пробуждало самые разные воспоминания, сладкие и не очень.
И от этого я добрался до Эта статья , и мне сразу перестало хотеться ностальгировать, и мне захотелось поразить ее таким увесистым многоточием с высоты последних семи лет. Dephi был абсолютно блестящим решением.
Знаете, как «Битлз», как графический интерфейс компьютера с управлением мышью, как двигатель внутреннего сгорания.
Гениальное решение, настолько широко вошедшее в нашу жизнь, что трудно поверить, что его никогда не существовало, а рисовать окна, флажки и кнопки в Windows могло быть настоящей головной болью.
Совершенно гениальной частью Delphi был VCL — тот самый набор флажков и кнопок для окон Windows, которые вдруг стало так легко и просто перетаскивать друг на друга и создавать красивые и необычные приложения для Windows. И как любой приличный пользовательский интерфейс, этот работал, конечно же, по событийной модели.
В OnClick в объекте кнопки описано все, что делает кнопка, в OnChange при вводе в текстовое поле все как у взрослых.
Но дальше, к сожалению, ничего не было.
Я имею в виду ничего из того, что мы знаем сейчас.
MVC, например — Delphi, считай, состоял из одного V, тогда все оставалось на усмотрение разработчика.
Затянуть запрос напрямую из OnClick в базу данных? Да, пожалуйста.
В OnChange открываешь какой-нибудь файл и пытаешься в него записать, а если файла нет, то он тихонько вылетает с чем-то вроде Memory Access Violation — на каждом шагу (впрочем, к Delphi как платформе это не имеет никакого отношения).
И надо сказать, что на протяжении многих лет это всех вполне устраивало, а некоторых это вполне устраивает до сих пор.
Преимущества небольшой и красивой библиотеки компонентов пользовательского интерфейса очевидны сразу; Преимущества всевозможных контроллеров и моделей становятся очевидными не в первый год разработки и не на первых сотнях килобайт исходного кода.
А даже если и стал, то об этом легко забыть, здесь ловушка разума, вроде тех оптических и звуковых иллюзий, о которых яростно спорят в Интернете.
Итак, позвольте мне попытаться проложить небольшой мостик от Delphi к современному пониманию пользовательского интерфейса, и мы разберемся, что из этого получится.
Итак, ключевая идея: мы отделяем презентацию от данных, виджет отдельный, вся работа с информацией в нем отдельная.
Насколько отдельно? Допустим, на кнопке еще есть надпись, а иногда и значок.
Пользователь сам может ввести эту надпись в текстовое поле, а иногда в текстовом поле имеется еще одна надпись, поясняющая пользователю, что именно он вводит. Общее правило: виджет занимается отображением, минимум (НИЦ!) логики, что бы в нем ни присутствовало, оно должно быть связано только с отображением и ничем более.
Например, если кнопка не готова растягиваться вместе с надписью на ней, то надпись должна либо обрезаться каким-то образом (например, показывать в подсказке многоточие и полную версию), либо выдавать ошибку при попытке установить значение большее, чем поместится (правда, идея так себе, такая ошибка скорее всего появится во время выполнения программы, в самый неподходящий момент).
Поле ввода текста может убрать из текста возврат каретки, если оно однострочное, но требовать, например, чтобы в него вводились только цифры, не стоит — это уже не его работа.
Так же, как обработчик нажатия кнопки не требует никаких проверок или вызовов перерисовки, так и сам обработчик кнопки должен подтягивать внешний код, отвечающий за логику UI и всего приложения.
И если вы живете в дивном новом реактивном мире, глядя свысока на всю эту ООП-событийную суету, то принцип все равно остается прежним: нажатие кнопки меняет состояние, добавляя к нему соответствующее Action, а затем какой-то код, код не связан с элементами пользовательского интерфейса, рассмотрит это действие, сделает соответствующие выводы и изменит состояние, чтобы было что отображать обратно в пользовательском интерфейсе.
То есть вне зависимости от среды, платформы и парадигмы сами визуальные элементы несут в себе минимум функционала и ноль логики.
Они получают информацию в самом общем виде, поэтому если у вас есть TextBox, он же Input, который также является полем для ввода текста, он принимает именно строку и возвращает строку.
И задача превратить строку в число, чье-то имя или что-нибудь похитрее уже не для виджета.
Ну а дальше Controller, или Presenter, обрабатывает полученное и выдает результат. Называйте его как хотите, только не добавляйте в него никаких визуальных элементов.
Какова прибыль? Перечисляю их в порядке от самого очевидного к самому, на мой взгляд, существенному.
Во-первых, многоразовость.
Довольно много времени уходит на то, чтобы понять, что поля для ввода почтового адреса, для ввода фамилии и для ввода суммы — это, по сути, одно и то же поле.
Тот же виджет, с тем же набором возможностей, который сводится к подергиванию события ввода текста или обновлению состояния.
И отличаться может только логика работы с текстом внутри него.
Пример «как не надо» из жизни: сделать поле для ввода денежной суммы (до двух знаков после запятой), а потом долго возиться, переделывая его так, чтобы иногда в одно и то же поле можно было вводить сумму ( до 4 десятичных знаков).
В процессе сломайте все места ввода суммы в приложении и срочно отремонтируйте их среди ночи.
И это несмотря на то, что по логике их работы различия у них были в третьем знаке после запятой.
Можно писать стихи о том, как поля для ввода почтовых адресов превращаются в поля для ввода географических адресов, используя наследование и слово Божие.
Во-вторых: тестируемость.
Вы также можете протестировать пользовательский интерфейс.
Практически любой интерфейс.
Но это будут дорого, по времени и ресурсам, затрачиваемым на разработку тестов и выполнение тестов, и вряд ли они будут запускаться при каждом ребилде, а когда тесты крашатся на релизе, это уже будет форс-мажор.
А вот компоненты пользовательского интерфейса наиболее рискованны с точки зрения поломок; как правило, они ломаются чаще всего, наиболее явно и наиболее болезненно.
Но код, отделенный от самих виджетов, действительно можно покрыть модульными тестами.
И юнит-тесты намного дешевле — и писать проще, и запускать можно буквально после любых изменений, и всегда быть уверенным, что ничего не сломано.
И в-третьих, самое важное, на мой взгляд. Рисовать кусок UI вместе с логикой в одном куске крайне сложно, чтобы побороть лень и глубже задуматься о том, как это работает. Прорабатывайте сценарии, отличные от идеально позитивного, когда пользователь ввел именно то, что от него ожидали, сделал именно то, что требовалось, и получил именно то, что хотел.
Тот самый сакраментальный программист «у меня все работает».
Разделение визуальной части и логической части заставляет задуматься, во-первых, о том, как работает визуальная часть: что в нее входит, что из нее выходит, что происходит, если входящее или выходящее не совсем то, что ожидалось.
А написание логики отдельно от управления заставляет писать ее по кейсам, то есть по возможным вариантам использования в конкретном месте конкретного приложения, включая обработку возникающих здесь ошибок и помощь пользователю с трудностями, которые он здесь испытывает. .
Ну да, не всегда, точнее не во всем, решение в общем виде лучше, чем решение, адаптированное к конкретному случаю.
Подведение итогов.
Можно написать на Delph, или приложение для iOS, помучить многострадальный веб по какому-то там-0, или наклепать какую-нибудь микроконтроллерную игру на Python, если ваш код перерос формулу «одна форма, один запрос, один результат» - Я вам скажу я настоятельно рекомендую вам сильно отделить виджеты от какой-либо логики их работы, и тогда есть шанс, что мух в ваших котлетах станет меньше.
И несмотря на первоначальную полную неочевидность преимуществ такого решения, чем дальше вы с ним работаете, тем больше этих преимуществ у вас появится.
Теги: #ui #дизайн программного обеспечения #архитектура программного обеспечения #лучшие практики #не вижу зла #программирование #Идеальный код #Визуализация данных
-
Давайте Убьем Ie6
19 Oct, 24 -
Радио Онлайн
19 Oct, 24 -
Быстрая И Большая Sdhc-Карта От Sandisk
19 Oct, 24
