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

185

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?

c# .net

— Joan Venge
sumber

1

mungkin duplikat kelas C # dalam file terpisah?

Lihat juga: programmers.stackexchange.com/questions/121365/…

— George Mamaladze

176

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

— Menandai
sumber

4

Lebih banyak kelas dalam file yang sama meningkatkan perbedaan antara kelas terkait hanya dalam satu operasi.

— Luca

3

Penampil beda yang tepat memungkinkan Anda melihat semua perbedaan satu komit.

— Dykam

44

Saya tidak sepenuhnya yakin bagaimana jawaban khusus ini adalah jawaban untuk pertanyaan (s) dari posting asli. Tentu itu memberikan alasan untuk menjaga 1 kelas ke file (meskipun Luca dan Dykam membuat poin bagus), tetapi itu tidak mencerminkan konsensus umum atau memberikan kasus ketika itu harus dihindari.

— Robert Davis

4

Praktik terbaik tidak ada, jika Anda yakin praktik terbaik memahami, itu hanya berlaku untuk konteks tertentu. Sebagai tanggapan lain menunjukkan ada saat-saat ketika aturan ini benar-benar akan membuat kode kurang terpelihara. Ketika alat menjadi lebih baik, aturan ini menjadi kurang relevan karena jauh lebih mudah untuk menemukan kelas dan tipe dalam suatu proyek.

— abombss

263

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:

Membuat kode lebih mudah dicerna dan dipelihara
Menjadikan solusi kurang mengganggu (menggulir file yang tidak perlu yang tak terhitung jumlahnya) dan kurang lambat
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.

— James
sumber

92

+1,000. Memahami alasan untuk praktik terbaik dan berpikir dua kali sebelum melanggarnya sangat bagus. Ketaatan budak itu jahat.

— dsimcha

19

Beberapa lusin kelas pengecualian khusus ? Bukankah itu sumber masalah sebenarnya? Saya tidak hanya bermaksud menjadi pemilih di sini: Saya pikir sebagian besar waktu orang ingin menggabungkan kelas menjadi satu file, itu karena mereka tidak perlu membuat terlalu banyak jenis. (Karena itu, mungkin ada kasus aktual di mana beberapa lusin kelas pengecualian kustom masuk akal). Banyak kelas kecil, tanpa op biasanya tanda dari masalah yang lebih besar.

— Jeff Sternal

16

Saya setuju dengan Anda untuk sebagian besar. Tetapi pengecualian adalah kasus khusus. Karena sistem yang dirancang dengan baik perlu memiliki penanganan pengecualian yang tepat untuk menangani semua kasus yang menghasilkan kesalahan yang sah, sebagian besar artikel praktik terbaik yang saya baca menekankan perlunya membuat pengecualian khusus (dan beberapa kali Anda membutuhkan banyak dari mereka untuk tutupi semua aturan bisnis pada proyek besar) sehingga Anda tidak berakhir dengan menangkap system.eception yang bukan penanganan yang tepat sama sekali.

— James

6

Saya setuju bahwa Anda tidak boleh mengikuti beberapa pedoman tanpa alasan yang jelas, namun saya tidak setuju dengan fakta bahwa Anda harus memiliki lebih dari satu kelas dalam sebuah file. Bagi saya file tersebut harus dinamai setelah kelas dan tidak mengandung lebih dari satu. Beberapa bahasa (java menjadi satu) membuat catatan untuk benar-benar menegakkan bahwa kelas ada dalam file dengan nama file yang cocok dengan nama kelas. Bagi saya itu membuat lebih mudah bagi pendatang baru untuk bernavigasi jadi untuk alasan itu saya percaya bahwa satu kelas per file adalah hal yang benar untuk dilakukan

— krystan honor

3

Menyimpan satu kelas per file dan menjaga nama file serta nama kelas dalam sinkronisasi adalah kebiasaan, seperti halnya variabel penamaan. Visual Studio sangat cocok untuk pendekatan ini. Lebih mudah untuk sistem kontrol sumber, dan pengembang yang ditambahkan di tengah proyek. Mereka secara intuitif akan mencari nama file yang cocok dengan nama kelas.

— Oybek

75

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

— Jeremy Bell
sumber

4

Apakah ada aturan seperti itu di .NET? Saya juga saya baru saja mengembalikan hasil pernyataan. : O

— Joan Venge

50

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.

— rev, Phil Rykoff
sumber

7

Jika Anda mengetahui bahwa keduanya digabungkan, mengapa Anda tidak memisahkannya?

— The Matt

39

@ Matt: Ini disebut menghindari rekayasa berlebihan. Jika Anda memiliki beberapa kelas yang sangat erat dan memisahkannya akan menambah banyak kompleksitas dibandingkan dengan jumlah fleksibilitas praktis yang diberikannya, lalu apa gunanya?

— dsimcha

9

Kadang-kadang saya memiliki dasarnya seperti "data" kelas yang hanya digunakan oleh kelas yang satu ini, jadi saya biasanya menempatkan data-kelas dalam file yang sama dengan pengguna karena datac-lass biasanya memiliki sedikit atau tidak ada logika itu sendiri dan sepertinya buang untuk membuat file baru untuk itu.

— Earlz

3

@The Matt: Kadang-kadang ada kelas pembantu yang saya anggap cocok untuk diterima. Mereka mengurangi kompleksitas untuk bagian dari kelas lain tetapi masih memfasilitasi tujuan yang sangat spesifik untuk kelas itu.

— Jordan Parmer

6

@TheMatt: Pisahkan ini: msdn.microsoft.com/en-us/library/... Kopling antar modul buruk, tetapi kolaborasi antar kelas dalam fitur logis tidak dapat dihindari.

— Ben Voigt

25

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 ...

— John K.
sumber

Terima kasih, apa yang Anda maksud dengan "setidaknya bagian pertama dari mereka"? Maksud Anda, Anda juga dapat memisahkan kelas bersarang?

— Joan Venge

1

Itu referensi tidak langsung ke partialkata kunci yang saya sebutkan.

— John K

1

Sebagai catatan, kelas yang bersarang dapat berupa partial msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx Saya melihat ini karena penasaran.

— John K

Ini hanya menunjukkan bahwa tampilan default harus logis (namespace / kelas) dan bukan fisik (file).

— David Schmitt

@ DavidSchmitt untuk itulah Class View digunakan dalam Visual Studio.

— Zack

14

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.

— Greg D
sumber

12

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>

— Andrei Rinea
sumber

Apakah Anda tahu solusinya untuk membuat StyleCop bahagia dalam kasus ini?

— George Polevoy

Tidak setuju, ada konvensi lain untuk kelas generik, Foo 1.cs for Foo <T> `dan Foo 2.cs for Foo <T, T1>`.

— Oybek

@ Oybek: Bagaimana jika saya memiliki Foo <T>, Foo <U> dan Foo <U, T>? Sekarang apa?

— Andrei Rînea

@AndreiRinea Tidak mungkin memiliki Foo<T>dan Foo<U>dalam namespace yang sama. Tetapi jika ruang nama berbeda, mereka biasanya di folder yang berbeda. Jadi untuk Foo<T>dan Foo<U>itu harus Foo 1.cs and for Foo <U, T> `Foo`2.cs. Tapi masih satu kelas per file.

— Oybek

Terima kasih atas informasinya! :)

— Andrei Rînea

8

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.

— Jason M
sumber

Re: find - ketika saya sedang mencari definisi jenis, saya tidak ingin melihat di mana itu digunakan. Selain itu, pencarian memakan waktu lebih lama daripada menggulir daftar file yang diurutkan berdasarkan abjad yang mungkin telah saya bagi (berdasarkan namespace).

— Jeff Sternal

1

Saya perhatikan Anda telah mengindikasikan Anda sedang mengerjakan sesuatu yang Anda bagi dengan namespace. Sayangnya, kita semua tidak cukup beruntung untuk selalu bekerja dengan proyek yang dapat kita kelola.

— Jason M

6

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.

— Michael
sumber

5

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

— Robert Davis
sumber

5

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 !!!

— Akapetronics
sumber

1

Kebijaksanaan sejati, tidak ada aturan dalam pemrograman yang sulit dan cepat.

— ChaosPandion

4

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.

— Chris Clark
sumber

Saya menemukan argumen ini kurang berharga dengan alat-alat seperti ReSharper. Saya Lakukan CTRL + T dan mulai mengetik nama jenis yang saya cari.

— Mark

3

Ya, tetapi apakah Anda ingin struktur aplikasi Anda bergantung pada alat pihak ketiga?

— Magnus

1

@ Magnus Saya tidak mengatakan ini bukan alasan untuk tidak melakukannya, tetapi argumen yang kurang menarik bagi seseorang untuk melakukannya.

— Markus

4

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.

— Steve Gilham
sumber

3

Ketika Anda mengatakan "tidak lebih dari satu kelas tingkat atas dalam satu ruang nama", maksud Anda dalam satu namespaceblok, bukan?

— Daniel Pryden

1

Aturan yang disinggung adalah SA1403: dokumen AC # hanya boleh berisi ruang nama tunggal. SA1402: dokumen AC # hanya boleh berisi satu kelas di tingkat root kecuali semua kelas parsial dan dari jenis yang sama.

— Steve Gilham

4

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).

— Luca
sumber

Tentu saja, Anda harus menghindari kelas dengan begitu banyak baris kode. Saya akan mengatakan bahkan 1000+ menjadi terlalu besar. Saya juga menyadari ini tidak selalu mungkin dalam kode warisan.

— Peter

Jika Anda mencoba menghasilkan kode sumber (kasus saya adalah generasi pengikatan C # untuk OpenGL dari spesifikasinya, memiliki ribuan titik masuk) sulit untuk memikirkan kelas kecil untuk banyak data ...

— Luca

3

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.

— roti jahe
sumber

1

Bagaimana jika "kelas kecil" adalah sesuatu seperti turunan dari EventArgs, yang dimaksudkan untuk meneruskan informasi kepada penerima acara kelas Anda? Akankah kode dibuat lebih bersih atau lebih mudah dipelihara dengan memindahkan hal seperti itu ke file lain? Boleh dibilang, hal seperti itu seharusnya menjadi kelas publik yang bersarang, tetapi yang tampaknya disukai juga. Adapun sejarah revisi, bukankah kelas muncul entah dari mana di changelog, dan tidakkah seharusnya ada komentar dalam catatan kode dari mana asalnya?

— supercat

Saya akan kelas itu sebagai very tightly relatedkelas dan meninggalkannya asalkan hanya memakan sedikit ruang layar dan tidak digunakan untuk tujuan yang sama oleh kelas lain.

— gingerbreadboy

3

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 :)

— IamDeveloper
sumber

1

Saya memiliki file yang sama dengan 120 kelas dan 750 subclass dengan setengah juta baris, juga autogenerated.the masalahnya adalah: jika saya klik di atasnya, saya harus reboot karena semuanya berhenti.

— Behrooz

3

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.

— dsimcha
sumber

1

Apa yang Anda maksud dengan "impor deklarasi boilerplate"? "Menggunakan pernyataan"? Tapi bukankah kelasnya akan berada di namespace yang sama?

— Joan Venge

3

@ Joan: Maksud saya harus mengimpor 15 modul yang berbeda tetapi terkait untuk mencapai sesuatu yang sangat sederhana. Mungkin itu tidak berlaku khusus untuk C #. Saya tidak benar-benar tahu C #, tetapi dalam bahasa lain itu adalah masalah yang cukup menjengkelkan.

— dsimcha

Terima kasih ya itu sebabnya saya bingung.

— Joan Venge

2

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

— Hasil
sumber

Terima kasih, tetapi mengapa Anda tidak memisahkannya ke file lain? Hanya penasaran.

— Joan Venge

@henchman telah mengatakannya dengan jauh lebih fasih daripada yang saya miliki, terutama ketika objek anak sangat kecil. Biasanya, kelas anak adalah properti hanya dengan logika yang mungkin sedikit

— CResults

2

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.)

— Daniel Pryden
sumber

2

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.

— Tim Scarborough
sumber

2

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.

— Mike Pateras
sumber

2

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.

— Brant Bobby
sumber

2

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.

— puffpio
sumber

1

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

— Asad
sumber

1

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!

— azamsharp
sumber

1

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.

— Kieran Oldham
sumber

0

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.

— Ian Mercer
sumber

-1

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.

— Steve Rehling
sumber

-1

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 !.

— Ceti
sumber

-5

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.

— Turing Lengkap
sumber