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

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

например.

W:\todo AddTask "Встреча с Джоном, повтор: авторизация эксперта" "John office" "2008-08-22" "14:00"

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

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

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

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

Location: [John office]  

Date:     [Fri. Aug. 22, 2008]  

Time:     [ 2:00 PM]

[Clear]  [Submit]

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

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

Рассматривается ли это:

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

Добавление:

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

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

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

Добавление 2:

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

Joel написал статью, сравнив эту ( "unix-style" ) разработку с первым ( "стиль Windows" ) с GUI несколькими годами назад. Он назвал его Biculturalism.

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

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

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

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

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

Ответ 8

@jcarrascal

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

Боковое примечание. Не начинать отдельную тему, но каков предпочтительный способ ответа на ваши вопросы? Я рассмотрел это и отредактировал сам вопрос.

Ответ 9

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

Ответ 12

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

Ответ 13

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

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

Ответ 14

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

Ответ 15

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

Дизайн:

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

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

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

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

Ответ 16

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

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

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

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

Ответ 17

@Maudite

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

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

Ответ 18

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

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

Для веб-сервиса не заходите за борт. do yaml или xml-rpc. Держите его простым.

Ответ 19

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

Ответ 20

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

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

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

Теперь вы хотите ударить графический интерфейс поверх этого, что вы делаете? Разбор вывода долговременного инструмента командной строки? Сканировать для WARNING и ERROR в этом выпуске, чтобы вызвать диалоговое окно?

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

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

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

Ответ 21

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

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

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

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

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

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