Penamaan antarmuka: awalan 'Can-' vs suffix '-Able'


29

Sangat umum untuk menggunakan '-able' sebagai sufiks untuk antarmuka misalnya

Serializable Cetak Dapat Diminum Minum Dapat Diputar Diputar

Saya berpikir bahwa 'Can-' mungkin lebih baik karena mungkin lebih deskriptif. Ya, ini lebih bertele-tele dan itu menambahkan noise ke nama antarmuka. Secara khusus, kata kerja pasif dapat digunakan.

Misalnya 1 apakah Shootable berarti bahwa objek dapat menembak (pistol mungkin menerapkan ini), atau apakah itu berarti dapat ditembakkan (papan target mungkin mengimplementasikan ini). Dengan awalan 'Can-', yang pertama adalah "CanShoot" dan yang terakhir adalah "CanBeShotAt" atau "CanShootAt".

Misalnya 2 Dokumen 'CanBePrinted' dan printer 'CanPrint'

Atau, haruskah kita tetap dengan '-Mampu' dan membiarkan dokumentasi memberikan konteks?

Ada pendapat.


Man, gunakan "-able". Periode.
Tulains Córdova

2
Gunakan keduanya untukclass Cannibal implements Can, Able {}
Thomas Eding

Jawaban:


18

Mungkin Anda ingin Mampu?

Beberapa contoh dari .Net:

NetworkStream.Readable
NetworkStream.Writable
Stream.CanRead
Stream.CanWrite
Type.IsSerializable

Tampaknya tidak ada standar yang seragam. Ikuti apa yang berbunyi dengan baik.

if (document.IsPrintable && printer.CanPrint) { printer.Print(document) }

EDIT: Seperti yang ditunjukkan, pertanyaannya adalah tentang Antarmuka, bukan Properti.

Dalam hal ini, saya tidak dapat menemukan antarmuka bernama Can-. Antarmuka cenderung selalu menggunakan -able. Saya setuju dengan terminologi ini. Suatu metode dapat meminta sebagai parameter a ISerializable objectatau IPrintable document. Meminta a ICanBeSerialized objectatau a ICanBePrinted documentsangat canggung untuk dibaca.

Di sisi lain, Printer, saya sarankan hanya memanggil antarmuka IPrinter. Metode Anda akan meminta a IPrinter device.

Baca tanda tangan metode di bawah ini dengan keras. (Secara pribadi, saya menganggap awalan "Saya" sebagai diam.) Apakah itu terbaca dengan baik? Apakah itu terdengar benar?

void PrintDocument(IPrinter device, IPrintable document)
{
    device.Print(document)
}

2
Document.IsPrintable lebih baik dari Document.CanBePrinted. Sejauh yang saya tahu mereka dapat digunakan-untuk menghindari suara pasif.
Thanos Papathanasiou

"Dapat dicetak" sepertinya bahasa Inggris yang lebih tepat daripada "dapat dicetak".
Danny Varod

1
"Suara pasif digunakan ketika fokusnya adalah pada tindakan. Namun tidak penting atau tidak diketahui, siapa atau apa yang melakukan tindakan itu." Saya hanya bisa menebak bahwa mereka ingin fokus untuk tetap pada objek dan bukan aksinya. Jadi jika "Type.IsSerializable" melempar pengecualian, itu salah Type. bukan metode 'tetapi jika "Type.CanBeSerialized" melempar pengecualian maka Anda akan menyalahkan metode dan bukan tipe. Diakui perbedaannya kecil tetapi ada di sana.
Thanos Papathanasiou

3
Saya melihat bahwa ini adalah jawaban yang diterima, tetapi ini tidak menjawab pertanyaan OP. Contoh yang diberikan adalah Nama properti . OP adalah meminta konvensi penamaan untuk Antarmuka nama, seperti ISerializable, IDataErrorInfo, dan INotifyPropertyChanged.
Kevin McCormick

@KevinMcCormick, poin bagus! Suntingan di atas.
Hand-E-Food

23

Secara tata bahasa, "canFoobar" adalah predikat, sedangkan "Foobarable" adalah kata sifat atau kata benda (biasanya kata benda dalam konteks API).

Perhatikan juga perbedaannya yang halus: -able menyiratkan peran pasif pada kata benda yang diterapkan, yaitu, jika Something itu Foobarable, maka ia dapat dibuat foobarred oleh sesuatu yang lain; dapat- menyiratkan peran aktif, yaitu, jika Sesuatu dapatFoobar, maka itu dapat membentuk sesuatu yang lain. Atau, dari sudut yang berbeda: jika A bisa foobar B, maka A.canFoobar()dan B is Foobarable.

Dalam hal ekspresif OOP, saya akan mengasosiasikan predikat dengan metode atau properti, sementara kata benda adalah kelas atau antarmuka. Begitu:

instance.canFoobar();

class Something implements Foobarable { ... }

7

Secara pribadi saya akan tetap menggunakan versi -able. Inilah alasan saya: Kebanyakan (semua?) Editor grafis menyarankan pengidentifikasi berdasarkan apa yang Anda ketikkan. Meskipun beberapa dari mereka cukup 'pintar' untuk mencari di dalam pengidentifikasi, beberapa masih menawarkan awal pencarian pengidentifikasi.

Untuk mempercepat pengetikan, Anda ingin mempersingkat daftar pengidentifikasi yang disarankan dengan penekanan tombol sesedikit mungkin. Semakin banyak pengidentifikasi memiliki awal yang sama, misalnya 'IC -' semakin banyak karakter yang harus Anda ketik.

Jika Anda pikir ini bukan masalah dalam kasus Anda, maka itu hebat dan saya akan merekomendasikan menggunakan kriteria lain untuk memilih konvensi penamaan. Dalam beberapa kasus, misalnya dalam tim kami, kami lebih suka pengidentifikasi yang membedakan setelah penekanan tombol sesedikit mungkin.

Selain itu saya akan merekomendasikan untuk menggunakan konvensi penamaan yang membuat kode Anda paling mudah dipahami oleh mereka yang bekerja di proyek. Lakukan percakapan dalam tim Anda. Tidak ada yang benar atau salah. Hanya konvensi yang berhasil dan konvensi yang kurang berhasil.

Jangan lupa bahwa alat refactoring yang baik memungkinkan Anda untuk mengubah nama sesering yang Anda inginkan. Jadi mudah untuk bereksperimen dengan berbagai pendekatan.


1
+1. Alasan saya akan sama, letakkan kata kerja pengontrol terlebih dahulu untuk membuatnya lebih mudah untuk mencari / menemukan / mengurutkan dalam IDE.
Pap

1
Intellisense tidak hanya berfungsi seperti itu, tetapi juga teks pemindaian manusia, awalan membuat kode Anda kurang terbaca
jk.

7

Jelas awalan dan sufiks adalah pilihan yang hampir jelas untuk jenis tindakan yang berbeda atau lebih tepatnya, arah tindakan yang berbeda.

Penggunaan dan preferensi saat ini mungkin tidak konsisten karena berbagai alasan.

Tindakan dilakukan oleh objek:
CanShoot -> Ini menembak (pada) sesuatu
CanFly -> Itu terbang
CanChange -> Itu berubah

Tindakan dilakukan pada objek:
Dapat dibaca -> Anda dapat membacanya
Tertulis -> Anda dapat menulis (untuk) dicetak
-> Anda dapat mencetaknya

Meskipun mungkin bukan aturan atau bahkan logis, itu membantu untuk mengadopsi konvensi dan mempertahankan konsistensi penggunaan dalam penamaan variabel.


4

Saya pikir Anda mungkin ingin membedakan antara kemampuan dan izin. Sementara Serializabledan CanSerializemenyiratkan bahwa sesuatu mampu diserialisasi, ada juga masalah izin (atau mungkin kurangnya ruang disk) dan Anda mungkin perlu mempertimbangkan MaySerialize. Membiarkan segala sesuatu ~ablemenghilangkan kebutuhan untuk membedakan antara candan may.


SerializableIfNotDiskFullAndIfNotPermissionMissing ... Lol :)
Max

2

Ketika subclassing / mengimplementasikan antarmuka saya pikir aturan praktis adalah bahwa Anda harus dapat mengatakan "B adalah A" (di mana B mengimplementasikan A). Kedengarannya tidak benar untuk mengatakan:

A Documentadalah aCanBePrinted

Tapi kedengarannya benar (atau setidaknya lebih baik) untuk mengatakan:

A Documentadalah aPrintable


2

Saya pikir Xable baik tata bahasa maupun konvensi lebih baik untuk nama antarmuka, sedangkan IsX, CanX, DoesX lebih baik untuk nama properti.

Dari MSDN:

"Beri nama properti Boolean dengan frasa afirmatif (CanSeek dan bukan CantSeek). Secara opsional, Anda juga bisa mengawali properti Boolean dengan Is, Can, atau Has, tetapi hanya jika itu menambah nilai." http://msdn.microsoft.com/en-us/library/ms229012.aspx


+1 untuk tautan bermanfaat; Saya tidak pernah tahu apa yang harus
disebutkan

0

Menurut pendapat saya, varian "-able" jauh lebih mudah dibaca daripada yang Anda usulkan "CanDoSomething" yang memaksakan lebih banyak punuk unta.


1
dan Can- lebih merupakan nama metode
ratchet freak

Nama properti - lihat MSDN. Nama metode harus berupa "kata kerja atau frasa kata kerja". Selain itu, apa yang salah dengan beberapa punuk?
Danny Varod

0

Dalam Scala, *Abledigunakan untuk antarmuka, tetapi Can*digunakan untuk pola kelas tipe. Pada dasarnya, untuk dapat memanggil metode tertentu, nilai implisit dari jenis tertentu harus ada dalam ruang lingkup. Nama tipe ini terkadang diawali dengan Can.


Can * bukan nama yang baik untuk sebuah kelas. Kutipan dari MSDN: "Apakah kelas nama, antarmuka, dan tipe nilai dengan kata benda, frasa kata benda, atau frasa kata sifat sesekali, menggunakan casing Pascal", tautan: msdn.microsoft.com/en-us/library/ms229040.aspx Nama yang baik untuk kelas akan menjadi Dokumen, nama yang dapat diterima akan Dicetak.
Danny Varod

Salah satu contoh dalam bahasa Scala adalah CanBuildFrom. Ini akan menjadi frase kata sifat. Kasus penggunaan kelas ini sangat berbeda dari kelas-kelas lain. Contoh kelas ini hampir tidak pernah dibangun atau diselesaikan oleh klien - melainkan, mereka tersedia dalam ruang lingkup untuk jenis tertentu. Jika mereka tersedia untuk jenis tertentu, maka metode yang melibatkan jenis yang ditandai untuk memerlukan kelas ini dapat dipanggil. Ini ada untuk menawarkan mekanisme ekstensibilitas yang lebih fleksibel daripada subtyping. Lihat scala-lang.org/node/114 .
axel22

Saya hanya ingat menggunakan kata sifat untuk kelas tiruan yang mengimplementasikan antarmuka untuk pengujian unit - karena mereka tidak memiliki peran nyata.
Danny Varod
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.