Soyut sınıflar için adlandırma kuralları

Bir keresinde Microsoft tarafından öne sürülen kılavuzun, soyut olduğu gerçeğini ortadan kaldırmak için soyut bir sınıfa "Temel" sonekini eklemek olduğunu çok iyi hatırlıyorum. Dolayısıyla, böyle sınıfları System.Web.Hosting.VirtualFileBase, System.Configuration.ConfigurationValidatorBase, System.Windows.Forms.ButtonBase, ve, tabii ki, System.Collections.CollectionBase.

Ama fark ettim ki, son zamanlarda Çerçeve'deki pek çok soyut sınıf bu kuralı takip ediyor gibi görünmüyor. Örneğin, aşağıdaki sınıfların tümü soyuttur ancak bu kurala uymayın:

• System.DirectoryServices.ActiveDirectory.DirectoryServer

• System.Configuration.ConfigurationElement

• System.Drawing.Brush

• System.Windows.Forms.CommonDialog

Ve birkaç saniye içinde çalabildiğim şey bu. Bu yüzden deli olmadığımdan emin olmak için resmi belgelerin söylemesi gerekenlere bakmaya gittim. Sınıf Kitaplıkları Geliştirmeye Yönelik Tasarım Yönergelerinde MSDN'de Sınıfların, Yapıların ve Arayüzlerin Adlarını buldum . İşin garibi, soyut bir sınıfın adının sonuna "Base" eklemek için kılavuzdan hiç bahsedemiyorum. Ve yönergeler artık Çerçeve'nin 1.1 sürümü için mevcut değildir.

Yani, kaybediyor muyum? Bu kılavuz hiç var mıydı? Tek kelime etmeden terk mi edildi? Son iki yıldır boşu boşuna uzun sınıf isimleri mi yaratıyorum?

Biri bana bir kemik atsın buraya.

Güncelleme ben deli değilim. Kılavuz vardı. Krzysztof Cwalina 2005'te bundan şikayet ediyor.

In Çerçeve Tasarım Kuralları p 174 devletler:

Sınıf genel API'larda kullanılmak üzere tasarlanmışsa, temel sınıfları "Temel" sonekiyle adlandırmaktan kaçının .

Ayrıca: http://blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx

Ayrıca, soyut sınıfın kullanılacak birkaç statik üyesi varsa, 'Temel' çirkinleşebilir.

Böyle bir kılavuzu hatırlamıyorum. Mantıklı bir adlandırma kullanmanız gerektiğine inanıyorum. Bazen soyut sınıf, son eke sahip olması gerektiğini düşündüğüm bazı sınıflara (bir araç olarak) ortak işlevsellik sağlamak için tasarlanmıştır. Bununla birlikte, bazı durumlarda, kendisini tamamlamayan bir polimorfizm hiyerarşisinin temeli olarak kullanmak istersiniz. Bu durumlarda normal bir sınıf gibi adlandırmayı öneririm.

Gördüğünüz gibi, bir ButtonBase'i parametre olarak kabul eden bir yöntemi muhtemelen bildirmeyeceksiniz. Alt sınıflar için minimum işlevsellik sağlamak üzere tasarlanmıştır. Bununla birlikte, ConfigurationElementbir kişiyi farklı formlara sahip ancak kendi başına tam olmayan bir varlık olarak ele alabilirsiniz (ve dolayısıyla soyuttur)

Bazen, özellikle birisinin somut bir uygulama oluşturmak için genişletmesi için hem somut bir sınıf hem de soyut bir sınıf sağladığınızda Base hala gereklidir.
örneğin Controller ve ControllerBase (aslında Controller da soyuttur, ancak ControllerBase'den önemli ölçüde daha fazla işlevsellik sağlar)

Temel sonek, bir arabirime karşı programlama yaparken çirkin, bu yüzden Microsoft yönergesinin, soyut sınıfın ağırlıklı olarak bir arabirim gibi kullanıldığı durumlarda geçerli olduğunu düşünüyorum. Muhtemelen Genel API ile kastettikleri şey.

Mesele şu ki, Base sonekini kullanmaktan daha iyi bir alternatifin olmadığı durumlar var.

Bir Temel Sonekten kaçınma eğilimini anlıyorum, ancak aynı zamanda bazı Soneklere olan ihtiyacı da anlıyorum . Şimdi, bu makalenin bir Yorumu , hiçbirini kullanmamak için ikinci seçenek olarak "Tür" ü Sonek olarak kullanmayı öneriyor. Bunun kafa karıştırıcı olduğuna inanıyorum, ancak "böylesine bağlayıcı olmayan bir kelimenin, bunun taahhüt edilmemiş bir sınıf olduğunu gösterme eğiliminde olacağı" fikri bana takıldı.

Bir Alternatif Olarak: Nesneyi "belirli bir ırk veya aileye ait veya ona ait" olarak belirtmek için "Tür" ü sonek olarak kullanmayı tercih ederim ( Vikisözlük: -kind ).

Örnek: DataProviderve ReflectiveDataProviderikisi deDataProviderKind

Örneğin, "canis lupus" un, kabaca "köpeğe benzeyen" anlamına gelen "Canoidea" ailesine ait olduğu Biyoloji'den esinlenilmiştir.

Microsoft şu adreste belirtiyor:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-classes-structs-and-interfaces

"✓ CONSIDER türetilmiş sınıfların adını temel sınıfın adıyla sonlandırır. Bu çok okunabilir ve ilişkiyi net bir şekilde açıklar. Bunun kodda bazı örnekleri şunlardır: Bir tür Exception olan ArgumentOutOfRangeException ve bir tür Exception olan SerializableAttribute Öznitelik türü. Bununla birlikte, bu yönergeyi uygularken makul bir muhakeme kullanmak önemlidir; örneğin, Button sınıfı, Control adında görünmese de, bir tür Control olayıdır. "

Genel olarak konuşursak, bu, adda "Base" kullanımını örtük olarak dışlar.