Program-driven programming: kapan itu layak?

Ok, saya tahu judul pertanyaan ini hampir identik dengan Kapan saya harus menggunakan pemrograman berbasis acara? tetapi jawaban dari pertanyaan tersebut tidak membantu saya dalam memutuskan apakah saya harus menggunakan acara dalam kasus tertentu yang saya hadapi.

Saya sedang mengembangkan aplikasi kecil. Ini adalah aplikasi sederhana, dan sebagian besar fungsinya adalah CRUD dasar.

Setelah peristiwa tertentu (saat memodifikasi data tertentu) aplikasi harus menulis salinan lokal dari data tersebut dalam file. Saya tidak yakin tentang apa cara terbaik untuk mengimplementasikan ini. Saya bisa:

• Kejadian kebakaran ketika data diubah dan mengikat respons (menghasilkan file) untuk peristiwa tersebut. Atau, terapkan pola pengamat. Kelihatannya seperti kompleksitas yang tidak perlu.
• Panggil kode penghasil file langsung dari kode yang memodifikasi data. Jauh lebih sederhana, tetapi tampaknya salah bahwa ketergantungan harus seperti ini, yaitu, tampaknya salah bahwa fungsionalitas inti dari aplikasi (kode yang memodifikasi data) harus digabungkan dengan tambahan (kode yang menghasilkan file cadangan). Saya tahu, bagaimanapun, bahwa aplikasi ini tidak akan berkembang ke titik di mana kopling itu menimbulkan masalah.

Apa pendekatan terbaik dalam kasus ini?

Ikuti prinsip KISS: Keep It Simple, Bodoh, atau prinsip YAGNI: Anda Tidak Akan Membutuhkannya.

Anda dapat menulis kode seperti:

void updateSpecialData() {
    // do the update.
    backupData();
}

Atau Anda dapat menulis kode seperti:

void updateSpecialData() {
     // do the update.
     emit SpecialDataUpdated();
}

void SpecialDataUpdatedHandler() {
     backupData();
}

void configureEventHandlers() {
     connect(SpecialDataUpdate, SpecialDataUpdatedHandler);
}

Dengan tidak adanya alasan kuat untuk melakukan sebaliknya, ikuti rute yang lebih sederhana. Teknik seperti penanganan acara memang kuat, tetapi mereka meningkatkan kompleksitas kode Anda. Itu membutuhkan lebih banyak kode untuk bekerja, dan itu membuat apa yang terjadi dalam kode Anda lebih sulit untuk diikuti.

Peristiwa sangat penting dalam situasi yang benar (bayangkan mencoba melakukan pemrograman UI tanpa peristiwa!) Tetapi jangan menggunakannya saat Anda dapat KISS atau YAGNI sebagai gantinya.

Contoh yang Anda gambarkan dari data sederhana, di mana modifikasi memicu beberapa efek dapat dengan sempurna diimplementasikan dengan pola desain pengamat :

• ini lebih mudah untuk diterapkan dan dipelihara daripada kode penuh event driven
• hubungan antara subjek dan pengamat dapat bersifat abstrak, yang memfasilitasi pemisahan masalah.
• ini ideal untuk hubungan satu ke banyak (subjek memiliki satu atau banyak pengamat).

Pendekatan event driven bernilai investasi untuk skenario yang lebih kompleks, ketika banyak interaksi yang berbeda dapat terjadi, dalam konteks banyak ke banyak, atau jika reaksi berantai dipertimbangkan (misalnya subjek menginformasikan pengamat, yang dalam beberapa kasus ingin memodifikasi subjek atau subjek lain)

Seperti yang Anda katakan, acara adalah alat yang hebat untuk mengurangi sambungan antar kelas; jadi walaupun dapat melibatkan penulisan kode tambahan dalam beberapa bahasa tanpa dukungan bawaan untuk acara, ini mengurangi kompleksitas gambaran besar.

Acara bisa dibilang salah satu alat paling penting dalam OO (Menurut Alan Kay - Objek berkomunikasi dengan mengirim dan menerima pesan ). Jika Anda menggunakan bahasa yang memiliki dukungan bawaan untuk acara, atau memperlakukan fungsi sebagai warga negara kelas satu, maka menggunakannya adalah hal yang sulit.

Bahkan dalam bahasa tanpa dukungan bawaan, jumlah pelat untuk sesuatu seperti pola Observer cukup minim. Anda mungkin dapat menemukan perpustakaan acara generik yang layak di suatu tempat yang dapat Anda gunakan di semua aplikasi Anda untuk meminimalkan boilerplate. (Agregator acara umum atau mediator acara berguna di hampir semua jenis aplikasi).

Apakah ini berguna dalam aplikasi kecil? Saya akan mengatakan ya .

• Menjaga kelas dipisahkan satu sama lain menjaga grafik ketergantungan kelas Anda bersih.
• Kelas tanpa dependensi konkret dapat diuji secara terpisah tanpa mempertimbangkan kelas lain dalam tes.
• Kelas tanpa ketergantungan konkret membutuhkan tes unit lebih sedikit untuk cakupan lengkap.

Jika Anda berpikir "Oh, tetapi itu benar-benar hanya aplikasi yang sangat kecil, itu tidak terlalu penting" , pertimbangkan:

• Aplikasi kecil terkadang berakhir dengan digabungkan dengan aplikasi yang lebih besar nantinya.
• Aplikasi kecil cenderung menyertakan setidaknya beberapa logika atau komponen yang nantinya perlu digunakan kembali dalam aplikasi lain.
• Persyaratan untuk aplikasi kecil dapat berubah, mendorong perlunya refactor, yang lebih mudah ketika kode yang ada dipisahkan.
• Fitur tambahan dapat ditambahkan kemudian, mendorong kebutuhan untuk memperluas kode yang ada, yang juga jauh lebih mudah ketika kode yang sudah ada dipisahkan.
• Kode yang digabungkan secara longgar biasanya tidak membutuhkan waktu lebih lama untuk menulis daripada kode yang digabungkan secara ketat; tetapi kode yang dipasangkan dengan erat membutuhkan waktu lebih lama untuk melakukan refactor dan menguji daripada kode yang dipasangkan secara longgar.

Secara keseluruhan, ukuran aplikasi seharusnya tidak menjadi faktor penentu apakah akan mempertahankan kelas secara longgar; Prinsip SOLID tidak hanya untuk aplikasi besar, tetapi juga berlaku untuk perangkat lunak dan basis kode pada skala apa pun.

Faktanya, waktu yang dihemat dalam unit untuk menguji kelas yang longgar digabungkan secara terpisah harus melawan keseimbangan waktu tambahan yang dihabiskan untuk memisahkan kelas-kelas tersebut.

Pola pengamat dapat diimplementasikan dengan cara yang jauh lebih kecil daripada yang dijelaskan oleh artikel Wikipedia (atau buku GOF), dengan asumsi bahasa pemrograman Anda mendukung sesuatu seperti "panggilan balik" atau "delegasi". Cukup kirimkan metode panggilan balik ke kode CRUD Anda (metode pengamat, yang bisa berupa metode "menulis-ke-file" umum, atau yang kosong). Alih-alih "event firing" panggil saja callback itu.

Kode yang dihasilkan hanya akan minimal lebih kompleks daripada memanggil kode penghasil file secara langsung, tetapi tanpa kelemahan dari kopling ketat dari komponen yang tidak terkait.

Itu akan membawa Anda "terbaik dari kedua dunia", tanpa mengorbankan decoupling untuk "YAGNI".