Diyelim ki soyut bir sınıfım var Task
.
Bunun AbstractTask
yerine isimlendirmemi önerecek bir standart ya da sözleşme var mı?
Diyelim ki soyut bir sınıfım var Task
.
Bunun AbstractTask
yerine isimlendirmemi önerecek bir standart ya da sözleşme var mı?
Yanıtlar:
Bloch'un Etkili Java'sına (Madde 18) göre, Özet öneki özel bir durumda kullanılan bir sözleşmedir.
Dışa aktardığınız her önemsiz arabirime gitmek için soyut bir iskelet uygulama sınıfı sağlayarak arabirimlerin ve soyut sınıfların erdemlerini birleştirebilirsiniz. ... Kural olarak, iskelet uygulamaları AbstractInterface olarak adlandırılır ve burada Arabirim uyguladıkları arabirimin adıdır.
Ancak Bloch ayrıca SkeletalInterface adının mantıklı olacağına dikkat çekiyor, ancak
Özet sözleşmesi şimdi sağlam bir şekilde kurulmuştur.
Diğer cevapların belirttiği gibi, genel olarak bu adlandırma kuralını tüm soyut sınıflara uygulamak için bir neden yoktur.
Kongre yok. Her şey, geliştirici olarak size daha fazla ve daha iyi kod yazmanıza ve başkalarının kodunuzu anlamasına yardımcı olacak şeylerle ilgilidir.
Kodu görecek ve koruyacak insanlara sorun. Ne görmeyi tercih ederlerdi? Onları kolaylaştıran nedir? Sonra ne istediklerine göre adlandırın.
Başka bir notta, Java Programlama Dili için Kod Kuralları: 9. Kuralların İsimlendirilmesi hiçbir gereklilik önermez :
Sınıf isimleri, her bir iç kelimenin ilk harfinin büyük harflerle yazılmasıyla isimler olmalıdır. Sınıf adlarınızı basit ve açıklayıcı tutmaya çalışın. Tam kelimeler kullanın-kısaltmalardan ve kısaltmalardan kaçının (kısaltma, URL veya HTML gibi uzun formdan çok daha yaygın olarak kullanılmadıkça).
Hayır. Intellisense bana soyut olup olmadığını önemsiz bir şekilde söyleyecektir, bu yüzden burada sadece KURU ihlal ediyorsunuz.
abstract
Bir sınıf adına eklemek DRY'yi ihlal etmez ve herkes zekayı kullanmaz. Örneğin, bir web sayfasındaki kodu okuyorsanız veya düz bir metin düzenleyicide veya harici bir fark aracında baktığınız bir yamanın parçasıysa ne yaparsınız?
abstract class AbstractName
? Açıkça iki kez "soyut" vardır. Ve Intellisense kullanmıyorsanız, o zaman bu sizin probleminizdir, herkes kodu görüntülemek için aklı başında araçlar kullanır.
Bu bir tercih meselesidir (ancak sınırda kötü uygulama), ancak çoğu insan niteleyicilerin bir kısmını sınıf adına görmekten hoşlanmaz.
Çoğu IDE, bu bilgileri sizin için kolayca erişilebilir hale getirecektir, bu yüzden isme koymak gerekli değildir ve sadece atlamak daha temiz olacaktır. Değişken adlandırma için Macarca gösterimi anımsatıyor ve günümüzde kesinlikle kötü bir form olarak kabul ediliyor. Sadece aramanızı öneririm Task
.
.NET'te, soyut bir temel sınıfı belirtmek için sonek olarak "Base" kullanımı sıklıkla görülür. Bunun Java'da yaygın bir uygulama olup olmadığı konusundaki diğer cevapları ertelerdim.
Benim düşünceme göre, bir işletmenin adı tip yapısı hakkında değil semantiği hakkında bilgi aktarmalıdır. Bu nedenle, soyutlama çalışma zamanı hedefinin bir parçası değilse, sınıfınızı "AbstractSomething" olarak tanımlamak mantıklı değildir. Bunun temel bir soyut sınıf olması programcı tarafından görülebilir ve isme yansıtılmasına gerek yoktur.
Ancak, soyut bir fabrikanın bir uygulamasını bir AbstractFactory olarak adlandırmayı mükemmel hale getirirse, bu sınıfın amacı ile ilgilidir.
Genel olarak, sınıfınızın hedefi hakkında en fazla bilgiyi aktarmaya yardımcı olan adlandırma kuralını destekleyin.
Benzer şekilde, uzak durun SomethingImpl
. Bunun bir temel sınıf değil, bir uygulama olması umrumda değil. Sınıf hiyerarşiniz miras için uygun şekilde tasarlanmışsa, birisi miras alabilir. Kuşkusuz, daha fazla "Impl" son eki veya diğer eserler ekleyerek bunların hiçbir değeri olmayacaktır. "Arayüz" soneki veya "I" öneki eklemenin de bir değeri yoktur.
Düşünmek:
IVehicle <-- IMotoredVehicle <-- AbstractCar <-- CarImpl
Aksine:
Vehicle <-- MotoredVehicle <-- Car <-- DefaultCar
<-- Ferrari
<-- Trabi
İkincisini çok tercih ederim.
Bu, bazı bakımdan, benzer bariz kötüye ait Macar Gösterimi ikincisi olduğunu onun kötü bir temsilcisi verdi insanlar yanlış değişkenin türü bir göstergesi olan değişkenler önüne geliştiricilerin gerektiren olarak yorumlamak başladı. Bu bazen kullanımlarına sahip olsa da (çoğunlukla türün tanımını aramak için tembelseniz), çoğunlukla işe yaramaz. Simonyi'nin Macar Gösterimi ile ilgili orijinal fikri, geliştiriciye türünün değil, işletmenin yeteneklerini hatırlatmak için bir anımsatıcı olarak kullanmaktı.
Önemli bir kural, sözdiziminden açıkça görülen bir isme özellikler eklememektir. Java'da, soyut bir sınıfı uygun şekilde adlandırılmış abstract
anahtar kelimeyle işaretlemeniz gerektiğinden , adı dahil etmem. Örneğin, C ++ 'da durum o kadar net değildir, ama en azından derleyici soyut bir sınıfı yanlış kullandığınızı söyleyecektir. Yine Python gibi bir şeyde, soyut bir sınıfı bu şekilde açıkça adlandırmak kötü bir fikir değildir.
Kuralın olağan istisnası, adın belirsiz olduğu zamandır. Herhangi bir nedenle, somut bir alt sınıf varsa Task
(diğer örneklerde, bu daha mantıklı olabilir, ancak her neyse), o zaman emin olun AbstractTask
.
protected abstract SomeClass { }
Bu bana bunun bir Abstract sınıfı olduğunu söylüyor. Bir önek eklemek bir totoloji ve anti-kalıptır ve çoğu durumda uygun değildir, package local
örneğin bir istisna olmaktan bahsettiği bağlantıya bakın .
Çoğu durumda, Abstract
sınıflar halka açık bir API'nin parçası olmamalıdır, eğer varsa gerçekten iyi bir sebep olmalı ve iyi bir sebep açıkça başka bir isim sağlamalıdır AbstractSomeClass
.
Çoğu durumda, daha açıklayıcı bir ad bulamazsanız, muhtemelen bazı yeniden tasarımlar yapmanız gerekir.
Beş sentim, muhtemelen bu soyut sınıfın uygulamalarına sahip olacaksınız ve bunlara 'SomeSpecificTask', 'TaskWithBubbles', 'StrangeTask' vb.
Ayrıca, 'özet' sözcüğü, iş etki alanı varlıklarıyla değil, dil sözdizimi ile ilgilidir, bu yüzden onu adın bir parçası olarak kullanmamayı tercih ederim.
Öte yandan, burada bir cevapta J.Bloch Etkili Java'dan bir ismin bir parçası olarak 'soyut' kullanmanın iyi kurulmuş bir uygulama olduğunu söyleyen bir alıntı gördüm. Öyle olabilir. Ama yine de resmi java kodu sözleşmelerinde bununla ilgili hiçbir şey yok.
public abstract class AbstractList<E> extends AbstractCollection<E> implements List<E>
- sınıfın List
adı olarak kullanılamaz AbstractList
çünkü arayüzün adı budur. İyi kurulmuş bir uygulama ve resmi Java kodunun, arabirimi uygulayan bir şeyin soyut bir sınıfı genişletebileceği veya genişletemeyeceği (ayrıca arabirimi de uygulayan) bir kısmı olan kullanımdaki resmi Java kodunun bir parçasıdır.
Ben bir Java geliştiricisi (INAJD?) Değilim ve bu tür şeyler için standart adlandırma bilmiyorum, ama sanırım Task
olduğu gibi tek başına durabilecek kadar soyut geliyor.
Bunu yaptım. AbstractOperation adlı soyut sınıfıma 'Abstract' öneki ekledim. Bunu yapmamın nedeni, Operasyon adlı soyut olmayan bir sınıfa sahip başka bir paket olmasıydı ve ekibime ve daha sonra ikisi arasında herhangi bir karışıklıktan kaçınan programcılara yardımcı oldu.