Pertanyaan itu menghadirkan dilema yang salah. Penerapan prinsip YAGNI yang benar bukanlah hal yang tidak terkait. Ini salah satu aspek dari desain yang bagus. Setiap prinsip SOLID adalah aspek desain yang baik juga. Anda tidak dapat selalu sepenuhnya menerapkan setiap prinsip dalam disiplin apa pun. Masalah dunia nyata menempatkan banyak kekuatan pada kode Anda, dan beberapa dari mereka mendorong ke arah yang berlawanan. Prinsip-prinsip desain harus menjelaskan semua itu, tetapi tidak ada prinsip yang dapat memenuhi semua situasi.
Sekarang, mari kita lihat setiap prinsip dengan pemahaman bahwa meskipun mereka kadang-kadang menarik ke arah yang berbeda, mereka sama sekali tidak inheren dalam konflik.
YAGNI dirancang untuk membantu pengembang menghindari jenis pengerjaan ulang: yang berasal dari membangun hal yang salah. Hal ini dilakukan dengan membimbing kita untuk menghindari membuat keputusan yang salah terlalu dini berdasarkan asumsi atau prediksi tentang apa yang kita pikir akan berubah atau dibutuhkan di masa depan. Pengalaman kolektif memberi tahu kita bahwa ketika kita melakukan ini, kita biasanya salah. Sebagai contoh, YAGNI akan memberitahu Anda untuk tidak membuat antarmuka untuk tujuan usabilitas , kecuali Anda tahu sekarang bahwa Anda memerlukan beberapa pelaksana. Demikian pula YAGNI akan mengatakan jangan membuat "ScreenManager" untuk mengelola formulir tunggal dalam aplikasi kecuali Anda tahu sekarang bahwa Anda akan memiliki lebih dari satu layar.
Berlawanan dengan apa yang dipikirkan banyak orang, SOLID bukan tentang usabilitas, kedermawanan, atau bahkan abstraksi. SOLID dimaksudkan untuk membantu Anda menulis kode yang disiapkan untuk perubahan , tanpa mengatakan apa pun tentang perubahan spesifik apa yang mungkin terjadi. Lima prinsip SOLID menciptakan strategi untuk membangun kode yang fleksibel tanpa terlalu generik, dan sederhana tanpa naif. Penerapan kode SOLID yang tepat menghasilkan kelas kecil, fokus dengan peran dan batasan yang jelas. Hasil praktisnya adalah bahwa untuk setiap perubahan kebutuhan yang diperlukan, sejumlah kelas minimum perlu disentuh. Dan demikian pula, untuk perubahan kode apa pun, ada jumlah minimal "riak" hingga ke kelas lain.
Melihat contoh situasi yang Anda miliki, mari kita lihat apa yang mungkin dikatakan YAGNI dan SOLID. Anda mempertimbangkan antarmuka repositori yang umum karena semua repositori terlihat sama dari luar. Tetapi nilai antarmuka umum yang umum adalah kemampuan untuk menggunakan implementer mana pun tanpa perlu tahu yang mana itu pada khususnya. Kecuali jika ada suatu tempat di aplikasi Anda di mana ini akan diperlukan atau berguna, YAGNI mengatakan jangan lakukan itu.
Ada 5 prinsip SOLID untuk dilihat. S adalah Tanggung Jawab Tunggal. Ini tidak mengatakan apa-apa tentang antarmuka, tetapi mungkin mengatakan sesuatu tentang kelas konkret Anda. Dapat dikatakan bahwa penanganan akses data itu sendiri mungkin paling baik dijadikan tanggung jawab satu atau lebih kelas lain, sedangkan tanggung jawab repositori adalah menerjemahkan dari konteks implisit (CustomerRepository adalah repositori secara implisit untuk entitas Pelanggan) ke dalam panggilan eksplisit ke API akses data umum yang menetapkan jenis entitas Pelanggan.
O Terbuka-Tertutup. Ini sebagian besar tentang warisan. Itu akan berlaku jika Anda mencoba untuk mendapatkan repositori Anda dari basis umum yang mengimplementasikan fungsi umum, atau jika Anda diharapkan untuk mendapatkan lebih jauh dari repositori yang berbeda. Tapi kamu tidak, jadi tidak.
L adalah Pengganti Liskov. Ini berlaku jika Anda bermaksud menggunakan repositori melalui antarmuka repositori umum. Itu menempatkan pembatasan pada antarmuka dan implementasi untuk memastikan konsistensi dan menghindari penanganan khusus untuk pelaksana yang berbeda. Alasan untuk ini adalah bahwa penanganan khusus seperti itu merusak tujuan antarmuka. Mungkin bermanfaat untuk mempertimbangkan prinsip ini, karena mungkin memperingatkan Anda untuk tidak menggunakan antarmuka repositori umum. Ini bertepatan dengan bimbingan YAGNI.
Saya adalah Segregasi Antarmuka. Ini mungkin berlaku jika Anda mulai menambahkan operasi kueri yang berbeda ke repositori Anda. Segregasi antarmuka berlaku di mana Anda dapat membagi anggota kelas menjadi dua himpunan bagian di mana satu akan digunakan oleh konsumen tertentu dan yang lain oleh orang lain, tetapi tidak ada konsumen yang kemungkinan akan menggunakan kedua himpunan bagian. Panduannya adalah membuat dua antarmuka terpisah, bukan satu antarmuka yang umum. Dalam kasus Anda, tidak mungkin mengambil dan menyimpan instance individual akan dikonsumsi oleh kode yang sama yang akan melakukan kueri umum, jadi mungkin berguna untuk memisahkannya menjadi dua antarmuka.
D adalah Injeksi Ketergantungan. Di sini kita kembali ke titik yang sama dengan S. Jika Anda memisahkan konsumsi API akses data ke objek yang terpisah, prinsip ini mengatakan bahwa alih-alih hanya membuat instance objek itu, Anda harus meneruskannya ketika Anda membuat repositori. Ini membuatnya lebih mudah untuk mengontrol masa pakai komponen akses data, membuka kemungkinan berbagi referensi untuk itu di antara repositori Anda, tanpa harus menempuh jalur membuatnya singleton.
Penting untuk dicatat bahwa sebagian besar prinsip SOLID tidak selalu berlaku pada tahap pengembangan aplikasi Anda. Sebagai contoh, apakah Anda harus membagi akses data tergantung pada seberapa rumitnya itu, dan apakah Anda ingin menguji logika repositori Anda tanpa mengenai database. Sepertinya ini tidak mungkin (sayangnya, menurut saya), jadi mungkin tidak perlu.
Jadi setelah semua pertimbangan itu, kami menemukan bahwa YAGNI dan SOLID benar-benar memberikan satu saran umum yang solid, relevan segera: Mungkin tidak perlu membuat antarmuka repositori umum yang umum.
Semua pemikiran yang cermat ini sangat berguna sebagai latihan pembelajaran. Ini memakan waktu ketika Anda belajar, tetapi seiring waktu Anda mengembangkan intuisi dan menjadi sangat cepat. Anda akan tahu hal yang benar untuk dilakukan, tetapi tidak perlu memikirkan semua kata-kata ini kecuali seseorang meminta Anda untuk menjelaskan alasannya.