Как разработать программу командной строки, допускающую повторное использование для будущей разработки GUI? [закрытый]
4 ответа
Вы делаете это, применяя значительную часть слоев (возможно, реализуя шаблон MVP) и рассматривая свой интерфейс командной строки как самостоятельный пользовательский интерфейс.
ОБНОВЛЕНИЕ
Этот текст из статьи в Википедии о шаблоне Model-View-Presenter объясняет это довольно хорошо.
Модель-представление-презентатор (MVP) - это пользовательский шаблон проектирования интерфейса, разработанный для облегчения автоматизированного модульного тестирования и улучшения разделения проблем в логика представления.
Модель - это интерфейс, определяющий данные, которые будут отображаться или иным образом использоваться в пользовательском интерфейсе .
Представление - это интерфейс, который отображает данные (модель) и направляет пользовательские команды (события) к ведущему для обработки этих данных.
Ведущий воздействует на модель и вид. Он извлекает данные из репозиториев (модель), сохраняет их и форматирует для отображения в представлении.
Суть в том, что вам нужно поработать над разделением проблем в вашем приложении. Ваш CLI будет одной реализацией представления , тогда как поклонник единорога будет реализовывать другое представление для полнофункционального клиента. Поклонник единорога будет основывать свое мнение на тех же докладчиках, что и ваш интерфейс командной строки. Если этих докладчиков недостаточно для его богатого клиента, он может легко добавить больше, потому что каждый докладчик основан на данных из модели. Модель, в свою очередь, - это то место, где базируется вся основная логика вашего приложения. Создание хорошей модели - это отдельная тема.Вам может быть интересно прочитать, например, о Domain-Driven Design , хотя я не знаю, насколько хорошо это применимо к вашему текущему приложению. Но в любом случае это интересное чтение. Как видите, статья в Википедии о MVP также говорит о тестируемости, что также имеет решающее значение, если вы хотите предоставить прочную основу для развития других. Чтобы достичь высокого уровня тестируемости в вашей кодовой базе, часто бывает хорошей идеей использовать какой-то фреймворк Dependency Injection .
Я надеюсь, что это даст вам общее представление о методах, которые вам необходимо использовать, хотя я понимаю, что это может быть немного ошеломляющим. Не стесняйтесь спрашивать, есть ли у вас дальнейшие сомнения.
/ Klaus
Это звучит как вопрос о том, как писать пригодный для использования код.
При рассмотрении многоразовости кода, вообще говоря, нужно стараться:
- разделять функциональность на модули
- иметь хорошо определенный интерфейс
Разделение функциональности на модули
Нужно стараться разделять код на части, которые несут простую ответственность. Например, программа, выходящая в Интернет для поиска изображений единорогов, может быть разделена на части, которые: а) ищут изображения в Интернете, б) определяют, является ли изображение единорогом, и в) сохраняют указанные изображения единорогов в определенном месте.
Иметь хорошо определенный интерфейс
Наличие хорошо разработанного интерфейса, API (интерфейс прикладного программирования), будет иметь решающее значение для обеспечения возможности повторного использования или расширения приложения.
Предоставление точек входа в каждую функциональность позволит другим программистам фактически написать новый пользовательский интерфейс для предоставленной функциональности.
Решение такого рода проблем очень простое, но на практике у многих младших программистов возникают проблемы с этим шаблоном. Вот решение:
Вы разрабатываете API соскабливания единорога . Это трудный шаг; хороший дизайн API безумно сложен, и примеров для изучения не так много. Один API, который, как мне кажется, стоит изучить, - это API из книги Дэйва Хэнсона Интерфейсы и реализации C .
Затем вы разрабатываете интерфейс командной строки. Если функциональность, которую вы раскрываете, несложная, это не так уж сложно. Но если это сложно, вы можете серьезно подумать об управлении своим API с помощью встроенного языка сценариев, такого как Lua или Tcl , и разработки интерфейса для сценариев, а не для командной строки.
Наконец, вы пишете код обработки командной строки и склеиваете все вместе.
Ваш гипотетический преемник создает свой графический интерфейс одним из двух способов: с использованием встроенных языков сценариев или непосредственно поверх вашего API.
Как отмечалось в других ответах, модель / представление / контроллер может быть хорошим шаблоном для использования при разработке вашего API.
Вы будете принимать входные данные, выполнять действия и представлять выходные данные. Хорошей идеей будет использовать механизм обратного вызова (например, обработчики событий, передача метода в качестве параметра или передача this/self вызываемому классу), чтобы отделить методы ввода и вывода от выполнения действия.
Кроме того, программируйте на интерфейс, а не на реализацию - суть MVC/MVP, как упомянул klausbyskov. Например, не вызывайте напрямую file.write(); сделайте myModel.saveMyData(), которая вызывает file.write, чтобы кто-то другой мог сделать somebodysModel.saveMyData(), которая записывает в базу данных.