Что вы думаете о разработке для командной строки в первую очередь?

Question

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

например.

W: \ todo AddTask "встреча с Джоном, повторная проверка входа в систему" "Офис Джона" "2008-08-22" "14:00"

загружает todo.exe и вызывает функцию с именем AddTask, которая выполняет некоторую проверку и выбрасывает собрание в базу данных.

В конце концов вы добавите на экран для этого:

============================================================

Event:    [meeting with John, re: login peer review]

Location: [John's office]  

Date:     [Fri. Aug. 22, 2008]  

Time:     [ 2:00 PM]

[Clear]  [Submit]

============================================================

Когда вы нажимаете кнопку Отправить, он вызывает ту же функцию AddTask.

Считается ли это:

• хороший способ кодирования
• только для новичков
• ужасающий!.

Приложение:

Я заметил здесь тенденцию к «общей библиотеке, вызываемой как исполняемыми файлами GUI, так и CLI». Есть ли какая-то веская причина, по которой они должны быть разделены, кроме, возможно, размера самих двоичных файлов?

Почему бы просто не вызвать один и тот же исполняемый файл по-разному:

• "todo /G" когда вам нужен полноценный графический интерфейс
• "todo /I" для интерактивного приглашения в пределах todo.exe (сценарии и т. Д.)
• обычный старый "todo <function>" когда вы просто хотите сделать что-то и покончить с этим.

Приложение 2:

Было упомянуто, что «для того, чтобы [я] описывал вещи, вам [нужно было бы] создавать исполняемый файл каждый раз, когда графический интерфейс должен что-то делать».

Опять же, это не было моим намерением. Когда я упомянул, что пример GUI называется «та же самая функция AddTask», я не имел в виду, что GUI каждый раз вызывал программу командной строки. Я согласен, что это было бы совершенно противно. Я намеревался (см. Первое приложение), чтобы все это содержалось в одном исполняемом файле, поскольку это был крошечный пример, но я не думаю, что моя формулировка обязательно исключала использование общей библиотеки.

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

Answer 1

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

В качестве бонуса, это дает MVC-подобный подход, так как весь «настоящий» код находится в библиотеке классов. Конечно, на более позднем этапе также возможно изменение библиотеки вместе с реальным графическим интерфейсом в один EXE-файл.

Answer 2

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

Answer 3

Лучшим подходом может быть разработка логики в виде библиотеки с четко определенным API и на этапе разработки без интерфейса (или с жестко-закодированным интерфейсом), тогда вы сможете создать CLI или GUI позже

Answer 4

Я бы не стал этого делать по нескольким причинам.

Конструкция:

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

Производительность:

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

Правильный способ сделать это - поместить реализацию в библиотеку, которая вызывается как CLI, так и GUI.

Answer 5

Джон Грубер написал хороший пост о концепции добавления графического интерфейса в программу, не предназначенную для этого: Удобство использования Ronco Spray-On

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

Answer 6

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

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

Когда это отличная идея?

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

Когда это плохая идея?

Когда вы уверены, что ваша структура никогда не умрет

Answer 7

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

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

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

Теперь вы хотите добавить GUI поверх этого, что вы делаете? Разобрать вывод вашего давно запущенного инструмента командной строки? Сканирование ПРЕДУПРЕЖДЕНИЯ и ОШИБКИ в этом выводе, чтобы вывести диалоговое окно?

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

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

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

Answer 8

В дополнение к тому, что сказал Stu , наличие общей библиотеки позволит вам также использовать ее из веб-приложений. Или даже из плагина IDE.

Answer 9

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

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

- массовое редактирование -

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

Answer 10

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

Это также позволяет вашей программе более легко участвовать в среде SOA.

Для веб-службы, не переусердствуйте. сделать yaml или xml-rpc. Сохраняй это простым.