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

https://stackoverflow.com/questions/18984

09-06-2019
|

Вопрос

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

например.

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.Таким образом, ваш переход к слою не привязан к командной строке.

(Кроме того, этот способ добавляет еще одну проблему безопасности:разве графический интерфейс не должен сначала убедиться, что вызывается ПРАВИЛЬНЫЙ todo.exe?)

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

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

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

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

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

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

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

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

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

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

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

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

@jcarrascal

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

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

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

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

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

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

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

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

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

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

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

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

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

Дизайн:

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

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

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

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

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

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

@Maudite

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--Массовая правка--

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow