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

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

например.

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

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

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

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

Событие: [встреча с Джоном, re: вход в систему экспертной оценки]

Расположение: [офис Джона]  

Дата: [пт. 22 августа 2008 г.]  

Время: [14:00]

[Очистить] [Отправить]

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

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

Это считается:

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

Приложение:

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

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

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

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

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

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

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

20.08.2008 22:27:56
В Windows вы помечаете исполняемый файл как консольную программу или графический интерфейс. Вы не можете включить оба одновременно.
Brad Gilbert 20.12.2008 16:38:03
В основном верно. Но приложение CLI может выступать в качестве оболочки для другого приложения с графическим интерфейсом. Если приложение CLI не передает флаг / G, приложение GUI просто не создает окно. См. MsDev.com/.exe для аналогичного примера
MSalters 12.01.2009 15:43:27
21 ОТВЕТ
РЕШЕНИЕ

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

Кроме того, с помощью библиотеки вы можете легко выполнять модульные тесты на функциональность.

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

16
21.08.2008 01:08:37

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

(Кроме того, этот способ добавляет еще одну проблему безопасности: не должен ли сначала графический интерфейс пользователя удостовериться, что вызывается именно RIGHT todo.exe?)

7
20.08.2008 22:31:17

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

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

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

1
21.08.2008 00:15:33

Джоэл написал статью, в которой несколько лет назад он сравнил эту разработку (в стиле «unix») с первым методом «GUI» (в стиле «Windows»). Он назвал это бикультурализмом .

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

5
20.08.2008 22:32:37

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

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

2
20.08.2008 22:34:25

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

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

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

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

2
20.08.2008 22:37:18

@jcarrascal

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

Примечание: не для того, чтобы начинать отдельную тему, но какой предпочтительный способ адресовать ответы / комментарии на ваши вопросы? Я обдумывал и это, и редактирование самого вопроса.

2
20.08.2008 22:37:52

Я думаю, это зависит от того, какое приложение вы разрабатываете. Проектирование для командной строки позволяет вам быстро перейти к тому, что Алан Купер называет «Модель реализации» в «Заключенные бегут из убежища» . Результатом является пользовательский интерфейс, который не интуитивно понятен и сложен в использовании.

37signals также рекомендует сначала разработать свой пользовательский интерфейс в Getting Real . Помните, что для большинства целей в большинстве приложений пользовательский интерфейс - это программа. Внутренний код только для поддержки.

3
20.08.2008 22:37:57

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

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

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

2
20.08.2008 22:48:47

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

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

Массовое редактирование

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

0
15.01.2009 01:53:32

@Maudite

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

Все та же цель. Я не вижу версию командной строки, влияющую на качество графического интерфейса.

0
20.08.2008 23:02:07

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

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

5
20.08.2008 23:02:23

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

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

1
20.08.2008 23:08:42

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

1
20.08.2008 23:47:25

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

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

1
20.12.2008 02:14:30

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

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

Для веб-службы не идите за борт. сделать yaml или xml-rpc. Будь проще.

0
20.08.2008 23:59:25

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

1
21.08.2008 00:30:10

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

0
23.05.2017 11:45:50

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

Дизайн:

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

Спектакль:

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

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

1
21.08.2008 13:19:01

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

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

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

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

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

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

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

0
25.08.2008 22:08:51

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

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

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

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

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

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

0
14.01.2017 08:14:56