Apakah cukup untuk metode dibedakan hanya dengan nama argumen (bukan tipe)?

Apakah cukup untuk metode dibedakan hanya dengan nama argumen (bukan tipe) atau lebih baik untuk nama lebih eksplisit?

Misalnya T Find<T>(int id)vs T FindById<T>(int id).

Apakah ada alasan yang baik untuk menamainya lebih eksplisit (yaitu menambahkan ById) vs mempertahankan nama argumen yang adil?

Salah satu alasan yang bisa saya pikirkan adalah ketika tanda tangan dari metode yang sama tetapi mereka memiliki makna yang berbeda.

FindByFirstName(string name) dan FindByLastName(string name)

Tentu ada alasan bagus untuk menyebutkannya secara lebih eksplisit.

Ini terutama bukan definisi metode yang harus jelas, tetapi metode yang digunakan . Dan sementara findById(string id)dan find(string id)keduanya cukup jelas, ada perbedaan besar antara findById("BOB")dan find("BOB"). Dalam kasus sebelumnya Anda tahu bahwa literal acak, pada kenyataannya, adalah ID. Dalam kasus terakhir Anda tidak yakin - itu mungkin sebenarnya nama yang diberikan atau sesuatu yang lain sama sekali.

Keuntungan FindById () .

1. Masa depan-pemeriksaan : Jika Anda memulai dengan Find(int), dan kemudian harus menambahkan metode lain ( FindByName(string), FindByLegacyId(int), FindByCustomerId(int), FindByOrderId(int), dll), orang-orang seperti saya cenderung menghabiskan usia mencari FindById(int). Tidak benar-benar masalah jika Anda bisa dan akan berubah Find(int)menjadi FindById(int)begitu diperlukan - pemeriksaan di masa depan adalah tentang ini jika s.

2. Lebih mudah dibaca . Findbaik-baik saja jika panggilannya seperti record = Find(customerId);Namun FindByIdsedikit lebih mudah untuk dibaca jika itu record = FindById(AFunction());.

3. Konsistensi . Anda dapat secara konsisten menerapkan FindByX(int)/ FindByY(int)pola di mana-mana, tetapi Find(int X)/ Find(int Y)tidak mungkin karena mereka bertentangan.

Keuntungan Menemukan ()

• CIUMAN. Findsederhana dan mudah, dan di samping operator[]itu salah satu dari 2 nama fungsi yang paling diharapkan dalam konteks ini. (Beberapa alternatif populer menjadi get, lookupatau fetch, tergantung pada konteks).
• Sebagai aturan praktis, jika Anda memiliki nama fungsi yang merupakan kata tunggal terkenal yang secara akurat menjelaskan apa fungsi tersebut, gunakan itu. Bahkan jika ada nama multi-kata yang lebih panjang yang sedikit lebih baik dalam menggambarkan apa fungsinya. Contoh: Panjang vs NumberOfElements . Ada tradeoff, dan di mana menarik garis adalah subjek dari perdebatan yang sedang berlangsung.
• Biasanya bagus untuk menghindari redundansi. Jika kita melihat FindById(int id), kita dapat dengan mudah menghapus redundansi dengan mengubahnya Find(int id), tetapi ada trade off - kita kehilangan kejelasan.

Atau Anda bisa mendapatkan keuntungan dari keduanya dengan menggunakan Id yang sangat diketik:

CustomerRecord Find(Id<Customer> id) 
// Or, depending on local coding standards
CustomerRecord Find(CustomerId id) 

Implementasi Id<>: Sangat mengetik nilai ID di C #

Komentar di sini, serta di link di atas, mengangkat beberapa kekhawatiran tentang Id<Customer>bahwa saya ingin alamat:

• Masalah 1: Ini penyalahgunaan obat generik. CustomerIddan OrderIDtipe yang berbeda ( customerId1 = customerId2;=> baik, customerId1 = orderId1;=> buruk), tetapi implementasinya hampir identik, sehingga kami dapat mengimplementasikannya baik dengan salin tempel atau dengan metaprogramming. Meskipun ada nilai dalam diskusi tentang mengekspos atau menyembunyikan generik, metaprogramming adalah tujuan generik.
• Kekhawatiran 2: Itu tidak menghentikan kesalahan sederhana./Ini adalah solusi dalam mencari masalah Masalah utama yang dihapus dengan menggunakan Id sangat diketik adalah urutan argumen yang salah dalam panggilan ke DoSomething(int customerId, int orderId, int productId). Id yang diketik dengan kuat juga mencegah masalah lain, termasuk yang ditanyakan OP.
• Kekhawatiran 3: Ini benar-benar hanya mengaburkan kode. Sulit untuk mengetahui apakah ada id yang ditahan int aVariable. Sangat mudah untuk mengetahui bahwa ID telah disimpan Id<Customer> aVariable, dan kami bahkan dapat mengatakan bahwa itu adalah ID pelanggan.
• Kekhawatiran 4: Id ini bukan tipe yang kuat, hanya pembungkus. Stringhanyalah pembungkus di sekitar byte[]. Pembungkus, atau enkapsulasi, tidak bertentangan dengan pengetikan yang kuat.
• Kekhawatiran 5: Sudah selesai direkayasa. Inilah versi minimalnya, walaupun saya merekomendasikan untuk menambahkan operator==dan operator!=juga, jika Anda tidak ingin bergantung secara eksklusif pada Equals:

.

public struct Id<T>: {
    private readonly int _value ;
    public Id(int value) { _value = value; }
    public static explicit operator int(Id<T> id) { return id._value; }
}

Cara lain untuk berpikir tentang ini adalah dengan menggunakan jenis keamanan bahasa.

Anda dapat menerapkan metode seperti:

Find(FirstName name);

Di mana FirstName adalah objek sederhana yang membungkus string yang berisi nama depan dan berarti tidak ada kebingungan tentang apa yang dilakukan metode ini, atau dalam argumen yang disebutnya.

Saya akan memilih deklarasi eksplisit seperti FindByID .... Perangkat lunak harus dibangun untuk Perubahan. Itu harus terbuka dan tertutup (SOLID). Jadi kelas terbuka untuk menambahkan metode menemukan yang mirip seperti katakanlah FindByName .. dll.

Tetapi FindByID ditutup dan implementasinya diuji unit.

Saya tidak akan menyarankan metode dengan predikat, itu bagus di tingkat generik. Bagaimana jika berdasarkan bidang (ByID) Anda memiliki metodologi yang berbeda lengkap.

Saya terkejut tidak ada yang menyarankan untuk menggunakan predikat seperti berikut:

User Find(Predicate<User> predicate)

Dengan pendekatan ini tidak hanya Anda mengurangi permukaan API Anda, tetapi juga memberikan lebih banyak kontrol kepada pengguna yang menggunakannya.

Jika itu tidak cukup, Anda selalu dapat mengembangkannya sesuai kebutuhan Anda.