Apakah ide yang baik untuk merancang arsitektur berpikir bahwa kelas User Interface dapat diganti dengan antarmuka baris perintah?


92

Dalam Kode Lengkap halaman 25, dikatakan bahwa adalah ide yang baik untuk dapat dengan mudah mengganti kelas antarmuka pengguna biasa dengan baris perintah.

Mengetahui keuntungannya untuk pengujian, bagaimana dengan masalah yang mungkin ditimbulkannya?

Apakah pekerjaan tambahan ini benar-benar terbayar untuk proyek web dan seluler? Bagaimana dengan proyek kecil dan menengah; apakah aturan yang sama berlaku? Bagaimana jika itu membuat desain Anda lebih kompleks?


2
Di Perl, ini hanya alat bantu seperti MooseX :: Getopt dan Plack :: Handler :: CLI .
Eter

4
Jika Anda membangun program Anda dengan CLI terlebih dahulu, UI dapat berlapis di atasnya, memberikan fleksibilitas lebih dari UI yang tertanam dalam program. Ini hampir sama untuk layanan web.
zzzzBov

28
Selalu merupakan kata yang kuat.
Mark Canlas

8
Harap perhatikan kutipan asli, yaitu: "Arsitektur harus dimodulasi sehingga antarmuka pengguna baru dapat diganti tanpa mempengaruhi aturan bisnis dan bagian output dari program. Misalnya, arsitektur harus membuatnya cukup mudah untuk mematikan suatu sekelompok kelas antarmuka interaktif dan tancapkan sekelompok kelas baris perintah. " Jadi CC tidak mengatakan Anda harus bersiap untuk mengganti GUI dengan baris perintah, itu hanya mengatakan arsitektur harus mengakomodasi perubahan UI. Baris perintah GUI-> hanyalah sebuah contoh.
sleske

2
@ Vandell Saya memiliki Edisi Kedua Kode Lengkap dan ini tidak disebutkan pada halaman 25. Edisi apa yang Anda maksud?
JW01

Jawaban:


43

Mampu menggunakan kembali fungsionalitas di bawah antarmuka yang berbeda (misalnya GUI vs CLI vs REST) ​​tidak selalu diperlukan tetapi menyenangkan untuk memiliki dan mengaktifkan penggunaan kembali kebetulan untuk suatu sistem, karena orang lain menemukan cara baru untuk berinteraksi dengannya.

Ini memiliki beberapa kelemahan yang perlu dipertimbangkan:

  1. Ini akan membutuhkan lapisan abstraksi tambahan (kadang-kadang bahkan tingkatan). Meskipun memiliki lapisan-lapisan ini adalah praktik rekayasa yang baik, mereka memiliki biaya tambahan dalam pengembangan, pemahaman yang mungkin tidak mengarah pada pengurangan upaya di bidang lain (misalnya pemeliharaan, penggunaan kembali, pengujian) sehingga perlu direnungkan sedikit tentang hal itu.
  2. Aliran yang optimal untuk media mungkin mengerikan bagi orang lain. Jika fungsionalitas dirancang untuk mendukung GUI, itu mungkin terlalu cerewet untuk web . Tidak semua fungsi bermanfaat di setiap media.
  3. Ada jebakan dalam mencoba mendefinisikan konverter generik antara layanan dan antarmuka pengguna, sehingga orang dapat menentukan kontrak layanan dan memperoleh secara otomatis (atau sebanyak mungkin) UI untuk semua media. Banyak proyek menyia-nyiakan terlalu banyak upaya untuk membangun kerangka kerja seperti itu dan menambahkan setiap penyesuaian yang mungkin untuknya ketika persyaratan berubah.

Karena itu, dalam pengalaman saya menerapkan lapisan seperti itu selalu berakhir dengan upaya. Dalam beberapa kasus, saya berhasil menggunakan sistem tepat waktu karena kami akhirnya harus menukar media (misalnya dari integrasi Layanan Web ke UI) beberapa minggu sebelum tanggal jatuh tempo.


2
Seperti komentar lain telah dicatat, itu harus meningkatkan kohesi kode dan mengurangi kopling. Keduanya harus membuat kode Anda lebih sederhana, dan lebih mudah untuk diuji. Flow lebih merupakan konsep GUI, dan biasanya tidak boleh ada dalam fungsi lain.
BillThor

Saya tidak percaya ini belum disebutkan tetapi ini adalah inti dari arsitektur Model-View-Controller. Intinya adalah untuk dapat menukar tampilan dan pengontrol sesuka hati, untuk mengurangi sambungan seperti yang dikatakan @BillThor. Ini adalah kasus penggunaan terbaik untuk MVC.
Rudolf Olah

110

Sama sekali selain dari pengujian, keuntungan yang jelas untuk pendekatan ini adalah bahwa itu akan membuat proyek Anda automatable dan skrip . Jika saya dapat mengirim perintah baris perintah ke suatu program, saya dapat menulis skrip untuk melakukan tugas-tugas rumit dengan lebih mudah (dan lebih andal!) Daripada saya dapat membuat makro untuk mengotomatisasi hal yang sama pada GUI.

Benar atau tidaknya itu layak dilakukan, tentu saja, sepenuhnya tergantung pada apakah Anda memiliki banyak pengguna yang ingin mengotomatiskan program Anda atau tidak.


12
Banyak aplikasi menggunakan model plugin untuk skrip. Biasanya model objek diekspos dan bahasa seperti python digunakan untuk menulis skrip. Saya tidak berpikir parameter baris perintah akan berfungsi untuk aplikasi non-sepele.
softveda

Manfaat lain dapat ditemukan. Fitur Ctrl-Shift-P dari Sublime Text adalah contoh yang fantastis untuk ini. Jika ada beberapa fungsi yang tidak jelas yang saya inginkan, daripada harus mencari melalui menu, saya cukup mengetik apa yang saya pikir akan dipanggil, dan saya dapat melihat perintah (dan pintasan) dan saya dapat segera menjalankannya.
Adam Iley

OpenDJ, open source, server LDAP berbasis java adalah contoh yang bagus untuk hal ini: baris perintah untuk setiap modifikasi yang Anda lakukan di GUI tersedia di kotak dialog konfirmasi.
Franck

1
@ Marnixv.R .: gestur hanyalah cara yang nyaman untuk melakukan beberapa tindakan yang dapat ditentukan oleh perintah, misalnya 'Memperbesar pada 35.73N 118.23W'. Suatu gambar bisa menjadi input sebagai perintah, meskipun itu akan merepotkan. Masih saya pikir ada utilitas yang bagus dalam antarmuka skrip yang nyaman, dan sangat sedikit tenaga yang diperlukan untuk membuatnya.
kevin cline

7
+1: Keuntungan utama lainnya adalah membuatnya mudah untuk mencatat tindakan pengguna, menyederhanakan reproduksi masalah produksi.
kevin cline

81

Ini bukan pekerjaan tambahan, hanya pekerjaan yang berbeda . Jika Anda melakukannya dengan benar, tidak hanya itu tidak akan membuatnya lebih kompleks, itu akan membuatnya lebih sederhana karena akan memaksa Anda untuk memisahkan desain Anda. Apakah Anda benar-benar mengimplementasikan CLI, desain Anda akan lebih baik karena memungkinkan untuk melakukannya.


4
-1 untuk beberapa pernyataan yang sepenuhnya salah. Tentu saja itu akan membuatnya lebih kompleks. Bagaimanapun, ini merupakan persyaratan / fitur tambahan.
Boris Yankov

@ BorisYankov Saya pikir maksudnya "rumit" dan bukan "kompleks" - mereka terdengar mirip dan memiliki arti yang tumpang tindih, sehingga mereka mudah membingungkan pada kesempatan
Izkata

43

Salah satu keuntungan utama yang tampaknya tidak disebutkan adalah bahwa mampu melakukan ini cukup memaksa decoupling ketat UI dari kode yang mendasarinya. Satu keuntungan utama dari ini adalah bahwa itu berarti bahwa jika Anda perlu secara signifikan mengubah GUI (katakan standar iOS ke standar OSX, atau satu mesin grafis ke yang lain), itu saja yang perlu Anda ubah, karena kode yang mendasarinya tidak bergantung pada tata letak UI. Ini tidak bisa terjadi, karena jika itu, alat baris perintah tidak akan bekerja.

Selain itu, kemampuan mengotomatisasi tes adalah keunggulan utama.


Koreksi saya jika saya salah, tetapi mengubah dari satu GUI ke GUI lainnya masih akan membutuhkan pekerjaan yang signifikan dalam hal validasi formulir / menampilkan pesan kesalahan, mengatur penangan acara, dll.
Klik Suara positif

5
Ya, tetapi semua validasi itu adalah bagian dari UI yang bagus, yang saya katakan perlu Anda ubah. Kode backend yang menyimpan (misalnya) keadaan akun pengguna saat ini, algoritma untuk mencari item, aturan khusus gim, dll. Hal utama di sini adalah jika saya harus beralih dari UI berbasis mouse / keyboard ke touchscreen UI untuk sebuah game, saya masih harus dapat menggunakan mesin backend yang sama untuk menangani perhitungan pertempuran dan penilaian, sehingga saya dapat fokus pada penulisan event handler baru yang menggunakan sistem dasar yang sama.
deworde

2
itu sama sekali tidak mudah, saya benci menulis event handler dan membuat kode validasi lebih dari kode bisnis. (walaupun saya setuju dengan Anda bahwa mereka harus digabungkan dengan cara Anda menggambarkan)
Klik Suara positif

2
@ClickUpvote Sejauh ini tergantung bagaimana Anda menerapkan GUI Anda. GUI yang sangat tipis yang hanya mengirim pesan ValueChanged ke kelas dukungan dan menerima pesan ValueValid / ValueInvalid sebagai respons akan jauh lebih mudah untuk menukar yang salah satu yang melakukan semua validasi dalam acara OnTextboxChanged.
Dan Neely

@ClickUpvote Saya cukup setuju, itu sebabnya saya ingin bisa fokus pada hal yang saya sukai tidak rusak, atau memberikan hal yang saya benci perhatian penuh saya, jadi saya bisa menyelesaikannya sesegera mungkin.
deworde

17

Ya itu hampir selalu merupakan ide yang bagus.

Jika Anda mengikuti pendekatan ini, Anda tidak akan memiliki logika bisnis atau akses data di utas yang sama dengan GUI, dan di belakang beberapa penangan GUI. Alasan ini saja layak diinvestasikan.


2
Apa keuntungannya jika Anda menulis, mis. Editor teks?
nikie

5
@nikie Karena, misalnya, Anda dapat mengganti tampilan editor teks WYSIWIG Anda dengan teks biasa atau front-end berbasis markup, dan selama itu meneruskan informasi yang sama ke model yang mendasarinya, infrastruktur Anda yang ada akan terus berfungsi.
deworde

5

Menurut saya ide ini bagus. Selain itu mampu menulis ujung depan baris perintah kedua, pada akhirnya membuktikan logika bisnis benar-benar dipisahkan dengan arsitektur server aplikasi tertentu.


5

Satu-satunya bahaya yang saya lihat dalam melakukan ini adalah bahwa untuk sampai ke bagian tertentu di UI, pengguna biasanya harus melintasi bagian lain dari UI.

Sedangkan sebagai pengembang bisa langsung menjalankan UI secara langsung. Saya telah melihat situasi di mana pengembang tidak dapat mereproduksi masalah pengguna sampai mereka benar-benar menggunakan produk.

Jadi faktor itu juga saat membuat tes.


3

Tidak. Sedikit nasihat yang mengerikan.

Agak yagni (Anda tidak akan membutuhkannya).

Mengekspos antarmuka baris perintah tidak sama dengan menyusun aplikasi Anda dengan cara yang mendukung pengujian unit, atau mematuhi setiap bagian dari SOLID, atau praktik pemrograman apa pun yang saya sarankan.

Tidak berfungsi untuk UI apa pun yang tidak cocok dengan antarmuka baris perintah. MS Paint adalah aplikasi yang sangat sederhana, tetapi bagaimana, dalam situasi apa pun, apakah Anda melihat manfaat untuk dapat mengendalikannya dari baris perintah?

Itu tidak akan membantu Anda menerapkan skrip. Itu benar-benar akan menghambat kemajuan ke arah itu.

Satu-satunya hal positif adalah itu muncul di halaman 25, jadi setidaknya Anda mendapat peringatan bahwa sisa buku mungkin, ... bau. Saya membacanya sejak lama dan tidak menyukainya, jadi saya bias.


1
Setuju +100000000

4
MSPaint Scriptable terdengar sangat berguna sebenarnya.
RoundTower

IMO jawaban terbaik. Sejak saya mengikuti mantra "jangan laksanakan 'YAGNI'", saya memiliki lebih banyak waktu untuk berkonsentrasi pada pekerjaan nyata dan saya bahkan memiliki cukup waktu untuk bereksperimen. Mencoba untuk menjadi pintar di muka telah menunjukkan kepada saya bahwa sebagian besar waktu pelanggan menginginkan ekstensi yang berbeda dari yang disebutkan sebelumnya, jadi tidak ada waktu yang terbuang untuk sesuatu yang tidak diperlukan.
topskip

Antarmuka baris perintah PSPaint + = AutoCAD
Vorac

-1 (jika saya bisa) Perhatikan bahwa ia tidak mengatakan "mengimplementasikan CLI dan GUI"; ia mengatakan "melayani untuk mengimplementasikan UI alternatif, seperti CLI".
Mark Hurd

2

Membangun dari apa yang dikatakan Mason Wheeler, dapat berinteraksi dengan aplikasi melalui command-line membuatnya sangat mudah untuk mengotomatisasi tugas.

Ini sangat berguna dalam pengujian.

Untuk memberikan contoh praktis, jika saya ingin menjalankan tes otomatis pada aplikasi, saya mungkin ingin menginstal aplikasi secara otomatis. Untuk melakukan ini, saya mungkin memberikan parameter berikut, "myApplication.exe / silentinstall".

Saya dapat memprogramnya sehingga ketika saya menentukan sakelar baris perintah ini, instalasi dilakukan secara diam-diam di latar belakang, tanpa pemasang GUI. Input apa pun ke penginstal (seperti direktori instal) mungkin dapat diambil dari file XML.

Ambil contoh lain. Microsoft Test Manager GUI (dilengkapi dengan Visual Studio) memungkinkan pengguna untuk meluncurkan uji coba dari antarmuka GUI-nya, tetapi juga menyediakan antarmuka baris perintah untuk melakukan hal yang sama (menggunakan kombinasi saklar dan input baris perintah). Ini berarti saya dapat menyusun skrip PowerShell atau DOS untuk mengotomatiskan peluncuran tes, dan saya kemudian dapat membuat tugas yang dijadwalkan sehingga skrip dijalankan setiap malam, mungkin.

Beberapa aplikasi memiliki saklar baris perintah yang menentukan aplikasi untuk dibuka dengan opsi tertentu (misalnya, saya mungkin menggunakan '/ maksimalkan' untuk membuka aplikasi dalam jendela yang dimaksimalkan).

Ada banyak skenario di mana antarmuka baris perintah bisa digunakan. Ini hanya beberapa contoh.


1

Perhatikan frasa lagi: "Ini adalah ide yang bagus untuk dapat dengan mudah mengganti kelas antarmuka pengguna biasa dengan baris perintah". Itu tidak berarti Anda harus menulis CLI, hanya saja Anda bisa melakukannya dengan mudah.

Jadi, apa yang dikatakannya adalah bahwa UI Anda harus dipisahkan dari sisa kode.


2
Saya pikir Anda bermaksud untuk memberikan komentar, bukan?
Julio Rodrigues

1

Itu tergantung dan ketika saya mengatakan itu tergantung, itu bukan hanya masalah memiliki pasangan tepi kasus, tetapi sangat tergantung pada aplikasi dan audiens target. Dengan asumsi bahwa kita menghilangkan game dari persamaan maka masih ada beragam aplikasi yang Anda dapat menulis di mana perintah seperti tidak mungkin atau tidak akan pernah diterapkan. Di luar kepala saya, aplikasi apa pun yang menargetkan lingkungan seluler (mis. IOS, Android, dll.) Kemungkinan akan jatuh di bawah judul ini.

Dengan mengingat hal itu, dalam ruang perangkat lunak umum, aplikasi apa pun yang sangat bergantung pada visualisasi (mis. PowerPoint, Maya , dll.) Tidak akan pernah melihat penggantian baris perintah diterapkan. Bahkan, dalam kasus perangkat lunak grafis seperti Maya, bisa dibilang latihan mental yang baik untuk menentukan bagaimana versi baris perintah yang lengkap dan tepat akan bekerja dan mungkin tidak mungkin untuk melakukannya dari sudut pandang pengguna. Dengan demikian, jelas bahwa ada beberapa aplikasi umum yang dapat ditemui di mana antarmuka seperti perintah tidak akan pernah terlihat, atau diinginkan bahkan jika skrip aplikasi mungkin diinginkan.

Selanjutnya, jika kita melihat saran dari sudut pandang arsitektur perangkat lunak umum, saya dapat melihat di mana masuk akal untuk bertanya pada diri sendiri secara berkala, "Bagaimana saya bisa mengakses fitur ini tanpa antarmuka pengguna?" Secara umum, jika tidak ada cara untuk melakukannya dan itu tidak secara langsung berinteraksi dengan pengguna (misalnya input gerakan) maka Anda kemungkinan memiliki situasi di mana arsitektur keseluruhan perlu ditingkatkan. Untuk memudahkan pengujian Anda akan ingin dapat langsung mengakses perintah tanpa melalui antarmuka pengguna, meskipun mereka mungkin tidak dipanggil melalui baris perintah. Ini umumnya berarti bahwa API yang solid harus ada dan secara teoritis API yang baik harus memungkinkan akses melalui baris perintah atau antarmuka pengguna. Selanjutnya, dalam jangka panjang,

Pada akhirnya, saya pikir apa yang ingin dicapai oleh saran itu masuk akal (mis. Miliki API yang bagus dan bangun antarmuka pengguna Anda dari itu) tetapi pemilihan kata mungkin sedikit lebih baik untuk menjelaskan maksudnya. .


1
Saya tidak setuju secara umum, tetapi salah satu kekuatan besar Maya adalah fakta bahwa ia memiliki API skrip yang sangat kuat (aslinya MELScript, sekarang Python).
jwd

@ jwd - Maya adalah contoh yang saya pilih karena saya menggunakannya beberapa tahun yang lalu, jika Anda memiliki yang lebih baik di jalur pemikiran yang sama, beri tahu saya. Mungkin Bryce meskipun tidak tahu juga?
rjzii

0

Tergantung.

Seringkali kita mempartisi program kita sebagai model / tampilan / pengontrol atau model / tampilan / tampilan / model. Tampaknya model harus mengizinkan akses baris perintah, tetapi saya tidak yakin tentang controller. Secara alami, tampilan adalah apa yang sedang diganti.

Beberapa perbedaan mungkin ada berdasarkan rantai alat. Kode Lengkap adalah buku Microsoft Press, jadi mungkin Anda menggunakan teknologi Microsoft untuk GUI ini? Jika demikian, saya pikir mungkin ada kotak centang ketika Anda membuat aplikasi untuk mengekspos antarmuka melalui COM atau DCOM. Untuk beberapa teknologi Microsoft, saya pikir tabel sumber daya dan penyampaian pesan cukup intensif digabungkan dengan apa pun yang Wizards bantu dengan cepat prototipe. Saya pikir ini semakin baik, tetapi jika Anda mempertahankan MFC atau Formulir, itu mungkin sedikit menyakitkan.

Dalam beberapa kasus, program berbasis GUI Anda mungkin menjadi pembungkus di sekitar antarmuka manajemen atau mungkin memiliki sedikit logika sendiri, sehingga tidak banyak yang dapat dikendalikan oleh antarmuka baris perintah. Membangun aplikasi konsol terpisah mungkin lebih cepat dan masih memungkinkan Anda membuat skrip, menguji, atau menggunakan yang penting.

Poin kunci yang saya kira adalah bahwa saran itu bukan aturan. Jika Anda mengikutinya, Anda harus mendapatkan pengujian unit dan penerimaan yang lebih mudah atau antarmuka mundur ketika Anda atau pelanggan lebih suka mengetik daripada mengklik. Jika itu membayar untuk dirinya sendiri, lakukanlah. Semoga berhasil.


4
-1: Code Complete adalah buku agnostik bahasa tentang keahlian pemrograman.
deworde

1
Dia tidak pernah mengatakan sebaliknya.
Klik Suara positif

Dan pertanyaannya adalah khusus untuk pengembangan UI ... Maksud Anda Mr deworde?
Ian

0

Itu tergantung pada seberapa berguna program baris perintah. Beberapa hal, seperti merencanakan rute pada peta, atau memainkan game 3-d, jangan meminjamkan diri ke antarmuka baris perintah. Tetapi hal-hal lain, seperti alat sistem jauh lebih baik dari baris perintah daripada dari GUI, karena alasan sederhana bahwa mereka dapat dituliskan.

Richard Hipp pernah berkata bahwa sistem operasi GUI idealnya adalah desktop kosong dengan ikon untuk membuka jendela perintah dan ikon lain untuk membuka browser web. Saya merasakan hal yang hampir sama. Jika itu akan berguna sebagai program command-line, dan tidak terlalu sulit untuk membangunnya, saya akan melakukannya. GUI bisa menjadi program yang benar-benar terpisah, mungkin dibangun oleh orang lain!


Mengapa tidak merencanakan rute pada peta cocok untuk otomasi CLI? Sesuatu seperti PlotRoute(startPoint, endPoint)ini cukup mudah.
Mason Wheeler

@MasonWheeler - Saya percaya ini akan lebih sepertiPlotRoute(startPoint, endPoint, chart)
Fabricio Araujo

0

Hari-hari ini (setidaknya untuk Java) sepertinya cepat atau lambat semua program menambahkan layanan web (SOAP atau Ajax atau keduanya) cepat atau lambat. Jadi secara umum ya berpikir seperti itu tetapi ujung depan layanan web lebih mungkin daripada baris perintah jika Anda ingin metafora mental yang lebih baik ... dan yang lebih mungkin.


0

Ada cara berbeda dalam memandang sesuatu. Daripada mengasumsikan bahwa baris perintah adalah satu-satunya cara untuk pergi, mengapa tidak menganggap bahwa kontrol wicara dapat digunakan sebagai gantinya? Dibutuhkan paradigma yang sama sekali berbeda.

Sebelum Jobs mengambil alih Apple, mekanisme kontrol suara yang sangat canggih sedang dieksplorasi. Apple memadamkan ini demi hal-hal seperti Siri.

Mendesah.

Populer dan jelas tidak selalu "terbaik."


Salah satu alasan utama untuk baris perintah terutama untuk dapat menguji dan skrip fungsi perangkat lunak. Mungkin sedikit canggung (atau setidaknya disk-hoggy) untuk merekam klip audio dari suara kami hanya untuk unit menguji perangkat lunak atau menjalankan skrip batch.

0

Ini umumnya ide yang bagus, ya.

Dengan metafora, orang mungkin menganggap ini sebagai bentuk desain yang tenang. .... itu bukan, karena itu, karena UI (G) biasa dapat melibatkan transaksi multi-tahap yang kompleks seperti pembuatan akun.

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

Saya pernah memprogram metafora UI drag'n'drop di browser. Aturan interaksi yang sangat kompleks di bagian belakang membuat UX terasa alami. Saya memecahkan masalah ini dengan menjadikan situs sebagai API dan GUI adalah aplikasi lengkap yang menghasilkan peristiwa saat beraksi. Sebuah modul menangkap peristiwa ini dan, pada penghitung waktu, menggabungkannya ke dalam 'panggilan API' (untuk efisiensi jaringan).

Hasilnya adalah sistem inti yang sepenuhnya tenang. Hasil kedua adalah bahwa saya memiliki antarmuka untuk pihak ke-3, yang dapat saya tampilkan menggunakan profil afiliasi sesuai model bisnis.


-1

Salah satu keuntungannya adalah Anda akan dipaksa untuk berpikir tentang aliran UI dari perspektif pengguna. (Apa yang ingin saya capai? Konteks apa yang perlu saya atur? Dengan konteks itu, bagaimana saya mencapai tujuan?)

Ada perbedaan besar antara "buat rekening bank" dan "tulis dokumen kata ms". Bahkan jika Anda tidak membangun CLI, itu dapat menambah nilai hanya untuk mempertimbangkan "konteks CLI" yang dibutuhkan. Model tidak hanya hidup dalam model objek bisnis!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.