Menggunakan nama yang sama untuk namespace dan kelas di dalamnya bermasalah.
Jika namespace berisi lebih dari satu kelas, mengapa kelas lain diletakkan di sana? rasanya tidak benar, karena tujuan dari nama namespace adalah untuk menggambarkan semua kelas di dalamnya, bukan hanya satu. Misalnya, jika Anda memiliki JsonSerialization
, BinarySerialization
dan XmlSerialization
kelas di namespace, apakah masuk akal untuk memberi nama namespace Anda XmlSerialization
?
Apa yang biasanya terjadi adalah bahwa karena ekstraksi kelas dari namespace yang ada, atau gabungan antara beberapa kelas atau reorganisasi lainnya, Anda menemukan diri Anda dengan namespace yang mengandung kelas utama ; secara progresif, kelas-kelas minor ditempatkan di sana karena mereka sedikit terkait dengan kelas asli. Misalnya, namespace LogParser
dapat berisi satu kelas LogParser
, dan kemudian seseorang meletakkannya LogConverter
, karena itu cukup terkait dengan parser, lalu LogSearcher
, dll. Masalahnya di sini adalah bahwa nama namespace tidak berubah: segera setelah LogConverter
ditambahkan, the nama seharusnya diubah menjadi LogsProcessing
atau, sederhananya Logs
,.
Jika namespace hanya berisi satu kelas, itu mungkin merupakan tanda masalah dalam organisasi kode.
Walaupun saya telah melihat beberapa kali situasi di mana satu kelas dengan prinsip SOLID yang tepat sangat berbeda dari apa pun dalam basis kode dan oleh karena itu dimasukkan ke dalam namespace khusus, kasus seperti itu jarang terjadi. Lebih sering, ini merupakan indikasi masalah. Demikian pula, tidak ada yang mencegah Anda memiliki kelas yang berisi metode tunggal, tetapi lebih sering daripada tidak, kelas tersebut akan menunjukkan masalah.
Bahkan jika namespace Anda hanya berisi satu kelas, biasanya ada cara untuk lebih spesifik ketika memberi nama kelas, dan lebih umum ketika memberi nama namespace. Bayangkan aplikasi yang, antara lain, pada saat tertentu harus mengkonversi file yang ditulis dalam format ABC ke format DEF. Konversi tidak memerlukan deserialisasi / serialisasi ke / dari objek bisnis, dan dilakukan dengan menerapkan banyak ekspresi reguler yang cukup pendek untuk dimasukkan ke dalam kelas konversi itu sendiri yang disebutAbcToDefConverter
. Semua logika konversi membutuhkan sekitar 80 LLOC dalam sekitar sepuluh metode yang saling tergantung — sepertinya situasi di mana sama sekali tidak perlu untuk memecah kelas yang ada, atau membuat kelas tambahan. Karena bagian aplikasi yang tersisa tidak ada hubungannya dengan konversi, kelas tidak dapat dikelompokkan dengan kelas lain di ruang nama yang ada. Jadi seseorang menciptakan namespace yang disebut AbcToDefConverter
. Meskipun tidak ada yang salah secara inheren dalam hal itu, orang juga bisa menggunakan nama yang lebih umum, seperti Converters
. Dalam bahasa seperti Python, di mana nama yang lebih pendek lebih disukai dan pengulangan dilemparkan, itu bahkan menjadi converters.Abc_To_Def
.
Oleh karena itu, gunakan nama yang berbeda untuk ruang nama daripada kelas yang dikandungnya. Nama kelas harus menunjukkan apa yang dilakukan kelas, sementara nama namespace harus menyoroti apa yang umum di semua kelas yang dimasukkan ke dalamnya.
By the way, kelas utilitas secara alami salah: alih-alih mengandung sesuatu yang spesifik, seperti aritmatika presisi sewenang-wenang, mereka lebih berisi segala sesuatu yang belum menemukan jalannya di kelas lain . Ini hanyalah penamaan yang buruk, sama seperti Miscellaneous
direktori di desktop — sesuatu yang menunjukkan kurangnya organisasi.
Penamaan ada karena suatu alasan: untuk membuat hidup Anda lebih mudah ketika Anda perlu menemukan barang nanti. Anda tahu bahwa jika Anda perlu menggambar bagan, Anda dapat mencoba mencari "bagan" atau "plot". Saat Anda perlu mengubah cara aplikasi membuat faktur, Anda akan mencari "faktur" atau "tagihan". Demikian pula, coba bayangkan sebuah kasus di mana Anda akan berkata pada diri sendiri: "hm, fitur ini mungkin bisa ditemukan di misc" Saya tidak bisa.
Lihatlah .NET Framework. Bukankah sebagian besar dari kelas utilitas kelas? Maksud saya, ada beberapa hal yang berkaitan dengan domain bisnis. Jika saya bekerja pada aplikasi keuangan, atau situs web e-commerce, atau platform pendidikan generasi berikutnya, membuat serialisasi XML atau membaca file atau melakukan query SQL atau melakukan transaksi adalah semua hal yang bermanfaat. Namun, mereka tidak dipanggil UtilitySerialization
atau UtilityTransaction
, dan mereka tidak ada dalam Utility
namespace. Mereka memiliki nama yang tepat, yang memungkinkan (dan mudah, terima kasih. Pengembang NET!) Untuk menemukannya ketika saya membutuhkannya.
Hal yang sama datang untuk Anda kelas Anda sering menggunakan kembali dalam aplikasi Anda. Mereka bukan kelas utilitas. Mereka adalah kelas-kelas yang melakukan hal-hal tertentu, dan hal-hal yang mereka lakukan sebenarnya haruslah nama-nama kelas tersebut.
Bayangkan Anda membuat beberapa kode yang berkaitan dengan unit dan konversi unit. Anda dapat menyebutkannya Utility
dan dibenci oleh kolega Anda; atau Anda dapat memberi nama Units
dan UnitsConversion
.