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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@jcarrascal

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн:

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

Спектакль:

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

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

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

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

@Maudite

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

Все та же цель. Я не вижу, чтобы версия командной строки влияла на качество GUI.

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

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

Что касается веб-сервиса, то не перегибайте палку. сделайте yaml или xml-rpc. Пусть все будет просто.

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

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

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

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

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

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

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

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

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

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

Когда же это станет отличной идеей?

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

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

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