.NET'te dosya kuralı başına bir sınıf? [kapalı]

Bu kurala uyuyorum ama bazı meslektaşlarım buna katılmıyor ve bir sınıf daha küçükse diğer sınıf (lar) ile aynı dosyada bırakılabileceğini savunuyorlar.

Her zaman duyduğum bir başka argüman da "Microsoft bile bunu yapmıyor, neden yapmalıyız?"

Bununla ilgili genel fikir birliği nedir? Bundan kaçınılması gereken durumlar var mı?

Dosya başına bir sınıf ayrıca, dosyanın farklarına bakmadan her check inin ne değiştiğiyle ilgili daha iyi bir fikir verir.

İnsanlar mutlak olarak düşündüklerinde ve bunu asla ya da böyle sübjektif ve nit seçici bir şeyle yapmamanız gerektiğini söylemekten nefret ediyorum, sanki hepimizin aptal doğru ve yanlış fikrine uymamız gerekiyormuş gibi. Alt satır: dosya başına birden fazla sınıfa sahip olmak mantıklıysa tamamen iyidir. Mantıklı olarak şunu demek istiyorum:

1. Kodun sindirilmesini ve bakımını kolaylaştırır
2. Çözümü daha az can sıkıcı (sayısız gereksiz dosyada kaydırma) ve daha az yavaş hale getirir
3. Geliştirici ekibi yerel bir kodlama uygulaması olarak sorun değil

Dosya başına neden birden fazla sınıf isteyebileceğime gerçekten iyi bir örnek:

Birkaç düzine özel istisna sınıfım var, her biri 4 astarlı, her biri için ayrı bir dosyaya sahip olabilirim veya istisnaları gruplayabilir ve grup başına bir dosya alabilirim. Bana göre en rasyonel / pragmatik yaklaşım onları gruplandırmak ve sadece birkaç dosyaya sahip olmaktır, çünkü daha verimli zaman / kodlama akıllıca (sağ tıklamak zorunda değilim -> Sınıf Ekle, yeniden adlandır, 50 kez) , çözümü daha az karmaşık ve daha iyi performans gösterir.

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

Bazen bir dosya içinde birden fazla sınıfı sıkıca bağlanmışsa ve en az biri çok küçükse gruplayabilirim.

Genel 'en iyi uygulama' sınıf başına bir dosyaya sahip olmaktır.

Varsayımsal argümanların ötesinde, Visual Studio IDE ve büyüyen yazılım projeleri ile Windows .NET'e odaklanmak, bu bağlamda her dosya için bir sınıfa sahip olmak mantıklıdır.

Genel olarak, görsel referans için hiçbir şey dosya başına bir sınıf alamaz. Gerçekten mi.

Microsoft'un aynı şeyi yapıp yapmadığını bilmiyorum, ancak bir sınıfı birden çok dosyaya bölmek için partialanahtar kelime oluşturdular (bu daha da şiddetli). Genellikle otomatik olarak oluşturulan tasarımcı kodunu aynı sınıftaki özel kodunuzdan ayırmak için kullanılır (ancak bazen farklı geliştiricilerin sınıfta aynı anda farklı dosyalar üzerinden çalışmasına izin vermek için kullanılır). Böylece Microsoft birden çok dosyanın faydalarını görür ve herkesin .NET ile kesin olarak düşünen birden çok dosya organizasyonu düşüncesi vardır.

Yuvalanmış sınıflar için, tek bir dosya veya sınıfların ilk bölümlerini kullanmaktan başka seçeneğiniz yoktur. Bu durumda bir dosya gerekli ve iyi:

class BicycleWheel {
    class WheelSpoke {
    }
}

Aksi halde neden tek bir dosyada birden fazla sınıf saklasınız ki? "Çünkü onlar küçük" veya birbirleriyle ilişkili argümanı fazla su tutmaz çünkü sonunda sınıflarınız diğer sınıflarla ilişkilendirilir. Sonuçta, özellikle yazılım büyümeye devam ettikçe , nesnelerin kullanımlarına göre dosya içi organizasyonunu kolayca çıkaramazsınız .

Ayrıca , ad alanları için klasörler kullanırsanız hiçbir zaman sınıf dosya adı çakışması olmaz. Visual Studio gibi bir geliştirme ortamında değilken (örneğin , bir sınıfı Not Defteri veya hızlı / hafif bir şeyle hızlı bir şekilde düzenlemek istiyorsanız) dosya sisteminde dosya adına göre bir sınıf bulmak da uygundur .

Pek çok iyi neden var ...

Vakaların büyük çoğunluğunda, her dosya kuralı için bir sınıfı izlerim. Düzenli olarak yaptığım tek istisna, belirli bir sınıfa sıkıca bağlı olan bir enum tanımıdır. Bu durumda, enum tanımını sık sık bu sınıfın dosyasına ekleyeceğim.

Ben de tek bir dosyada bir tür olması gerektiğine inanıyorum.

Bu kuralda belirtilmesi gereken bir istisna vardır: Yalnızca aşağıdaki gibi genel bir argümanla farklılık gösteren iki sınıfa sahip olmak:

RelayCommand     

ve

RelayCommand<T>

Gerçekten, bu kişisel tercihe bağlı. Herkes "dosya başına bir sınıf" diyecek, ama hepimizin bazı durumlarda bundan kaçınma nedenlerimiz var. Yaklaşık 300 farklı numaraya sahip büyük bir projem vardı. Hiçbir şekilde sadece bazı numaralandırmalar üç durumluyken, her sınıf için bir tane olmak üzere 300 ayrı dosyam olmayacak.

Ayrıca, belirli sınıfları, olduklarından sonra adlandırılan dosyalarda yoksa, bulamayan kişiler için, Bul'u tüm çözümde aramayı kullanmamanın bir nedeni var mı? Bul'u kullanmak Çözüm Gezgini'nde gezinmem için değerli zaman kazandırıyor.

İçerik ne kadar hafif olursa olsun, dosya başına bir sınıf / arayüz / vb.

Visual Studio'da büyük bir çözüm üzerinde çalışıyorsam dosyaları görebilmek istiyorum ve görmek için içine delve gerek yok. ReSharper gibi navigasyon araçlarıyla bile, 1: 1 eşleme istiyorum.

İçeriği çok az olan veya hiç olmayan çok fazla kaynak dosya bulursanız (belki bir sınıfı genişletir, ancak hiçbir şey eklemezseniz) belki de tasarımınızı yeniden düşünmelisiniz.

Bir sınıfı standart fabrika sınıfı ile aynı dosyada gruplamanın çok yararlı olduğunu düşünüyorum.

Normalde her dosya için bir sınıfa sahip olurdum, ancak normalde dosyanın ilgili sınıfları içerip içermediğini görmek için kendi kendinize ve diğer geliştiriciler tarafından yeniden kullanılabilen istisnalarınızı gruplandırabileceğinizi görmek zorundasınız. Bu durumda, kullanıcının birden fazla dosya yerine yalnızca bir dosyaya dahil edilmesi gerekir.

Mesele şu ki: takdir yetkisi kullanılmalıdır !!!

Daha büyük çözümlerde, dosya başına bir sınıfa sahip olmanın çok değerli olduğunu ve dosyanın sınıfla aynı şekilde adlandırıldığını düşünüyorum. Çalışmanız gereken kodu bulmanızı kolaylaştırır.

C # için StyleCop aracı, bir ad alanında birden fazla üst düzey sınıf gerektirmeyen standart kurallara sahiptir (ayrıca bu ad alanındaki herhangi bir sayıda arabirim, delege ve numaralandırma).

İkinci ve sonraki sınıfların yalnızca birincisi tarafından kullanıldığı iki veya daha fazla sınıf durumunda, bunlar yalnızca tüketen sınıf tarafından görülebilen iç sınıflar olabilir ve olmalıdır.

Bazen dosya başına bir sınıf, ama ...

Birden çok sınıf sıkı bir şekilde ilişkili olduğunda, aynı kaynak dosyadaki birden fazla sınıf, her sınıfa kısa bir kaynak dosyası ayırmak yerine IMHO, BETTER olur. Kaynak daha okunabilir ve kompakttır (ve #region kullanılarak aynı kaynak öncekinden daha yapılandırılabilir).

Ayrıca, 20000+ satır kaynak dosyasına sahip olduğum RAM ile bile kullanışlı olmadığından , bazen aynı sınıfı farklı dosyalara ( kısmi kullanarak ) yaymanın GEREKLİ olduğunu düşünün (ama bu başka bir soru).

Bazen daha büyük bir sınıfla küçük bir sınıf bırakacağım, ancak sadece bir nesne ve koleksiyon sınıfı veya fabrika gibi çok sıkı bir şekilde ilişkili oldukları takdirde.

Bununla ilgili bir sorun var. Sonunda küçük sınıf, kendi dosyasında olması gereken noktaya kadar büyür, eğer yeni dosyaya taşırsanız, düzeltme geçmişinize kolay erişiminizi kaybedersiniz.

yani.

• pazartesi y.css dosyasındaki x ve y sınıflarımı değiştiriyorum
• Salı günü x sınıfını kendi dosyasına x.css olarak ayırıyorum çünkü çok büyümüş
• çarşamba günü patronum Pazartesi günü x sınıfında neyi değiştirdiğimi görmek istiyor, bu yüzden x.css geçmişine bakar, sadece x.css salı günleri değişmeden önce geçmişi göstermez.

Bu gerçekten bir sorun mu? :)
Gerçekten küçük sınıflar, tıpkı enums gibi, başkaları ile bir araya getirilebilir. İzlenmesi gereken bir kural var: sadece ortak bir şeyleri olan sınıfları bir araya getirin.

Bir araştırma olarak - projelerimden birinde içinde 150 sınıf bulunan bir dosyam var. Dosya 10000 satır kod içeriyor. Ama otomatik olarak üretildiğinden tamamen kabul edilebilir :)

Bir dosyaya birden fazla ilişkili sınıf koymanın bir nedeni, API'nizi kullanan fakir piçin ithalat beyannamesi yazısını yazmak için yarım gün harcamak zorunda kalmaması ve kodu korumak zorunda olan fakir piçin yarım harcamak zorunda olmamasıdır. bir gün ithalat beyanı kaynatma plakası kaydırma. Genel kuralım, her seferinde yalnızca bir tane yerine aynı anda büyük bir alt kümesini kullanırsanız, birden fazla sınıfın aynı dosyaya ait olmasıdır.

Bunu yapıyorum, ancak sadece sınıflar bir çocuk-ebeveyn tarzındaysa ve çocuk sınıfları SADECE ebeveyn tarafından kullanılıyorsa.

Genellikle her dosya için bir sınıfa sadık kalırım. Ancak, proje genelinde kullanılan benzer yapı gruplarına istisnalar sunacağım. Örneğin:

• EventArgsGenellikle her biri sadece 5-10 kod satırı olduğu için alt sınıfları içeren bir EventArgs.cs , ancak bunlar genellikle birkaç farklı sınıf tarafından kullanılır. Alternatif olarak, EventArgssınıfları olayları bildiren sınıfla aynı dosyaya koyabilirim .
• Genellikle her biri yalnızca 1 satır olduğundan, proje boyunca kullanılan Temsilciler içeren bir Delegates.cs. Yine, alternatif onları açığa çıkaran / tüketen sınıfla aynı dosyaya koymaktır.
• enumProje boyunca kullanılanlar içeren bir Enums.cs . ( enumYalnızca bir sınıf tarafından kullanılan bir varsa , genellikle privatebu sınıfa yaparım .)

Dosya sınıfla aynı şekilde adlandırıldığında, dosya başına bir sınıf için başka bir oy. Benim için uzun süreli bakımda yardımcı oluyor. Depoyu kolayca inceleyebilir ve projeyi veya dosyaları açmak zorunda kalmadan hangi sınıfların bir çözümün parçası olduğunu görebilirim.

Bunu% 99 oranında takip ediyorum. Standartlara uymak güzel, ama aynı zamanda esnekliğin de yeri olduğuna inanıyorum. Bazen işleri parçalamak için saçma bir zaman kaybı gibi görünüyor. O zamanlarda kendimi aşar ve sadece kodumu yazarım.

Şimdiye kadar verilen yanıtlar, insanların kuraldaki istisnaları etrafında dönüyor gibi görünüyor, bu yüzden işte benim: .NET3.5 SP1'deki DataAnnotations paketini kullanırken sınıfları ve metadata 'arkadaş' sınıflarını bir arada tutuyorum. Aksi takdirde, her zaman ayrı dosyalarda bulunurlar. Bilirsiniz, çoğu zaman. Olmadığı zamanlar hariç.

Bunu nadiren yapıyorum. Örneğin, sınıfla yakından ilişkili ancak kendi başına ayrılmak için çok önemsiz olan bir numaralandırma veya yapı varsa.

Veya ana sınıf için bazı uzantı yöntemleri içerecek ayrı bir sınıf.

One case could be:sınıflarınız ortaklaşa module / unitbazı ana sınıflara hizmet eden bir tane oluşturduğunda helper classes, diğer bilge hayır .

ASP.NET MVC 2.0 proje kaynak koduna bir göz atın . Bu kurala kesinlikle uyuyor

Daha küçük sınıflar oluşturma ve sınıfın sadece yapması gerekeni yaptığından emin olma fikrini seviyorum. Tek bir sorunun çözülmesine katkıda bulunan birden fazla sınıfınız varsa, bunları aynı dosyada bir araya getirmenin bir zararı yoktur.

EN İYİ UYGULAMALAR olmadığı için MS uygulamalarını takip etmem!

Başka kimsenin bahsetmediğini gördüğüm başka bir nokta, dosya kuralı başına bir sınıfı kullanarak geliştirdiğinizde, o sınıfın ne kullandığını kolayca görebilmenizdir.

Örneğin: bir sınıfın Linq kullandığı, diğerinin kullanmadığı iki sınıfınız olabilir.

Bu sınıflar aynı dosyadaysa, hangi sınıfın ne kullandığını koduna bakmadan söyleyemezdiniz. Dosya başına bir sınıf olduğunda, tek yapmanız gereken o sınıfta tam olarak ne kullanıldığını görmek için dosyanın üst kısmına bakmaktır. Hiç yeni bir lib'e geçiyorsanız yardımcı olur.

Şimdiye kadar gönderilen yanıtlarda belirtilmeyen dosya başına bir sınıfın başka bir nedeni, dosya başına bir sınıfın bir kod incelemesi sırasında bir PR'nin etkisini anlamayı kolaylaştırmasıdır. Ayrıca birleştirme çatışmalarını da azaltır.

Birisi geri bildirim için bir PR gönderdiğinde, değiştirilen dosyaların listesine bakabilir ve hemen üzerinde çalıştığım şeylerle çakışabilir. Çakışmaya bağlı olarak, kodlarına daha derinlemesine bakmak veya bir Tamam vermek isteyebilirsiniz, çünkü kendi değişikliklerimi etkilemeyeceğinden oldukça eminim.

İki kişi çok sınıflı bir dosyada çalışırken ve her ikisi de bağımlılık eklediğinde using, üstteki blokta birleştirme çakışması elde etme şansınız yüksektir . Sınıfları dosyalara ayırmak, her sınıfın ne kullandığını görebilmeniz için bağımlılıkları ayırır ve bunun gibi çakışmalar alamazsınız.

Bu kuralın istisnaları vardır (arayüz + uygulama, numaralandırmalar, ...), ancak genellikle genç geliştiricilerin ilgisiz sınıfların her türünü aynı dosyaya paketlemesine izin veren tam tersi olandan daha iyi bir başlangıç ​​noktasıdır.

Dosya başına bir sınıf, yoruma tabi olmayan açık ve net bir kuraldır.

İlgili dosyadaki sınıflar kişisel tercihlere ve yoruma tabidir (burada tüm diğer cevaplardan görebileceğiniz gibi, ne zaman kullanmanın uygun olduğu) ve bu nedenle kötü bir kuraldır.

Geri ve ileri çok ilginç ve görünüşte sonuçsuz olsa da, genel izlenimim, sınıflar ve dosyalar arasında 1-1 bir eşlemenin, bazı kişiler tarafından istisnalar olsa da, çoğunluk düşüncesi olduğudur.

Yanıtlarınızın herhangi birinin sizin yaptığınıza bağlı olarak değişip değişmediğini merak ediyorum: (1) bir Windows Forms uygulaması, bir Web uygulaması, bir Kütüphane veya başka bir şey geliştirme; veya (2) Visual Studio kullanıyor veya kullanmıyor. VS kullanılırken, diğer iş parçacıklarındaki fikir birliği VS çözümlerinin / projelerinin dizin / dosya adlandırma ve yapısında yansıtılması gerektiği için dosya kuralı başına bir sınıfın VS projesi başına bir sınıf anlamına geldiği anlaşılmaktadır. Aslında benim izlenimim, fikir birliğinin proje adı = derleme adı = (iç içe) ad alanı adına sahip olması, hepsi dizin / dosya adlandırma ve yapısında yansıtılacak olmasıdır. Bunlar doğru yönergeler (veya kurallar) ise, tüm bu görünüşte dikey olan düzenleme mekanizmaları yine de senkronize kalır.

Evet, okunabilirlik adına her sınıfta bir dosya olmalı !. Sadece bir projeye atladým. Bir dosyada birçok sınıf görüyorum. yeni bir adamın bunu anlamasını zorlaştırıyor. sürdürülebilirliği düşünmemeli miyiz? ne zaman bir yazılım geliştiriyoruz? geliştirme diğer geliştiriciler tarafından birçok kez devam edecektir. Eşyalarımızı düzenlemek için ad alanlarımız var, bunu yapmak için dosyalara ihtiyacımız yok !.

Dosya başına bir kod öğesi, evet.

Diğer her şey bir yanlış uygulama ve açıkçası RAD mağduriyetinin bir işaretidir.

Biri uygun yazılım geliştirmeye başlar başlamaz (IoC, tasarım desenleri, DDD, TDD vb.) bu kural gerçekten, gerçekten önemlidir.