Чи є гарною ідеєю розробити архітектуру, думаючи, що класи інтерфейсу користувача можуть бути замінені інтерфейсом командного рядка?

92

На сторінці "Код повного" на сторінці 25 сказано, що добре було б легко замінити звичайні класи користувальницького інтерфейсу командним рядком.

Знаючи його переваги для тестування, що з проблемами, які він може спричинити?

Чи справді ця додаткова робота окупить веб-та мобільні проекти? Як щодо малих та середніх проектів; чи застосовуються ті самі правила? Що робити, якщо це зробить ваш дизайн складнішим?

— Хуліо Родрігес
джерело

2

У Perl це саме те, для чого призначені MooseX :: Getopt і Plack :: Handler :: CLI .

— Ефір

4

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

— zzzzBov

28

Завжди сильне слово.

— Марк Канлас

8

Зверніть увагу на оригінальну цитату, яка є: "Архітектуру слід модулювати, щоб новий інтерфейс користувача можна було замінити, не впливаючи на бізнес-правила та вихідні частини програми. Наприклад, архітектура повинна зробити її досить легко відключити група інтерактивних класів інтерфейсу та підключення до групи класів командного рядка. " Таким чином, CC не говорить, що ви повинні готуватися до заміни графічного інтерфейсу командним рядком, він просто говорить, що архітектура повинна відповідати зміні інтерфейсу користувача. Річ командного рядка GUI-> - лише приклад.

— sleske

2

@Vandell У мене друге видання коду завершено, і це не згадується на сторінці 25. На яке видання ви посилаєтесь?

— JW01

43

Можливість повторного використання функціональності під різними інтерфейсами (наприклад, GUI проти CLI проти REST) не завжди необхідна, але приємно мати та увімкнути багаторазове повторне використання системи, оскільки інші люди знаходять нові способи взаємодії з нею.

У цьому є кілька недоліків, які потрібно зважити:

Для цього знадобляться додаткові шари абстракції (іноді навіть яруси). Хоча наявність цих шарів є гарною інженерною практикою, вони мають додаткові витрати на розробку, розуміючи, що це може не призвести до зменшення зусиль в інших сферах (наприклад, технічному обслуговуванні, повторному використанні, тестуванні), тому варто трохи задуматися над цим.
Оптимальний для середовища потік може бути жахливим для інших. Якщо функціонал був розроблений для підтримки графічного інтерфейсу, це може бути занадто базікати для Інтернету . Не кожен функціонал вартий у кожному носії.
Існує пастка у спробі визначити загальний перетворювач між службами та користувальницьким інтерфейсом, тому можна визначити договір на послуги та отримати автоматично (або наскільки це можливо) інтерфейс користувача для всіх середовищ. Багато проектів витрачали занадто багато зусиль, намагаючись створити такі рамки і додавши до неї всі можливі налаштування під час зміни вимог.

Сказавши це, на моєму досвіді впровадження таких шарів завжди закінчувало платити зусилля. У кількох випадках мені вдалося вчасно розгорнути системи, оскільки нам довелося заміняти медіа (наприклад, від інтеграції веб-служб до інтерфейсу користувача) за кілька тижнів до строку.

— Даніель Йокомізо
джерело

2

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

— BillThor

Я не можу повірити, що це ще не згадувалося, але це суть архітектури Model-View-Controller. Сенс у тому, щоб мати можливість замінювати погляди та контролери за бажанням, щоб зменшити зв'язок, як говорить @BillThor. Це найкращий випадок використання MVC.

— Рудольф Олах

110

Повністю окрім тестування, очевидною перевагою такого підходу є те, що він зробить ваш проект автоматизованим та пробірним . Якщо я зможу надсилати команди командного рядка до програми, я можу написати сценарій для виконання складних завдань набагато простіше (і надійніше!), Ніж я міг би створити макрос для автоматизації того ж самого запису на графічному інтерфейсі.

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

— Мейсон Вілер
джерело

12

Дуже багато додатків використовують плагін-модель для сценаріїв. Зазвичай об'єктна модель піддається впливу, і мова, як python, використовується для запису скриптів. Я не думаю, що параметри командного рядка працюватимуть для нетривіальної програми.

— softveda

Ще однією перевагою може бути відкриття. Особливість Ctrl-Shift-P Sublime Text є фантастичним прикладом цього. Якщо є якийсь незрозумілий функціонал, який я хочу замість того, щоб шукати в меню, я просто набираю те, що, на мою думку, буде називатися, і я можу побачити команду (і ярлик) і можу її виконати негайно.

— Адам Ілей

OpenDJ, сервер LDAP з відкритим кодом, на базі Java, є чудовим прикладом цього: командний рядок для кожної модифікації, зробленої в графічному інтерфейсі, доступний у діалоговому вікні підтвердження.

— Франк

1

@ Marnixv.R .: жести - це просто зручний спосіб виконати якусь дію, яку можна вказати командою, наприклад, "Збільшити 35,73N 118,23W". Малюнок може бути введений як команди, хоча це було б незручно. І все-таки я думаю, що в зручному сценарії інтерфейсу є велика корисність, і для її створення потрібно дуже мало праці.

— Кевін Клайн

7

+1: Ще одна ключова перевага полягає в тому, що він дозволяє легко реєструвати дії користувача, спрощуючи відтворення виробничих проблем.

— Кевін Клайн

81

Це не зайва робота, просто інша робота. Якщо ви зробите це правильно, це не тільки не зробить його складнішим, але зробить його простішим, оскільки змусить вас розв'язати дизайн. Незалежно від того, чи реально ви реалізуєте CLI чи ні, ваш дизайн буде кращим, щоб зробити це можливим.

— Карл Білефельдт
джерело

4

-1 для кількох абсолютно невірних тверджень. Звичайно, це зробить це складніше. Зрештою, це додаткова вимога / особливість.

— Борис Янков

@BorisYankov Я думаю, що він мав на увазі "складне", а не "складне" - вони звучать схоже і мають збіг у значенні, тому їх легко переплутати з нагоди

— Ізката

43

Однією з ключових переваг, яка, здається, не згадується, є те, що можливість зробити це в значній мірі вимагає суворої розв'язки інтерфейсу користувача від базового коду. Однією з ключових переваг цього є те, що це означає, що якщо вам потрібно істотно змінити графічний інтерфейс (скажімо, стандарти iOS на стандарти OSX або один графічний движок на інший), це все, що вам потрібно змінити, оскільки базовий код не залежить від макет інтерфейсу користувача. Не може бути, тому що якби інструменти командного рядка не працювали.

Крім цього, можливість автоматизації тестів є ключовою перевагою.

— девальду
джерело

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

— Натисніть Upvote

5

Так, але все це перевірка є частиною хорошого інтерфейсу, який я сказав, що вам потрібно змінити. Резервний код, який зберігає (наприклад) поточний стан облікового запису користувача, алгоритм пошуку предметів, конкретні правила гри тощо. Тут головне, що якщо мені доведеться перейти з інтерфейсу користувача на основі миші / клавіатури на користувальницький інтерфейс сенсорного екрану для гри, я все одно повинен мати можливість використовувати один і той же механізм резервного копіювання для обробки бойових розрахунків та підрахунку балів, тому я можу зосередитись на написанні нових обробників подій, які використовують ту саму базову систему.

— deworde

2

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

— Натисніть Upvote

2

@ClickUpvote Наскільки це залежить від того, як ви реалізуєте свій графічний інтерфейс. Дійсно тонкий графічний інтерфейс, який просто надсилає повідомлення ValueChanged до класу підтримки та отримує у відповідь ValueValid / ValueInvalid повідомлення, буде набагато простіше замінити той, який виконує всі перевірки в подіях OnTextboxChanged.

— Ден Нілі

@ClickUpvote Я цілком погоджуюся, тому я хочу мати можливість зосередити увагу на тому, що мені подобається непошкоджено, або надати річ, яку я ненавиджу повну свою увагу, тому я можу це зробити якнайшвидше.

— deworde

17

Так, це майже завжди хороша ідея.

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

— Кодер
джерело

2

Яка була б перевага в цьому, якщо ви пишете, наприклад, текстовий редактор?

— nikie

5

@nikie Оскільки, наприклад, ви можете замінити свій перегляд текстового редактора WYSIWIG на звичайний текст або на основі розмітки, і поки він передав ту саму інформацію базовій моделі, ваша існуюча інфраструктура продовжуватиме працювати.

— deworde

5

Я думаю, що це гарна ідея. Крім того, що в змозі написати другий передній край командного рядка, в кінцевому рахунку доводиться, що бізнес-логіка повністю відокремлена від будь-якої конкретної архітектури сервера додатків.

— Тулан Кордова
джерело

5

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

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

Настільки чинник, що і в процесі тестування.

— Саймон О'Дохерті
джерело

3

Ні. Жахлива порада.

Це трохи ягні (Вам це не потрібно).

Розкриття інтерфейсу командного рядка - це не те саме, що структурувати додаток у спосіб, який підтримує тестування одиниць, або відповідає будь-якій частині SOLID або будь-якій практиці програмування, яку я рекомендував би.

Він не працює для будь-якого інтерфейсу, який просто не підходить для інтерфейсу командного рядка. MS Paint - це дійсно просте додаток, але як у будь-якій ситуації ви побачили б користь від того, щоб мати можливість керувати ним з командного рядка?

Це не допоможе вам застосувати сценарій. Це фактично перешкоджатиме будь-якому прогресу в цьому напрямку.

Єдине позитивне - він з’явився на сторінці 25, тож принаймні ви отримуєте попередження, що решта книги може бути… смердючою. Я читав це давно і не сподобався, тому я упереджений.

— Ян
джерело

1

Погоджено +100000000

4

Сценарійний MSPaint звучить насправді корисно.

— RoundTower

ІМО найкраща відповідь. З тих пір, як я слідую за мантрами "не впроваджувати" ЯГНІ ", у мене набагато більше часу зосереджується на реальній роботі, і мені навіть вистачає часу, щоб багато експериментувати. Намагаючись бути розумним заздалегідь, показав мені, що більшу частину часу клієнт хотів якесь інше розширення, ніж згадувалося раніше, тому не витрачався час на щось, що не потрібно.

— topskip

PSPaint + інтерфейс командного рядка = AutoCAD

— Vorac

-1 (якщо я міг би) Зауважте, що він не говорить "впровадити CLI, а також графічний інтерфейс"; в ньому написано "задоволення для реалізації альтернативного інтерфейсу користувача, як CLI".

— Марк Херд

2

Спираючись на те, що сказав Мейсон Уіллер, можливість взаємодіяти з додатком за допомогою командного рядка дуже легко автоматизує завдання.

Це особливо корисно при тестуванні.

Щоб навести практичний приклад, якщо я хочу запустити автоматичні тести на програму, я, можливо, захочу встановити програму автоматично. Для цього я можу передати наступні параметри "myApplication.exe / silentinstall".

Я можу запрограмувати це так, що коли я вказую цей перемикач командного рядка, установка виконується безшумно у фоновому режимі, без встановлення GUI. Будь-який вхід до інсталятора (наприклад, каталог встановлення), можливо, може бути зібраний з файлу XML.

Візьміть ще один приклад. Інтерфейс інтерфейсу Microsoft Test Manager (поставляється разом з Visual Studio) дозволяє користувачам запускати пробні запуски з його інтерфейсу GUI, але також надає інтерфейс командного рядка, щоб зробити те ж саме (використовуючи комбінацію комутаторів командних рядків та входів). Це означає, що я можу з'єднати сценарій PowerShell або DOS, щоб автоматизувати запуск тестів, і тоді я міг створити заплановане завдання, щоб сценарії запускалися щовечора, можливо.

Деякі програми мають перемикачі командного рядка, які вказують на відкриття програми з певними параметрами (наприклад, я можу використовувати "/ maximize", щоб відкрити програму в максимальному вікні).

Існує безліч сценаріїв, коли інтерфейс командного рядка може бути використаний. Це лише деякі приклади.

— об. CiaranG
джерело

1

Зауважте знову фразу: "[Це '] гарна ідея, щоб мати можливість легко замінити звичайні класи інтерфейсу користувача командним рядком". Це не означає, що вам потрібно писати CLI, просто щоб ви могли це легко зробити.

Отже, це говорить про те, що ваш інтерфейс повинен бути від'єднаний від решти коду.

— Хосе Дінунціо
джерело

2

Я думаю, ти мав намір зробити коментар, правда?

— Хуліо Родрігес

1

Це залежить, і коли я кажу, що це залежить, справа не лише в декількох випадках, але це дуже залежить від програми та цільової аудиторії. Якщо припустити, що ми виключаємо ігри з рівняння, то ще існує широкий набір програм, які ви можете писати там, де така команда навряд чи буде реалізована. Будь-яка програма, орієнтована на мобільне середовище (наприклад, iOS, Android тощо), можливо, підпадає під цей заголовок.

Зважаючи на це, у загальному програмному просторі будь-яка програма, яка сильно залежить від візуалізації (наприклад, PowerPoint, Maya тощо), навряд чи коли-небудь побачить заміну командного рядка. Насправді, у випадку з графічним програмним забезпеченням, таким як Maya, можна думати про хорошу розумову вправу, щоб визначити, як працюватиме повна та правильна версія командного рядка, і це може бути неможливо зробити з точки зору користувача. Таким чином, зрозуміло, що є остаточно поширені програми, з якими можна зустрітись, коли інтерфейс, подібний командам, навряд чи коли-небудь побачить, або бажано, навіть якщо сценарій програми може бути бажаним.

Далі, якщо ми подивимось на запропоновану форму з точки зору загальної архітектури програмного забезпечення, я можу побачити, де було б сенс періодично запитувати себе "Як я можу отримати доступ до цієї функції без інтерфейсу користувача?" Взагалі, якщо немає способу це зробити, і він не взаємодіє безпосередньо з користувачем (наприклад, введення жестами), то, швидше за все, виникає ситуація, коли загальну архітектуру потрібно вдосконалити. Для зручності тестування ви хочете мати можливість безпосередньо отримувати доступ до команди, не проходячи через користувальницький інтерфейс, навіть якщо вони не можуть викликатися через командний рядок. Це, як правило, означає, що потрібен надійний API, а теоретично хороший API повинен забезпечувати доступ через командний рядок або інтерфейс користувача. Крім того, у перспективі

Зрештою, я думаю, що те, що пропозиція намагається отримати, має сенс (тобто, мати хороший API та створити свій користувальницький інтерфейс від цього), але вибір слів міг би бути трохи кращим, щоб зрозуміти кращу точку .

— rjzii
джерело

1

Я взагалі не погоджуюся, але однією з найсильніших сильних сторін Майя є той факт, що вона насправді має дуже сильний сценарій API (спочатку MELScript, тепер Python).

— jwd

@jwd - Майя - це приклад, який я вибрав, тому що використовував його пару років тому, якщо у вас є кращий у тому ж роздумі, дайте мені знати. Можливо, Брайс, хоча це не так добре відомо?

— rjzii

0

Це залежить.

Часто ми розбиваємо наші програми на модель / view / контролери або model / view / view / model. Здається, що модель повинна дозволяти доступ до командного рядка, але я не так впевнений у контролері. Природно, погляд - це те, що замінюється.

Деякі відмінності можуть існувати на основі ланцюга інструментів. Code Complete - це книга Microsoft Press, тому, можливо, ви використовуєте технології Microsoft для цього графічного інтерфейсу? Якщо так, я думаю, що під час створення програми для експозиції інтерфейсів через COM або DCOM може бути прапорець. Щодо деяких технологій Microsoft, я думаю, що таблиці ресурсів та передача повідомлень досить інтенсивно поєднуються з усім, що допоможе вам швидко зробити прототип. Я думаю, що стає краще, але якщо ви підтримуєте MFC або Forms, це може трохи зашкодити.

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

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

— DeveloperDon
джерело

4

-1: Code Complete - це мовно-агностична книга про програмування.

— deworde

1

Він ніколи не сказав інакше.

— Клацніть Upvote

І його питання було специфічним для розвитку інтерфейсу користувача ... Ваша думка, пане деворде?

— Ян

0

Це залежить від того, наскільки корисною була б програма командного рядка. Деякі речі, такі як побудова маршруту на карті чи триденна гра, просто не піддаються інтерфейсу командного рядка. Але інші речі, як-от системні інструменти, набагато краще з командного рядка, ніж з графічного інтерфейсу, з тієї простої причини, що вони можуть бути скриптовані.

Доктор Річард Хіпп одного разу сказав, що його ідеальною операційною системою GUI був порожній робочий стіл з піктограмою для відкриття вікон команд та іншим значком для відкриття веб-браузера. Я відчуваю себе майже так само. Якщо це було б корисно як програма командного рядка, і не надто складно побудувати такий спосіб, я б це зробив. GUI може бути цілком окремою програмою, можливо, її побудує хтось інший!

— GlenPeterson
джерело

Чому графік маршруту на карті не піддається автоматизації CLI? Щось на кшталт PlotRoute(startPoint, endPoint)досить просто.

— Мейсон Уілер

@MasonWheeler - Я вважаю, що це буде більше схожеPlotRoute(startPoint, endPoint, chart)

— Fabricio Araujo

0

У наші дні (принаймні для Java) рано чи пізно всі програми додають веб-сервіс (SOAP або Ajax або обидва). Отже, загалом, так, думаю, але передній край веб-сервісу скоріше, ніж командний рядок, якщо ви хочете вдосконалити ментальну метафору ... і більш вірогідну.

— ArtB
джерело

0

Існує інший спосіб погляду на речі. Замість того, щоб припускати, що командний рядок - єдиний шлях, чому б не припустити, що замість цього може використовуватися керування мовою? Тоді потрібна зовсім інша парадигма.

Перш ніж Джобс перейняв Apple, досліджувались дуже складні механізми управління голосом. Apple примружила це на користь таких речей, як Сірі.

Зітхнути.

Популярне і очевидне не завжди "найкраще".

— Siajanai
джерело

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

0

Це взагалі гарна ідея, так.

За метафорою, люди можуть вважати це формою RESTful дизайну. .... саме по собі це не так, як типовий (G) інтерфейс користувача може включати складні багатоступеневі транзакції, такі як створення облікових записів.

Better that one stays away from multi-stage complexity through shopping-cart-like models for transactional setup.

Я одного разу запрограмував метафору drag'n'drop UI у браузері. Дуже складні правила взаємодії на задній частині, щоб UX відчував себе природним. Я вирішив це, зробивши сайт API, а графічний інтерфейс - повноцінним додатком, який генерував події після дії. Модуль зафіксував ці події і за таймером з'єднав їх у "API-виклики" (для ефективності мережі).

Результатом цього стала повністю РЕСТЕВНА ядрова система. Другим результатом було те, що у мене був інтерфейс для третіх сторін, який я міг виставляти за допомогою профілів приналежності відповідно до бізнес-моделі.

— випуски NewAlexandria
джерело

-1

Одна перевага полягає в тому, що вас змусять задуматися про потік інтерфейсу користувача з точки зору користувача. (Що я намагаюся досягти? Який контекст мені потрібно встановити? З огляду на цей контекст, як я досягти мети?)

Існує велика різниця між "створити банківський рахунок" та "написати мс word word document". Навіть якщо ви не будуєте CLI, він може додавати значення лише враховуючи необхідний "контекст CLI". Моделі не просто живуть у моделі бізнес-об'єкта!

— Асвіді
джерело