Soyut derslerime bir "Özet" öneki eklemeli miyim? [kapalı]


20

Diyelim ki soyut bir sınıfım var Task.

Bunun AbstractTaskyerine isimlendirmemi önerecek bir standart ya da sözleşme var mı?


Burada listelenen adlandırma kuralları: oracle.com/technetwork/java/codeconventions-135099.html hayır, ancak bu bağlantıyı öneriyor: stackoverflow.com/questions/1006332/… yapabileceğinizi söylüyor ve eğer yaparsanız korkunç bir şey olmaz.
SinirliWithFormsDesigner

C # 'da standart kural' * Base 'ile Sonek'tir.
Den

Yanıtlar:


26

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.


15

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).


13

Hayır. Intellisense bana soyut olup olmadığını önemsiz bir şekilde söyleyecektir, bu yüzden burada sadece KURU ihlal ediyorsunuz.


21
-1 abstractBir 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?
Bryan Oakley

10
@Bryan: Elbette DRY'yi ihlal ediyor. 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.
DeadMG

13
"Everbody"? Tanıdığım çoğu insan emacs ve vi kullanıyor, birkaç tanesi tutulma kullanıyor. Bir şeyin "sizin probleminiz" olduğunu söylemek tam olarak ekip çalışmasının tanımı değildir. Benim dert ettiğim nokta, sadece bir battaniye kuralı belirleyemezsiniz ve bunun böyle yapıldığını söyleyemezsiniz. Farklı ekiplerin farklı gereksinimleri vardır ve herkesin akıllıca yardıma ihtiyacı yoktur. Ayrıca, dediğim gibi, birincil düzenleyiciniz veya IDE'niz dışındaki bazı araçlarda koda bakarken birçok kez var.
Bryan Oakley

1
+1 kesinlikle KURU ihlal eder. Intellisense'e güvenmek biraz güçlü, ancak temel sınıfı kullanan herkes en azından SOLID'in bir parçası olarak neyi genişlettiğini görmelidir.
Gary Rowe

8
@BryanOakley neden halka açık ve finalde de bulunmuyorsunuz? Bir sınıf adı daha sonra PublicAbstractPersonThatImplementsInterfaceHuman gibi görünecektir. Hmm, bunun iyi olduğundan emin değilim. Ancak katılıyorum, evrensel bir toplantı gibi bir şey yok - ekibin kolektif verimliliğini artıran her şeyi kullanın.
Apoorv Khurasia

9

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.


9

.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.


1
"Base" ve "Impl" sonekleri için +1. Yapısal bir noktaya işaret ediyorlar (soyut bir sınıf bir şeyin temeli olacak).
vski

7
@vski: hayır, kesinlikle katılmıyorum: popoda işe yaramaz bir acı. Arayüzünüzü veya temel sınıfınızı jenerik bir adla adlandırmak genellikle arayüzü açıklar ve somut uygulamanızı daha fazla isim ile adlandırır.
haylem

3
Kullanmaya meyilliyim ... Bir arabirimin arkasındaki temel sınıf için temel. İyi ad zaten arabirim tarafından alınır ve temel sınıf yine de istemci kodu tarafından kullanılmaz.
starblue

1
@Haylem birçok java tasarım deseni, beklenen tek bir uygulama ile arayüzler kullanır. Impl bu durumlarda çok yararlı bir sonektir.
funkybro

Impl kullanımı ile ilgili olarak bkz. Varsayılan vs Impl - Impl'den uzak durun! Base'i sonek olarak kullanmak (örneğin, TaskBase), bir temel sınıfın bir dil yapısı yerine bir örüntü olduğunu gösterir.
Gary Rowe

8

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ı.


3

Ö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ış abstractanahtar 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.


... ya da böyle bir arayüz Listve AbstractListsınıf (ki uygular olarak).

3
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, Abstractsı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.


0

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 Listadı 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.

-1

Eğer bir takımda çalışıyorsanız, o zaman tüm takım soyut sınıflara "Soyut" önekinin eklenip eklenmeyeceğine karar vermelidir.

Kendi başınıza çalışıyorsanız, tamamen size kalmış, bu sitedeki ben veya başka hiç kimse size bağlı değil.



-2

Soyut bir AbstractSyntaxTreesınıf yazmak isterseniz ne olur ? Ya da sadece bir özet SyntaxTree?

Geleneksel değildir ve insanları kolayca karıştırabilir.


-2

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.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.