Является ли хорошей идеей спроектировать архитектуру, полагая, что классы пользовательского интерфейса могут быть заменены интерфейсом командной строки?

На странице 25 Code Complete говорится, что неплохо иметь возможность легко заменить обычные классы пользовательского интерфейса на один из командной строки.

Зная его преимущества для тестирования, как насчет проблем, которые он может принести?

Окажется ли эта дополнительная работа действительно для веб-и мобильных проектов? А как насчет малых и средних проектов; применяются ли те же правила? Что если это сделает ваш дизайн более сложным?

Возможность повторного использования функциональности в различных интерфейсах (например, GUI против CLI против REST) ​​не всегда необходима, но приятно иметь и разрешать случайное повторное использование для системы, поскольку другие люди находят новые способы взаимодействия с ней.

Это имеет несколько недостатков, которые необходимо взвешивать:

1. Это потребует дополнительных слоев абстракции (иногда даже уровней). Хотя эти уровни являются хорошей инженерной практикой, они требуют дополнительных затрат на разработку, понимание, которое может не привести к сокращению усилий в других областях (например, техническое обслуживание, повторное использование, тестирование), поэтому стоит задуматься над этим.
2. Поток, который оптимален для среды, может быть ужасным для других. Если функциональность была разработана для поддержки графического интерфейса, она может быть слишком болтливой для Интернета . Не вся функциональность имеет смысл в каждой среде.
3. Попытка определить общий конвертер между сервисами и пользовательским интерфейсом является ловушкой, поэтому можно определить контракт на сервис и автоматически (или, насколько это возможно, получить) пользовательский интерфейс для всех сред. Многие проекты тратили впустую слишком много усилий, пытаясь создать такие платформы и добавляя в них все возможные настройки по мере изменения требований.

Сказав это, по моему опыту, внедрение таких слоев всегда заканчивалось тем, что мы платили за это. В нескольких случаях мне удалось вовремя развернуть системы, потому что нам пришлось поменять носитель (например, с интеграции Web-сервисов в пользовательский интерфейс) за несколько недель до даты исполнения.

Помимо тестирования очевидным преимуществом этого подхода является то, что он сделает ваш проект автоматизируемым и пригодным для сценариев . Если я могу посылать команды командной строки в программу, я могу написать сценарий для выполнения сложных задач гораздо проще (и надежнее!), Чем создать макрос для автоматизации того же самого в графическом интерфейсе.

Конечно, стоит ли это делать, зависит полностью от того, много ли у вас пользователей, которые хотели бы автоматизировать вашу программу.

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

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

Помимо этого, возможность автоматизировать тесты является ключевым преимуществом.

Да, это почти всегда хорошая идея.

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

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

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

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

Так что учтите это при создании тестов.

Нет, ужасный совет.

Это немного ягни (вам это не понадобится).

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

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

Это не поможет вам реализовать скрипты. Это на самом деле будет препятствовать любому прогрессу в этом направлении.

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

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

Это особенно полезно при тестировании.

В качестве практического примера, если я хочу запустить автоматическое тестирование приложения, я могу установить его автоматически. Для этого я мог бы передать следующие параметры, «myApplication.exe / silentinstall».

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

Возьмите другой пример. Графический интерфейс Microsoft Test Manager (поставляется с Visual Studio) позволяет пользователям запускать тестовые запуски из его интерфейса GUI, но также предоставляет интерфейс командной строки для того же действия (используя комбинацию параметров командной строки и входных данных). Это означает, что я могу собрать сценарий PowerShell или DOS для автоматизации запуска тестов, а затем создать запланированное задание, чтобы, возможно, сценарии запускались каждую ночь.

В некоторых приложениях есть переключатели командной строки, которые указывают, что приложение должно открываться с определенными параметрами (например, я мог бы использовать «/ maximize», чтобы открыть приложение в развернутом окне).

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

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

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

Это зависит, и когда я говорю, что это зависит, это не просто вопрос о нескольких крайних случаях, но это очень зависит от приложения и целевой аудитории. Если предположить, что мы исключаем игры из уравнения, тогда существует множество приложений, которые вы, возможно, пишете, где подобная команда маловероятна или никогда не будет реализована. Честно говоря, любое приложение, предназначенное для мобильных устройств (например, iOS, Android и т. Д.), Скорее всего, попадет под этот заголовок.

Учитывая это, в общем программном пространстве любое приложение, которое сильно зависит от визуализации (например, PowerPoint, Maya и т. Д.), Вряд ли когда-либо увидит замену командной строки. На самом деле, в случае графического программного обеспечения, такого как Maya, спорным является хорошее умственное упражнение, чтобы определить, как будет работать полная и правильная версия командной строки, и это может оказаться невозможным с точки зрения пользователя. Таким образом, ясно, что существуют определенно общие приложения, которые могут встречаться там, где интерфейс, подобный интерфейсу, вряд ли когда-либо будет замечен или желателен, даже если сценарии приложения могут быть желательны.

Далее, если мы посмотрим на форму предложения с точки зрения общей архитектуры программного обеспечения, я пойму, где имеет смысл периодически спрашивать себя: «Как я могу получить доступ к этой функции без пользовательского интерфейса?» В общем, если нет способа сделать это и он не взаимодействует напрямую с пользователем (например, ввод жестов), то, скорее всего, у вас возникает ситуация, когда необходимо улучшить общую архитектуру. Чтобы упростить тестирование, вы захотите иметь возможность прямого доступа к командам без прохождения через пользовательский интерфейс, даже если они не могут быть вызваны из командной строки. Как правило, это означает, что должен существовать надежный API, а теоретически хороший API должен обеспечивать доступ через командную строку или пользовательский интерфейс. Кроме того, в конечном счете,

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

По-разному.

Часто мы разделяем наши программы как модель / представление / контроллеры или модель / представление / представление / модель. Кажется, что модель должна разрешать доступ командной строки, но я не так уверен насчет контроллера. Естественно, вид - это то, что заменяется.

Некоторые различия могут существовать в зависимости от цепочки инструментов. Code Complete - это книга Microsoft Press, так что, возможно, вы используете технологии Microsoft для этого графического интерфейса? Если это так, я думаю, что при создании приложения может быть установлен флажок для отображения интерфейсов через COM или DCOM. Я полагаю, что для некоторых технологий Microsoft таблицы ресурсов и передача сообщений интенсивно сочетаются со всем, что Wizards помогает вам быстро создавать. Я думаю, что становится лучше, но если вы поддерживаете MFC или Forms, это может немного повредить.

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

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

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

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

В наши дни (по крайней мере для Java) кажется, что рано или поздно все программы добавляют веб-сервис (SOAP или Ajax или оба) рано или поздно. Так что в общем-то да, думаю, что так, но интерфейс веб-службы более вероятен, чем командная строка, если вы хотите лучшую умственную метафору ... и более вероятную.

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

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

Вздох.

Популярные и очевидные не всегда «лучшие».

Это вообще хорошая идея, да.

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

Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.

Однажды я запрограммировал метафору drag'n'drop UI в браузере. Очень сложные правила взаимодействия на сервере, чтобы UX чувствовал себя естественно. Я решил эту проблему, сделав сайт API, а графический интерфейс был полноценным приложением, которое генерировало события при действии. Модуль перехватил эти события и по таймеру связал их в «вызовы API» (для эффективности сети).

Результатом стала полностью RESTful ядро ​​системы. Вторым результатом было то, что у меня был интерфейс для третьих лиц, который я мог выставить, используя профили присоединения согласно бизнес-модели.

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

Существует большая разница между «создать банковский счет» и «написать документ MS Word». Даже если вы не создаете интерфейс командной строки, он может добавить ценность только для того, чтобы учесть необходимый «контекст интерфейса командной строки». Модели не просто живут в модели бизнес-объектов!