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

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?

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. .

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.

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!

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.

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."

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.

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!