Sınıfları adlandırmak için en iyi yaklaşım nedir?

Sınıflar için iyi ve kesin isimler bulmak herkesin bildiği gibi zordur. Doğru yapıldığında, kodu daha fazla kendi kendini belgelendirir ve daha yüksek bir soyutlama düzeyinde kod hakkında akıl yürütmek için bir kelime hazinesi sağlar.

Belirli bir tasarım modelini uygulayan sınıflara, iyi bilinen model adına (örn. FooFactory, FooFacade) dayalı bir ad verilebilir ve alan kavramlarını doğrudan modelleyen sınıflar, adlarını problem alanından alabilir, peki ya diğer sınıflar? İlham alamadığımda ve genel sınıf adlarını kullanmaktan kaçınmak istediğimde başvurabileceğim bir programcının eş anlamlılar sözlüğü gibi bir şey var mı (FooHandler, FooProcessor, FooUtils ve FooManager gibi)?

Kent Beck'in Uygulama Modellerinden bazı pasajlardan alıntı yapacağım :

Basit Süper Sınıf Adı

"[...] İsimler kısa ve etkili olmalıdır. Bununla birlikte, isimleri kesinleştirmek için bazen birkaç kelime gerekir. Bu ikilemden çıkmanın bir yolu, hesaplama için güçlü bir metafor seçmektir. Akılda bir metaforla, hatta tek kelimeler onlarla birlikte zengin bir çağrışımlar, bağlantılar ve çıkarımlar ağı getirir.Örneğin, HotDraw çizim çerçevesinde, bir çizimdeki bir nesne için ilk adım DrawingObject idi . Ward Cunningham, tipografi metaforuyla birlikte geldi: bir çizim basılı, düzenlenmiş bir sayfa. Bir sayfadaki grafik öğeler şekillerdir, bu nedenle sınıf Şekil olur . Metafor bağlamında, Figure , DrawingObject'ten aynı anda daha kısa, daha zengin ve daha kesindir . "

Nitelikli Alt Sınıf Adı

"Alt sınıfların adlarının iki görevi vardır. Hangi sınıfa benzediklerini ve nasıl farklı olduklarını iletmeleri gerekir. [...] Hiyerarşilerin köklerindeki adların aksine, alt sınıf adları neredeyse sohbetlerde kullanılmaz, böylece kısa ve öz olma pahasına anlamlı olabilirler. [...]

Hiyerarşilerin kökleri olarak hizmet eden alt sınıflara kendi basit adlarını verin. Örneğin, HotDraw , bir şekil seçildiğinde şekil düzenleme işlemlerini sunan bir sınıf Tutamacına sahiptir. Şekil genişlemesine rağmen basitçe Sap olarak adlandırılır . Tam bir tutamaç ailesi vardır ve en uygun şekilde StretchyHandle ve TransparencyHandle gibi adlara sahiptirler . Çünkü Sap kendi sıralamasının temelidir, nitelikli bir alt sınıf adıyla daha basit üst sınıf adını hak ediyor.

Alt sınıf isimlendirmedeki diğer bir kırışıklık, çok seviyeli hiyerarşilerdir. [...] Değiştiricileri körü körüne üst sınıfa eklemek yerine, adı okuyucunun bakış açısından düşünün. Bu sınıfın hangi sınıf olduğunu bilmesi gerekiyor? Bu üst sınıfı, alt sınıf adının temeli olarak kullanın. "

Arayüz

Arayüz isimlendirmesinin iki stili, arayüzleri nasıl düşündüğünüze bağlıdır. Uygulama içermeyen sınıflar olarak arayüzler, sınıflarmış gibi adlandırılmalıdır ( Basit Üst Sınıf Adı , Nitelikli Alt Sınıf Adı ). Bu adlandırma stiliyle ilgili bir sorun, sınıfları adlandırmaya başlamadan önce iyi adların kullanılmış olmasıdır. File adlı bir arabirim , ActualFile , ConcreteFile veya (yuck!) FileImpl gibi bir uygulama sınıfına ihtiyaç duyar.(hem bir son ek hem de bir kısaltma). Genel olarak, soyut nesnenin bir arayüz veya bir üst sınıf olarak uygulanıp uygulanmadığına bakılmaksızın, birinin somut veya soyut bir nesneyle ilgilenip ilgilenmediğini iletmek önemlidir. Arayüzler ve üst sınıflar arasındaki ayrımın ertelenmesi, bu adlandırma stiliyle iyi bir şekilde desteklenir ve sizi daha sonra gerekli olursa fikrinizi değiştirmekte özgür bırakır.

Bazen, somut sınıfları adlandırmak, iletişim için arayüzlerin kullanımını gizlemekten daha önemlidir. Bu durumda, "I" ile önek arabirim adları. Arayüzün adı IFile ise, sınıf basitçe Dosya olarak adlandırılabilir .

Daha ayrıntılı tartışma için kitabı satın alın! Buna değer! :)

Her zaman MyClassA, MyClassB'yi tercih edin - Güzel bir alfa sıralaması sağlar ..

Şaka yapıyorum!

Bu iyi bir soru ve çok uzun zaman önce deneyimlemediğim bir şey. Kod tabanımı işyerinde yeniden düzenliyordum ve neyi nereye koyacağım ve ona ne ad vereceğim konusunda sorunlar yaşıyordum ..

Gerçek sorun?

Çok şey yapan derslerim vardı. Tek sorumluluk ilkesine bağlı kalmaya çalışırsanız, her şeyin daha güzel bir şekilde bir araya gelmesini sağlar. Tek bir yekpare PrintHandler sınıfı yerine , onu PageHandler , PageFormatter (vb.) Olarak bölebilir ve ardından bir master Printer sınıfına sahip olabilirsiniz. hepsini bir araya getiriyor.

Yeniden düzenlemem zaman aldı, ancak çok sayıda yinelenen kodu bir araya getirdim, kod tabanımı çok daha mantıklı hale getirdim ve bir sınıfa fazladan bir yöntem atmadan önce düşünme konusunda çok şey öğrendim: D

Ben ediyorum değil ancak sınıf adı içine model isimleri gibi şeyler koyarak önerilir. Sınıflar arayüzü bunu açık hale getirmelidir (bir tekil için yapıcıyı gizlemek gibi). Sınıf genel bir amaca hizmet ediyorsa, genel isimde yanlış bir şey yoktur.

İyi şanslar!

Josh Bloch'un iyi API tasarımı hakkındaki mükemmel konuşmasında birkaç iyi tavsiye var:

• Sınıflar bir şeyi yapmalı ve iyi yapmalıdır.
• Bir sınıfı adlandırmak veya açıklamak zorsa, muhtemelen bir önceki madde işaretindeki tavsiyelere uymuyordur.
• Bir sınıf adı, sınıfın ne olduğunu anında iletmelidir.
• İyi isimler iyi tasarımları yönlendirir.

Sorununuz, maruz kalan dahili sınıfları ne adlandıracağınızsa, belki onları daha büyük bir sınıfta birleştirmelisiniz.

Eğer probleminiz birçok farklı şey yapan bir sınıfı adlandırmaksa, onu birden çok sınıfa ayırmayı düşünmelisiniz.

Herkese açık bir API için iyi bir tavsiye buysa, başka hiçbir sınıf için zarar veremez.

Eğer bir adla Takılırsanız bazen sadece o veriyor herhangi daha sonra revize etmek amacında olan yarı mantıklı isim iyi bir stratejidir.

Felç olarak isimlendirmeyin. Evet, isimler çok önemli ama çok fazla zaman harcayacak kadar önemli değiller. 10 dakika içinde aklınıza iyi bir isim çıkaramazsanız, devam edin.

Aklıma iyi bir isim gelmezse, muhtemelen daha derin bir problem olup olmadığını sorardım - sınıf iyi bir amaca hizmet ediyor mu? Eğer öyleyse, isimlendirmek oldukça basit olmalıdır.

Eğer "FooProcessor" gerçekten foo'ları işliyorsa, o zaman zaten bir BarProcessor, BazProcessor vb. Var diye ona bu ismi vermeye isteksiz olmayın. Şüpheye düştüğünüzde en iyisi barizdir. Kodunuzu okumak zorunda kalan diğer geliştiriciler, sizinle aynı eşanlamlılar sözlüğünü kullanmıyor olabilir.

Bununla birlikte, bu özel örnek için daha fazla özgüllük zarar vermez. "Süreç" oldukça geniş bir kelimedir. Örneğin, gerçekten bir "FooUpdateProcessor" ("FooUpdater" haline gelebilir) mi? Adlandırma konusunda çok "yaratıcı" olmanıza gerek yok, ancak kodu yazdıysanız, muhtemelen ne işe yarayıp yaramadığı konusunda oldukça iyi bir fikriniz vardır.

Son olarak, çıplak sınıf adının sizin ve kodunuzun okuyucularının devam etmesi gereken tek şey olmadığını unutmayın - oyunda genellikle ad alanları da vardır. Bunlar genellikle okuyuculara, sınıfınızın çıplak adı oldukça genel olsa bile, gerçekten ne için olduğunu açıkça görmeleri için yeterli bağlam sağlayabilir.