Soyut sınıflar için genel isimler nasıl önlenir?

10

Genel olarak (örn.) Dosya tanıtıcıları veya (örneğin) unix işlemleriyle uğraşmadıkça, rutin adların ve sınıf adlarının bir parçası olarak "tanıtıcı" veya "işlem" gibi sözcüklerden kaçınmak iyidir. Bununla birlikte, soyut sınıflar çoğu zaman, bir şeyle ne yapacaklarını gerçekten bilmezler. Şu anki durumumda bir kullanıcının gelen kutusuna giriş yapan ve ondan gelen mesajları işleyen bir "EmailProcessor" var. Aşağıdaki stil maddesinin ortaya çıktığını fark etsem de, bunun nasıl daha kesin bir isim vereceğimi gerçekten net değil:

türetilen sınıfları istemci olarak ele almak ve uyguladığı işlevsellik tarafından temel sınıfı adlandırmak daha iyi mi? Ona daha fazla anlam verir, ama ihlal eder. Örneğin, EmailAcquirer, türetilmiş sınıf için edinildiği için makul bir ad olurdu, ancak türetilmiş sınıf, herkes için edinmeyecektir.
Ya da türetilmiş sınıfların ne yapacağını kimin bildiğinden, sadece belirsiz bir isim. Ancak "İşlemci", IMAP oturum açma ve kullanma gibi birçok ilgili işlemi gerçekleştirdiği için hala çok geneldir.

Bu ikilemden kurtulmanın bir yolu var mı?

Sorun, "bu ne işe yarar?" Sorusuna gerçekten cevap veremediğiniz soyut yöntemler için daha belirgindir. çünkü cevap basitçe "müşteri ne isterse" dir.

object-oriented coding-style naming

— djechlin
kaynak

Bu "genel" iddia için bir kaynağınız (ve bir bağlamınız) var mı? Ayrıca, liste için ek bir adlandırma kuralı - muhtemelen var olmayan mükemmel bir ad aramak için zaman kaybetmeyin. Şüpheniz varsa, ona mümkün olan en iyi adı verin, gerekirse tanımlandığı gibi bir yorum olarak daha uzun bir açıklama ekleyin, ancak bir kişi seçiminizi beğenmezse veya mükemmel bir ad aniden size geldiğinde daha sonra her zaman yeniden düzenleyebilirsiniz. başka bir şey yapıyoruz.

— Steve314

3

@ Steve314 - evet, Steve McConnell, Code Complete, 1. baskı, rutinlerle ilgili Bölüm 4 veya 5. Bu bölümlerde isimlendirme hakkında kapsamlı bir tartışma, aslında iyi bir isminiz yoksa muhtemelen iyi bir işleve sahip olmadığınız sonucuna varır.

— djechlin

iyi bir ad bulamamak kötü bir işaret gibi görünebilir, ancak IMO, işlevin kendisine göre işlevin kötü olup olmadığını bilmelisiniz. İngilizcenin projeniz için özel olarak tasarlanmamış olması nedeniyle yeniden düzenleme biraz zor. Hayır, bu günlük bir sorun değil, ama zaten bir sorun yaşamaya karar verdin.

— Steve314

1

@ Steve314 Programlama tamamen karmaşıklığı yönetmekle ilgilidir ve eğer beyniniz bir şey için bir kelime bulamazsa, oldukça iyi bir şans var, kullanmak gibi şeyler yapmak zorunda kaldığında karmaşıklığını yönetemez. daha büyük cümleler veya daha büyük sistemlerin bir parçası olarak. Aslında, iyi bir isim bulamamanın endişe için duraklamanın büyük bir nedeni olduğunu söylemek cesur bir iddia değildir. Ancak bu McConnell'de yoğun bir şekilde tartışıldı, en azından tüm kitap kapaktan okunmaya değer olsa da, en azından bu iki bölümü okumanızı tavsiye ederim.

— djechlin

Code Complete'teki iddialara mutlaka güvenilmemelidir. Kitapların itibar farkındayım, ama ben de farkındayım bu . Ayrıca, karmaşıklığı çağlar boyunca mükemmel bir şekilde iyi idare ediyorum - hatalar, neden, ancak işler yanlış gittiğinde, bazen sorun o kadar basit bir işlevdir ki açıkçası yanlış olamaz, ama yine de .

— Steve314

10

Sorun isim değil, bir sınıfa çok fazla şey eklemeniz.

Örnek sınıfınızda, bazı parçalar çok somuttur (postaların nasıl elde edileceği). Diğer bölümler çok soyut (postalarla ne yapacaksınız).

Bunu kalıtımdan ziyade ayrı sınıflarla yapmak daha iyidir.

Öneririm:

POPMailBoxDownloader tarafından alt sınıflara ayrılmış soyut bir MessageIterator
bir POPMailBoxDownloader SAHİBİ ve mesajlarla bir şeyler yapan başka bir sınıf.

— Kris Van Bael
kaynak

Kulağa doğru geliyor. Kendinize bir şey "processEvent" veya "MessageProcessor" sınıfı adını verirseniz, türetme yerine kompozisyon üzerinde tasarlayabileceğiniz iyi bir şans var gibi görünüyor. Bu durumda, bir esneklik yararlı olabileceğinden, ancak bir istemci her işlevin tam olarak ne yaptığını merak ederek (bakımdan daha moreso) rahatsızlık yaratır.

— djechlin

6

Bir sınıf için iyi bir isim bulamazsam, sınıf için satır içi kod belgeleri yazarım. Sınıfın amacını tek bir kokuda tanımlar. Genellikle bu açıklamadan sınıf için iyi bir isim türetebilirim. Bu soyut sınıflar için de yararlıdır.

Sınıfın açıklaması "Kullanıcının gelen kutusuna giriş yapar ve ondan gelen mesajları işlerse", sınıf adı olarak "InboxProcessor" öneririm. Bir türev sınıfta "kullanıcının gelen kutusuna giriş yapar ve spam e-postasını bir spam klasörüne taşır" ifadesi varsa, ad olarak "InboxSpamMover" ı seçerdim.

Soyut bir sınıfın genel amacını yansıtıyorsa, "işlemci" gibi genel adları kullanırken bir sorun görmüyorum.

Bir sınıfın amacını bir veya iki kokuyla tanımlamakta sorun yaşıyorsanız, bir tasarım sorununuz olabilir. Belki de sınıf çok fazla şey yapıyor ve Tek Sorumluluk İlkesini ihlal ediyor . Bu soyut sınıflar için de geçerlidir.

— Theo Lenndorff
kaynak

2

Frank Zappa'yı yorumlamak için, budur ve bu şekilde adlandırılmalıdır. Örneğiniz, ne tür bir işlemenin devam ettiğini yeterince derinlemesine incelemiyor. Bir EmailToTroubleTicketProcessor, bir EmailGrammarCorrectorveya bir EmailSpamDetectormi?

Sorun, "bu ne işe yarar?" Sorusuna gerçekten cevap veremediğiniz soyut yöntemler için daha belirgindir. çünkü cevap basitçe "müşteri ne isterse" dir.

Bu tam olarak doğru değil; soyut bir şey için cevaplayamayacağınız soru " yaptığı şeyi nasıl yapıyor?" çünkü bu uygulamaya özgüdür. Bir EmailSendersınıfın bir DeliveryStatus deliver(Email e)yöntemi varsa, bir uygulamanın e-posta alacağı, onu teslim etmeye çalıştığı ve nasıl gittiğiyle ilgili bir durum döndüreceği zımni bir sözleşme vardır. SMTP sunucusuna bağlanıp bağlanmadığı ya da uygulama vaat edileni yaptığı sürece bir posta güvercine bağlanmak üzere yazdırılmasının umrunda değilsiniz. Bildiri özetleri sadece bir uygulamanın "evet, bunu yaparım" diyebilmesi için bu vaadi ölçüyor.

— Blrfl
kaynak

Son işlev bir anlamda uçbirim olduğunda, yani soyut sınıf "ve işte burada, onunla ne istersen yap?" örneğin, yöntemin duruma erişimi, geçersiz dönüş türü, atmasız.

— djechlin

Hala aynı şey. Metodunuz olsa bile void doWhatYouDoWith(Email e), yine de sınıfın EmailDisposerne yaptığını söyleyecek kadar spesifik, ancak uygulamanın nasıl yapılacağını genel olarak anlayabilirsiniz . @KrisVanBael'in çivilenmiş olmasına rağmen: belirsiz bir şeye başvurduysanız, bir çatı altında çok fazla olabilir.

— Blrfl

0

Bu tür kelimeleri kullanmanın neden kötü olduğunu düşünün . Açıklayıcı mı? Sınıfları tanımlamak için hangi kelimeler var ? EmailBaseClass? Bu, EmailManager veya benzeri bir şey söylemekten daha açıklayıcı olabilir mi? Anahtar, söz konusu sınıf hakkında bir fikir sahibi olmaktır , bu yüzden uygun fiilleri veya isimleri bulun. Kodunuza şiirmiş gibi davranın.

— zxcdw
kaynak

"EmailBaseClass", "ageInteger" adını vermek gibi olurdu int age, çünkü düz metin e-postaları, MIME e-postaları vb. Türetmeyi beklediğimden daha da kötüsü. abstractİlk olarak sözcükten önce gelenleri açıklamaya gerek yoktur (bu Java'dır). Bu sınıfın temel kısmı hakkında özel bir fikriniz var mı? Ve daha fazla kavrayış, bir ilişkiyi geçecek bir şeyi adlandırma sorununu hala çözmüyor, ya çok belirsiz ya da çok genel bir şeyim olabilir, daha fazla kavrayışa daha fazla kavrayış.

— djechlin

@djechlin - bunun ageIntegergibi bir şeyin gerçekten uygun olduğu nadir durumlar vardır . Macarca gösterim, çok fazla olduğu bir bağlamdan kısaltılmış bir versiyondur. Eğer çizgisinde bir şey gerekebilir zaman Kesinlikle zamanlar vardır ageNumericve ageStringbelirsizliği giderecek en kolay ve en net yol olarak isim türünde bir göstergesi olan, aynı kapsamda.

— Steve314

@djechlin Ben şahsen sadece bir anlayış kazanmak için göz atabilirsiniz kod ile çalışmak en kolay buluyorum . Yani isimler bana neyle çalıştığımı söylüyor. systemControllerSoyut bir temel sınıf mı yoksa büyük bir hiyerarşide bir yaprak mı olduğunu bilmenize gerek yok . Tabii ki bu IDE ile düzeltilebilir (sanırım çoğu Java gelişiminde olduğu gibi?) Derhal kullanıcıyı sınıfın içeriği ve yapısı hakkında bilgilendirebilir, böylece aslında anlayışlı isimler benzer bir şekilde haklı gösterilemez.

— zxcdw