Satu kelas per aturan file dalam .NET? [Tutup]

Saya mengikuti aturan ini tetapi beberapa rekan saya tidak setuju dengan itu dan berpendapat bahwa jika suatu kelas lebih kecil dapat dibiarkan dalam file yang sama dengan kelas lainnya.

Argumen lain yang saya dengar sepanjang waktu adalah "Bahkan Microsoft tidak melakukan ini, jadi mengapa kita harus melakukannya?"

Apa konsensus umum tentang ini? Apakah ada kasus di mana ini harus dihindari?

Satu kelas per file juga memberi Anda gagasan yang lebih baik tentang perubahan setiap check in tanpa melihat perbedaan file.

Saya benci ketika orang berpikir secara absolut dan mengatakan Anda tidak boleh melakukan ini atau itu dengan sesuatu yang subyektif dan rewel seperti ini, seolah-olah kita semua harus menyesuaikan diri dengan ide bodoh tentang benar dan salah. Intinya: memiliki lebih dari satu kelas per file sama sekali baik-baik saja jika masuk akal. Secara masuk akal saya maksudkan hal-hal seperti:

1. Membuat kode lebih mudah dicerna dan dipelihara
2. Menjadikan solusi kurang mengganggu (menggulir file yang tidak perlu yang tak terhitung jumlahnya) dan kurang lambat
3. Tim dev baik-baik saja dengan itu sebagai praktik pengkodean lokal

Contoh yang sangat bagus mengapa saya ingin beberapa kelas per file:

Katakanlah saya punya beberapa lusin kelas pengecualian kustom, masing-masing adalah 4 liner, saya dapat memiliki file terpisah untuk masing-masing atau saya dapat mengelompokkan pengecualian dan memiliki file per grup. Bagi saya yang tampaknya pendekatan yang paling rasional / pragmatis adalah mengelompokkannya, dan hanya memiliki beberapa file, karena itu lebih efisien waktu / coding bijaksana (saya tidak perlu klik kanan -> Tambah Kelas, ganti nama, 50 kali) , itu membuat solusinya kurang berantakan dan berkinerja lebih baik.

static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}

Saya kadang-kadang mengelompokkan lebih dari satu kelas dalam sebuah file jika mereka digabungkan dengan erat dan setidaknya satu dari mereka sangat kecil.

'Praktik terbaik' umum adalah memiliki satu file per kelas.

Melampaui argumen hipotetis dan sebagai gantinya berfokus pada Windows .NET dengan Visual Studio IDE dan proyek perangkat lunak yang berkembang, masuk akal dalam konteks ini untuk memiliki satu kelas per file.

Secara umum, untuk referensi visual tidak ada yang mengalahkan satu kelas per file. Betulkah.

Saya tidak tahu apakah Microsoft melakukan atau tidak melakukan hal yang sama, namun mereka membuat partialkata kunci untuk membagi satu kelas menjadi beberapa file (ini bahkan lebih parah). Ini sering digunakan untuk memisahkan kode desainer yang dibuat secara otomatis dari kode khusus Anda di kelas yang sama (tetapi kadang-kadang digunakan untuk memungkinkan pengembang yang berbeda untuk bekerja di kelas pada saat yang sama melalui file yang berbeda). Jadi Microsoft memang melihat manfaat dari banyak file dan semua orang pasti memikirkan beberapa organisasi file dengan .NET.

Untuk kelas bersarang Anda tidak punya pilihan selain menggunakan satu file, atau setidaknya bagian pertama dari kelas di dalamnya. Satu file diperlukan dan baik-baik saja dalam hal ini:

class BicycleWheel {
    class WheelSpoke {
    }
}

Kalau tidak, mengapa Anda menyimpan beberapa kelas dalam satu file? Argumen "karena mereka kecil" atau terkait satu sama lain tidak menampung banyak air karena akhirnya kelas Anda akan dikaitkan dengan kelas lain. Pada akhirnya Anda tidak dapat dengan mudah menyimpulkan organisasi file dalam objek berdasarkan penggunaannya terutama ketika perangkat lunak terus tumbuh.

Selain itu jika Anda menggunakan folder untuk ruang nama maka Anda tidak akan pernah memiliki bentrokan nama file kelas. Juga mudah untuk menemukan kelas dengan nama file pada sistem file ketika tidak di dalam lingkungan pengembangan seperti Visual Studio (misalnya jika Anda ingin dengan cepat mengedit kelas dengan Notepad atau sesuatu yang cepat / ringan ).

Banyak alasan bagus ...

Dalam sebagian besar kasus, saya mengikuti satu kelas per aturan file. Satu-satunya pengecualian yang saya buat secara berkala adalah definisi enum yang digabungkan secara ketat ke kelas tertentu. Dalam satu kasus itu, saya akan sering memasukkan definisi enum dalam file kelas itu.

Saya juga percaya harus ada satu jenis yang termasuk dalam satu file.

Ada satu pengecualian untuk aturan ini yang harus disebutkan: Memiliki dua kelas yang berbeda hanya dengan argumen umum seperti:

RelayCommand     

dan

RelayCommand<T>

Sungguh, ini bermuara pada preferensi pribadi. Semua orang akan mengatakan "satu kelas per file", tetapi kita semua memiliki alasan untuk menghindari itu dalam keadaan tertentu. Saya dulu punya proyek besar yang memiliki sekitar 300 enum yang berbeda. Tidak mungkin saya akan memiliki 300 file terpisah, satu untuk setiap kelas, ketika beberapa enum hanya tri-state.

Juga untuk orang-orang yang tidak dapat menemukan kelas-kelas tertentu jika mereka tidak semua dalam file dinamai seperti apa mereka, apakah ada alasan Anda tidak menggunakan Cari mencari di seluruh solusi? Menggunakan Find menghemat waktu saya yang berharga untuk menelusuri Solution Explorer.

Tidak peduli seberapa ringan kontennya, saya pikir satu kelas / antarmuka / dll. Per file sangat penting.

Jika saya sedang mengerjakan solusi besar dalam Visual Studio, saya ingin dapat melihat file dan tidak harus menggali ke dalam untuk melihat. Bahkan dengan alat navigasi seperti ReSharper, saya ingin pemetaan 1: 1.

Jika Anda menemukan banyak file sumber dengan sedikit atau tanpa konten (mungkin memperluas kelas tetapi tidak menambahkan apa-apa), maka mungkin Anda harus memikirkan kembali desain Anda.

Saya menemukan bahwa pengelompokan kelas dengan kelas pabrik standar dalam file yang sama sangat berguna.

Saya biasanya memiliki satu kelas per file tetapi Anda biasanya harus menggunakan kebijaksanaan Anda untuk melihat apakah file tersebut dapat berisi kelas terkait misalnya mengelompokkan pengecualian Anda yang dapat digunakan kembali oleh Anda dan pengembang lain. Dalam hal ini, pengguna hanya perlu satu file untuk dimasukkan daripada beberapa file.

Jadi intinya adalah: kebijaksanaan harus digunakan !!!

Dalam solusi yang lebih besar, saya pikir sangat berharga untuk memiliki satu kelas per file dan file tersebut dinamai sama dengan kelas. Itu membuatnya lebih mudah untuk menemukan kode yang Anda butuhkan untuk bekerja.

Alat StyleCop untuk C # memiliki aturan standar yang tidak memerlukan lebih dari satu kelas tingkat atas dalam satu namespace (ditambah sejumlah antarmuka, delegasi dan enum di namespace itu).

Dalam kasus dua atau lebih kelas di mana kelas kedua dan berikutnya hanya pernah digunakan oleh yang pertama, mereka bisa dan harus kelas batin, hanya terlihat oleh kelas konsumen.

Kadang satu kelas per file, tetapi ...

Ketika beberapa kelas sangat terkait, lebih dari satu kelas dalam file sumber yang sama adalah, IMHO, LEBIH BAIK daripada mendedikasikan file sumber pendek untuk setiap kelas. Sumber lebih mudah dibaca dan ringkas (dan menggunakan #region, sumber yang sama dapat lebih terstruktur dari sebelumnya).

Pertimbangkan juga bahwa kadang-kadang PERLU untuk menyebarkan kelas yang sama di file yang berbeda (menggunakan parsial ), karena memiliki file sumber 20000+ garis tidak berguna bahkan dengan RAM saya telah tersedia (tapi ini adalah pertanyaan lain).

Kadang-kadang saya akan meninggalkan kelas kecil dengan kelas yang lebih besar tetapi hanya jika mereka sangat terkait erat seperti objek dan itu adalah kelas koleksi atau pabrik.

Ada satu masalah dengan ini. Akhirnya kelas kecil tumbuh ke titik di mana seharusnya itu ada di file sendiri, jika Anda memindahkannya ke file baru Anda kehilangan akses mudah ke riwayat revisi Anda.

yaitu.

• pada hari Senin saya membuat perubahan ke kelas saya x dan y di file y.css
• pada hari selasa saya memisahkan kelas x ke file x.css sendiri karena telah tumbuh menjadi besar
• pada hari rabu bos saya ingin melihat apa yang saya ubah di kelas x pada hari Senin jadi dia melihat sejarah untuk x.css, hanya x.css tidak menunjukkan sejarah sebelum perubahan hari Selasa.

Apakah itu benar-benar masalah? :)
Kelas yang sangat kecil, seperti enum, dapat disatukan dengan yang lain. Ada satu aturan yang harus diikuti: kumpulkan hanya kelas-kelas yang memiliki kesamaan.

Sebagai penyimpangan - dalam salah satu proyek saya, saya memiliki file yang memiliki 150 kelas di dalamnya. File ini memiliki 10.000 baris kode. Tapi ini dihasilkan secara otomatis sehingga sepenuhnya dapat diterima :)

Salah satu alasan untuk menempatkan beberapa kelas terkait dalam satu file adalah agar bajingan miskin yang menggunakan API Anda tidak perlu menghabiskan setengah hari mengetik boilerplate deklarasi impor dan bajingan miskin yang harus mempertahankan kode tidak harus menghabiskan setengah sehari bergulir melalui boilerplate deklarasi impor. Aturan praktis saya adalah bahwa beberapa kelas termasuk dalam file yang sama jika Anda hampir selalu menggunakan subset besar dari mereka pada saat yang sama, bukan hanya satu per satu.

Saya melakukan ini, tetapi hanya ketika kelas terkait dalam mode anak-orang tua dan kelas anak HANYA digunakan oleh orang tua.

Saya biasanya tetap dengan satu kelas per file. Tapi saya akan membuat pengecualian untuk kelompok konstruksi serupa yang digunakan di seluruh proyek. Sebagai contoh:

• EventArgs.cs yang berisi EventArgssubclass apa pun , karena mereka biasanya hanya 5-10 baris kode, tetapi mereka biasanya digunakan oleh beberapa kelas yang berbeda. Atau, saya mungkin meletakkan EventArgskelas - kelas di file yang sama dengan kelas yang menyatakan peristiwa.
• Delegates.cs yang berisi Delegasi yang digunakan di seluruh proyek, karena mereka biasanya masing-masing hanya 1 baris. Sekali lagi, alternatifnya adalah meletakkannya di file yang sama dengan kelas yang mengekspos / mengkonsumsinya.
• Enums.cs yang berisi enums digunakan di seluruh proyek. (Jika ada enumyang hanya digunakan oleh satu kelas, saya biasanya akan sampai privateke kelas itu.)

Pilihan lain untuk satu kelas per file dengan file yang dinamai sama dengan kelas. Bagi saya, ini membantu dengan perawatan jangka panjang. Saya dapat dengan mudah melihat melalui repositori dan melihat kelas apa yang merupakan bagian dari solusi tanpa harus membuka proyek atau file apa pun.

Saya mengikutinya 99% dari waktu. Baik untuk mengikuti standar, tetapi saya juga percaya fleksibilitas ada di tempatnya. Kadang-kadang sepertinya hanya buang-buang waktu saja untuk memecah-belah. Pada saat itu, saya melupakan diri saya sendiri dan hanya menulis kode saya.

Respons sejauh ini tampaknya berkisar pada pengecualian orang terhadap aturan, jadi inilah milik saya: Saya menjaga kelas dan kelas 'teman' metadata mereka bersama ketika menggunakan paket DataAnnotations di .NET3.5 SP1. Kalau tidak, mereka selalu dalam file terpisah. Anda tahu, sebagian besar waktu. Kecuali kalau tidak.

Saya jarang melakukan ini. Misalnya jika ada enumerasi atau struct yang terkait erat dengan kelas namun terlalu sepele untuk dipisahkan sendiri.

Atau kelas terpisah berisi beberapa metode ekstensi untuk kelas utama itu.

One case could be:ketika kelas Anda bersama-sama membentuk a module / unityang melayani beberapa kelas utama seperti helper classes, tidak bijaksana lain .

lihat kode sumber proyek ASP.NET MVC 2.0 . Secara ketat mengikuti aturan ini

Saya suka ide membuat kelas yang lebih kecil dan memastikan bahwa kelas hanya melakukan apa yang seharusnya dilakukan. Jika Anda memiliki beberapa kelas yang berkontribusi untuk memecahkan satu masalah, maka tidak ada salahnya menyatukannya dalam file yang sama.

Saya tidak akan mengikuti praktik MS karena mereka bukan PRAKTEK TERBAIK!

Poin lain yang saya belum melihat orang lain menyebutkan adalah bahwa ketika Anda mengembangkan menggunakan aturan satu kelas per file Anda dapat dengan mudah melihat apa yang menggunakan kelas tertentu.

Sebagai contoh: Anda mungkin memiliki dua kelas di mana satu kelas menggunakan Linq dan yang lainnya tidak.

Jika kelas-kelas ini berada di file yang sama Anda tidak akan dapat memberi tahu tanpa melihat kode yang menggunakan kelas apa. Ketika satu kelas per file yang harus Anda lakukan adalah melihat bagian atas file untuk melihat apa yang sedang digunakan di kelas itu. Membantu jika Anda pernah bermigrasi ke lib baru dll.

Alasan lain untuk satu-kelas-per-file yang belum disebutkan dalam jawaban yang diposting sejauh ini adalah bahwa satu-kelas-per-file membuatnya lebih mudah untuk memahami dampak PR selama tinjauan kode. Ini juga mengurangi konflik gabungan.

Ketika seseorang memposting PR untuk mendapatkan umpan balik, saya dapat melihat daftar file yang diubah dan segera melihat tumpang tindih dengan apa yang mungkin saya kerjakan. Bergantung pada tumpang tindih saya mungkin ingin melihat kode mereka lebih dalam atau memberikannya OK karena saya cukup yakin itu tidak akan mempengaruhi perubahan saya sendiri.

Ketika dua orang bekerja dalam file multi-kelas dan keduanya menambahkan ketergantungan ada kemungkinan Anda akan mendapatkan konflik gabungan di usingblok di atas. Memisahkan kelas menjadi file memisahkan dependensi sehingga Anda dapat melihat apa yang digunakan setiap kelas dan Anda tidak mendapatkan konflik seperti ini.

Ada pengecualian untuk aturan ini (antarmuka + implementasi, enum, ...) tetapi ini adalah tempat awal yang lebih baik daripada sebaliknya yang biasanya memungkinkan pengembang junior menggabungkan semua jenis kelas yang tidak terkait ke dalam file yang sama.

Satu-kelas-per-file adalah aturan yang jelas tidak ambigu yang tunduk pada interpretasi.

Kelas-terkait-dalam-file terkait dengan preferensi dan interpretasi pribadi (seperti yang dapat Anda lihat dari semua jawaban lain di sini mengenai kapan boleh digunakan) dan karenanya merupakan aturan yang buruk.

Bolak-balik sangat menarik, dan tampaknya tidak meyakinkan, meskipun kesan umum saya adalah bahwa pemetaan 1-1 antara kelas dan file adalah pendapat mayoritas, meskipun dengan beberapa pengecualian orang per orang.

Saya ingin tahu apakah ada jawaban yang bervariasi tergantung pada apakah Anda: (1) mengembangkan aplikasi Windows Forms, aplikasi Web, Perpustakaan, atau apa pun; atau (2) menggunakan Visual Studio atau tidak. Dalam menggunakan VS, akan tampak bahwa aturan satu kelas per file juga akan menyiratkan satu kelas per proyek VS karena konsensus dalam utas lain tampaknya bahwa solusi / proyek VS harus dicerminkan dalam direktori / penamaan file dan struktur. Memang, kesan saya adalah bahwa konsensus adalah memiliki nama proyek = nama majelis = (bersarang) nama namespace, yang semuanya kemudian akan dicerminkan dalam direktori / penamaan file dan struktur. Jika itu adalah pedoman (atau aturan) yang tepat, maka semua mekanisme pengorganisasian yang tampaknya ortogonal ini akan tetap disinkronkan.

Ya demi keterbacaan, kita harus memiliki satu file per kelas !. Baru saja melompat ke proyek. Saya melihat banyak kelas dalam satu file. itu hanya membuat sangat sulit bagi pria baru untuk memahaminya. bukankah seharusnya kita memikirkan rawatan? kapan kita mengembangkan perangkat lunak? berkali-kali pengembangan akan dilanjutkan oleh pengembang lain. Kami memiliki ruang nama untuk mengatur barang-barang kami, kami tidak perlu file untuk melakukan itu !.

Satu item kode per file, ya.

Yang lainnya adalah malpraktek - dan, sejujurnya, tanda korban RAD.

Segera setelah seseorang memulai pengembangan perangkat lunak yang tepat (IoC, pola desain, DDD, TDD, dll ...) dan meninggalkan "omg mari kita selesaikan ini, saya tidak tahu caranya, tapi saya dibayar" bermain, orang akan melihat bahwa Aturan ini benar-benar penting.