Paket isimleri tekil mi yoksa çoğul mu olmalı?


227

Genellikle, kütüphanelerde özellikle paketler, tek bir kavram etrafında düzenlenen sınıfları içerir. Örnekler: xml, sql, user, config, db . Bence hepimiz doğal olarak bu paketlerin tekil olarak doğru olduğunu düşünüyoruz .

com.myproject. xml .Element
com.myproject. sql .Connection
com.myproject. kullanıcı .User
com.myproject. kullanıcı. Kullanıcı Fabrika

Ancak, gerçekte tek bir tür uygulama koleksiyonu içeren bir paketim varsa - örneğin görevler, kurallar, işleyiciler, modeller vb. Tercih edilebilir mi?

com.myproject. görevler .TakeOutGarbageTask
com.myproject. görevler .DoTheDishesTask
com.myproject. görevler .PaintTheHouseTask

veya

com.myproject. görev .TakeOutGarbageTask
com.myproject. görev .DoTheDishesTask
com.myproject. görev .BaskıTheHouseTask


5
tekil tıpkı veri tabanı tablosu isimleri gibi her zaman tekil olmalı, fakat farklı sebeplerle. Örneğin, Java veya Python gibi herhangi bir popüler standart kütüphaneye bakın.

@ Robrod Roberson: Lütfen cevabınızı bir cevap olarak gönderin, böylece doğru şekilde oylayabiliriz.
S.Lott

@ Jarrod bazı örneklere ihtiyaç duyacaktır, çünkü standart kütüphanelerde çoğu sınıf listelediğim ilk kategoriye girer .
Nicole

@Renesis Güncelleştirilmiş cevabımı bir göz atın.
Matthew Rodatus

@Matthew - Beğendim. Şüphelendiğimi ifade ettin ama nasıl kodlanacağından emin değildin.
Nicole

Yanıtlar:


293

Çoğul homojen içerikli paketler için ve tekil heterojen içerikli paketler için kullanın.

Bir sınıf, veritabanı ilişkisine benzer. Veri tabanı ilişkisi tekil olarak adlandırılmalıdır, çünkü kayıtları ilişkinin örnekleri olarak kabul edilir. Bir ilişkinin işlevi, basit verilerden karmaşık bir kayıt oluşturmaktır.

Öte yandan, bir paket veri soyutlama değildir. Kodun düzenlenmesine ve adlandırma çatışmalarının çözümüne yardımcı olur. Bir paket tekil olarak adlandırılmışsa, paketin her bir üyesinin paketin bir örneği olduğu anlamına gelmez; ilişkili ancak heterojen kavramlar içermektedir. Çoğul olarak adlandırılmışsa ( çoğu zaman olduğu gibi ), paketin homojen kavramlar içermesini beklerdim.

Örneğin, a'nın örneklerini içeren bir koleksiyon olduğundan, TaskCollectionbunun yerine bir türün adlandırılması gerekir . Adı verilen paket , içerilen her sınıfın bir görevin örneği olduğu anlamına gelmez. Bir da olabilir bir, vb isimli bir pakette : Ancak bütün görevler farklı tipte içerecektir , vbTasksCollectionTaskcom.myproject.taskTaskHandlerTaskFactorycom.myproject.tasksTakeOutGarbageTaskDoTheDishesTask


13
Benzer bir soru için, english.stackexchange.com/q/25713 adresini ziyaret edin . Bir kategori tekil ile aynıdır ve bir tür çoğul ile aynıdır.
Matthew Rodatus

4
Sağladığınız bağlantı , bu kuralın istisnasını gösterir. beansçoğul, ancak java.beansJavaBeans ile ilgili her türlü sınıfı içerir.
SkyDan

İyi cevap, ancak veritabanı ilişkisi mantığına katılmıyorum. ERD'deki ilişkiler tekildir, çünkü varlıklar arasındaki ilişkileri gösterirler. Tablolar, ilişkilerin fiziksel bir uygulamasıdır ve birden fazla satır tutarlar ve bu nedenle çoğul IMO olmalıdır. "Bu tabloda ne var?" "kullanıcılar" "kullanıcı" değil. Verilen, tekil adlandırma işlem dünyasında (C #, Java) Ruby, Python, Javascript ve PHP gibi topluluklarda olduğundan daha yaygın gibi görünüyor.
ryeguy

4
@ SkyDan'ın yorumu, burada tamamen göz ardı edilen çok önemli bir şeye işaret ediyor. Bana göre çoğul "java.beans" isminin aslında bir hata olduğu ve bunun yerine "java.bean" olarak adlandırılmış olması gerektiği, tekil olarak.
Vicky Chijwani

6
@VickyChijwani @SkyDan, JavaBeans ™ bir ticari marka olduğundan, muhtemelen teknolojinin kendisine atıfta bulunmak için ismini tutmak istedi ve bu nedenle kullandılar java.beans.
Hejazi

1

Bu muhtemelen belirli bir dile bağlı. .NET'te (C #), eğer bir ad alanı tipi ad çarpışması muhtemelse ( type name expected but namespace foundhata) kesinlikle çoğul olmalıdır . Bununla başa çıktım, bu hiç hoş değil ve kodun her yerinde fazla nitelikli tür adlarıyla sonuçlanıyor. Örnek .

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.