Apa pendekatan terbaik untuk menamai kelas?


92

Mendapatkan nama yang bagus dan tepat untuk kelas sangatlah sulit. Jika dilakukan dengan benar, ini membuat kode lebih terdokumentasi sendiri dan memberikan kosakata untuk penalaran tentang kode pada tingkat abstraksi yang lebih tinggi.

Kelas yang menerapkan pola desain tertentu mungkin diberi nama berdasarkan nama pola terkenal (misalnya FooFactory, FooFacade), dan kelas yang secara langsung memodelkan konsep domain dapat mengambil namanya dari domain masalah, tetapi bagaimana dengan kelas lain? Apakah ada tesaurus programmer yang bisa saya gunakan ketika saya kekurangan inspirasi, dan ingin menghindari penggunaan nama kelas umum (seperti FooHandler, FooProcessor, FooUtils, dan FooManager)?


6
Ini adalah pertanyaan yang sangat bagus! Menutupnya adalah IMHO tidak berdasar, lebih baik akan memigrasi situs programmer.
Timofey

1
Saya setuju, harus dibuka kembali atau dipindahkan
ftl


Saya telah melihat banyak pertanyaan luar biasa ini "ditutup oleh casperOne". Mungkin dia bisa menjadi deletionist di Wikipedia?
Perlator

Jawaban:


59

Saya akan mengutip beberapa bagian dari Pola Implementasi oleh Kent Beck:

Nama Superclass Sederhana

"[...] Nama harus pendek dan kuat. Namun, untuk membuat nama yang tepat terkadang memerlukan beberapa kata. Jalan keluar dari dilema ini adalah memilih metafora yang kuat untuk komputasi. Dengan metafora dalam pikiran, bahkan satu kata membawa serta jaringan asosiasi, koneksi, dan implikasi yang kaya. Misalnya, dalam kerangka gambar HotDraw, nama depan saya untuk objek dalam gambar adalah DrawingObject . Ward Cunningham datang dengan metafora tipografi: gambar itu seperti halaman yang dicetak dan ditata. Item grafis pada halaman adalah gambar, sehingga kelasnya menjadi Figur . Dalam konteks metafora, Figur secara bersamaan lebih pendek, lebih kaya, dan lebih tepat daripada DrawingObject . "

Nama Subclass Berkualifikasi

"Nama-nama subclass memiliki dua pekerjaan. Mereka perlu mengkomunikasikan seperti apa kelas mereka dan bagaimana mereka berbeda. [...] Tidak seperti nama-nama di akar hierarki, nama subclass tidak digunakan hampir sesering dalam percakapan, sehingga mereka bisa ekspresif dengan biaya yang ringkas. [...]

Beri nama sederhananya pada subclass yang berfungsi sebagai akar hierarki. Misalnya, HotDraw memiliki kelas Handle yang menampilkan operasi pengeditan gambar ketika gambar dipilih. Ini disebut, sederhana, Menangani meskipun memperluas Gambar . Ada banyak jenis pegangan dan mereka paling tepat memiliki nama seperti StretchyHandle dan TransparencyHandle . Karena Handle adalah root dari hierarkinya sendiri, ia membutuhkan nama superclass sederhana lebih dari sekedar nama subclass yang memenuhi syarat.

Kerutan lain dalam penamaan subclass adalah hierarki multi-level. [...] Daripada membabi buta menambahkan pengubah ke superclass langsung, pikirkan tentang nama dari sudut pandang pembaca. Kelas apa yang dia butuhkan untuk mengetahui kelas ini? Gunakan superclass itu sebagai dasar untuk nama subclass. "

Antarmuka

Dua gaya antarmuka penamaan bergantung pada bagaimana Anda memikirkan antarmuka. Antarmuka sebagai kelas tanpa implementasi harus dinamai seolah-olah kelas ( Nama Superclass Sederhana , Nama Subclass Memenuhi Syarat ). Satu masalah dengan gaya penamaan ini adalah bahwa nama-nama baik digunakan sebelum Anda mendapatkan kelas penamaan. Antarmuka bernama File membutuhkan kelas implementasi yang disebut sesuatu seperti ActualFile , ConcreteFile , atau (yuck!) FileImpl(sufiks dan singkatan). Secara umum, mengkomunikasikan apakah seseorang berurusan dengan objek konkret atau abstrak itu penting, apakah objek abstrak diimplementasikan sebagai antarmuka atau superclass kurang penting. Menunda perbedaan antara antarmuka dan superkelas> didukung dengan baik oleh gaya penamaan ini, membuat Anda bebas untuk berubah pikiran nanti jika> itu diperlukan.

Terkadang, menamai kelas konkret lebih penting untuk komunikasi daripada menyembunyikan penggunaan antarmuka. Dalam hal ini, awalan nama antarmuka dengan “I”. Jika antarmuka disebut IFile , kelas dapat disebut File .

Untuk pembahasan lebih detail, beli bukunya! Itu sangat berharga! :)


1
"Kadang-kadang, menamai kelas konkrit lebih penting untuk komunikasi daripada menyembunyikan penggunaan antarmuka. Dalam hal ini, awali nama antarmuka dengan" I ". Jika antarmuka disebut IFile, kelas tersebut dapat disebut File." Lucu sekali, karena dalam buku Clean Code oleh Robert C. Martin, saya menemukan bahwa kami lebih suka menamai implementasi sebagai FileImpl, daripada menamai antarmuka seperti IFile, karena kami tidak ingin klien tahu bahwa kami melayani mereka dan antarmuka. Dan di buku ^ ada kutipan dari buku yang Anda maksud :)
Cristian Ciobotea

38

Selalu gunakan MyClassA, MyClassB - Ini memungkinkan untuk jenis alfa yang bagus ..

Aku bercanda!

Ini adalah pertanyaan yang bagus, dan sesuatu yang saya alami belum lama ini. Saya sedang mengatur ulang basis kode saya di tempat kerja dan mengalami masalah di mana harus meletakkan apa, dan apa namanya ..

Masalah sebenarnya ?

Aku terlalu banyak mengikuti kelas. Jika Anda mencoba untuk mengikuti prinsip tanggung jawab tunggal itu akan membuat semuanya menjadi jauh lebih baik .. Daripada satu kelas PrintHandler monolitik , Anda dapat memecahnya menjadi PageHandler , PageFormatter (dan seterusnya) dan kemudian memiliki kelas Pencetak master yang mana menyatukan semuanya.

Dalam re-org saya, butuh waktu, tetapi saya akhirnya mengumpulkan banyak kode duplikat, membuat basis kode saya jauh lebih logis dan belajar banyak ketika harus berpikir sebelum melempar metode tambahan di kelas: D

Namun saya tidak akan merekomendasikan untuk memasukkan hal-hal seperti nama pola ke dalam nama kelas. Antarmuka kelas harus membuatnya jelas (seperti menyembunyikan konstruktor untuk singleton). Tidak ada yang salah dengan nama generik, jika kelas melayani tujuan umum.

Semoga berhasil!


Setuju dengan tidak memasukkan nama pola ke dalam nama kelas. Bagaimana jika pola berubah kemudian saat implementasi berubah?
thegreendroid

2
Saya lebih suka memberi nama pola dalam nama. Mengapa? Karena jika saya harus melihat detail implementasi (seperti konstruktor pribadi) untuk mengetahui bahwa itu tunggal, yang memperlambat saya sebagai pembaca dan bergantung pada tingkat keahlian saya, saya mungkin tidak tahu bahwa itu sebenarnya bagian kelas dari pola umum. Konstruktor tunggal dan pribadi adalah contoh yang dipertanyakan, tetapi untuk pola yang lebih rumit (Pengunjung, Adaptor, dll.) Menjadi cukup rumit. Jika polanya berubah, perubahannya adalah bahwa kelas-kelas itu tidak akan ada lagi ...
dragan.stepanovic

28

Pembicaraan Josh Bloch yang sangat baik tentang desain API yang baik memiliki beberapa saran bagus:

  • Kelas harus melakukan satu hal dan melakukannya dengan baik.
  • Jika sebuah kelas sulit untuk disebutkan atau dijelaskan, maka kelas tersebut mungkin tidak mengikuti saran di poin-poin sebelumnya.
  • Nama kelas harus langsung mengkomunikasikan apa kelas itu.
  • Nama yang bagus mendorong desain yang bagus.

Jika masalah Anda adalah apa yang harus dinamai kelas internal yang terbuka, mungkin Anda harus menggabungkannya ke dalam kelas yang lebih besar.

Jika masalah Anda adalah menamai kelas yang melakukan banyak hal berbeda, Anda harus mempertimbangkan untuk memecahnya menjadi beberapa kelas.

Jika itu adalah saran yang bagus untuk API publik maka tidak ada salahnya untuk kelas lain.


1
tautan video di youtube youtube.com/watch?v=aAb7hSCtvGw
Andrew Harry

12

Jika Anda terjebak dengan nama, kadang-kadang hanya memberikan setiap nama setengah-masuk akal dengan komitmen untuk merevisi nanti adalah strategi yang baik.

Jangan mengalami kelumpuhan penamaan. Ya, nama itu sangat penting tetapi tidak cukup penting untuk membuang banyak waktu. Jika Anda tidak dapat menemukan nama yang baik dalam 10 menit, lanjutkan.


9

Jika nama yang baik tidak muncul dalam pikiran, saya mungkin akan mempertanyakan apakah ada masalah yang lebih dalam - apakah kelas memiliki tujuan yang baik? Jika ya, menamainya harus cukup mudah.


3

Jika "FooProcessor" Anda benar-benar memproses foo, jangan segan-segan memberikan nama tersebut hanya karena Anda sudah memiliki BarProcessor, BazProcessor, dll. Jika ragu, jelaslah yang terbaik. Pengembang lain yang harus membaca kode Anda mungkin tidak menggunakan tesaurus yang sama dengan Anda.

Meskipun demikian, lebih spesifik tidak ada salahnya untuk contoh khusus ini. "Proses" adalah kata yang cukup luas. Apakah itu benar-benar sebuah "FooUpdateProcessor" (yang mungkin menjadi "FooUpdater"), misalnya? Anda tidak harus terlalu "kreatif" tentang penamaannya, tetapi jika Anda yang menulis kode, Anda mungkin memiliki gagasan yang cukup baik tentang apa yang dilakukannya dan tidak lakukan.

Terakhir, ingatlah bahwa nama kelas telanjang bukanlah semua yang Anda dan pembaca kode harus teruskan - biasanya ada ruang nama yang juga digunakan. Itu sering kali dapat memberikan konteks yang cukup kepada pembaca untuk melihat dengan jelas untuk apa kelas Anda sebenarnya, meskipun nama kosongnya cukup umum.

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.