Java'daki yardımcı sınıflar için adlandırma kuralı

115

Java'da yardımcı program sınıfları yazarken, izlenecek bazı iyi yönergeler nelerdir?

Paketler "yararlanılmalı" mı yoksa "araçlar" mı olmalıdır? ClassUtil mi yoksa ClassUtils mi? Bir sınıf ne zaman "Yardımcı" veya "Yardımcı" olur? Yardımcı Programlar mı, Yardımcı Programlar mı? Yoksa bunların bir karışımını mı kullanıyorsunuz?

Standart Java kitaplığı hem Yardımcı Programları hem de Yardımcı Programları kullanır:

javax.swing.Utilities
javax.print.attribute.AttributeSetUtilities
javax.swing.plaf.basic.BasicGraphicsUtils

Apache, çeşitli Util ve Utils kullanır, ancak çoğunlukla Utils:

org.apache.commons.modeler.util.DomUtil
org.apache.commons.modeler.util.IntrospectionUtils
org.apache.commons.io.FileSystemUtils
org.apache.lucene.wordnet.AnalyzerUtil
org.apache.lucene.util.ArrayUtil
org.apache.lucene.xmlparser.DOMUtils

Spring, birçok Helper ve Utils sınıfını kullanır:

org.springframework.web.util.UrlPathHelper
org.springframework.core.ReflectiveVisitorHelper
org.springframework.core.NestedExceptionUtils
org.springframework.util.NumberUtils

Öyleyse, hizmet sınıflarınızı nasıl adlandırıyorsunuz?

java naming-conventions

— JR.
kaynak

82

Bu tür birçok konvansiyon gibi, önemli olan, kullandığınız konvansiyonu tutarlı bir şekilde kullandığınız kadar çok da değildir. Örneğin, üç faydalı sınıfınız varsa ve bunlara CustomerUtil, ProductUtils ve StoreUtility adını verirseniz, sınıflarınızı kullanmaya çalışan diğer insanlar sürekli olarak kafaları karışacak ve yanlışlıkla CustomerUtils yazacak, aranacak, sizi birkaç kez lanetleyecek, vb. (Bir keresinde konuşmacının "1", "2." ve "C" olarak etiketlenmiş üç ana noktadan oluşan konuşmasının ana hatlarını gösteren bir slayt koyduğu tutarlılık üzerine bir ders duydum.)

Asla bir CustomerUtil ve bir CustomerUtility gibi, yalnızca bazı yazım inceliklerinde farklılık gösteren iki isim asla yapmayın. İki sınıf yapmak için iyi bir neden varsa, o zaman onlarda farklı bir şeyler olmalı ve isim en azından bize bu farkın ne olduğu konusunda bir ipucu vermelidir. Biri ad ve adresle ilgili yardımcı işlevler içeriyorsa ve diğeri siparişlerle ilgili yardımcı işlevler içeriyorsa, bunları CustomerNameAndAddressUtil ve CustomerOrderUtil veya benzer şekilde arayın. İsimlerde anlamsız ince farklılıklar gördüğümde düzenli olarak deliriyorum. Daha dün olduğu gibi, navlun maliyetleri için "navlun", "navlun maliyeti" ve "fright" adlı üç alanı olan bir program üzerinde çalışıyordum. Aralarındaki farkın ne olduğunu anlamak için kodu incelemeliydim.

— alakarga
kaynak

9

Ve 4 numaralı :-) için IV - Ama ne oldu arasındaki fark navlun , freightcost ve frght ?

— KajMagnus

4

@KayMagnus Bu gönderi bir yıldan daha uzun bir süre önceydi, ancak hatırladığım kadarıyla bunlardan biri, siparişin içeriğini ve dolayısıyla potansiyel olarak navlun maliyetini değiştirmeden önce rekordaki mevcut navlun maliyetiydi; diğeri bir tablodan alınan standart navlun maliyetiydi; ve üçüncüsü, denizaşırı gönderiler gibi bazı özel durumlarda kullanılan hesaplanmış bir maliyetti. Mesela neden en azından "currFreight", "stdFreight" ve "calcFreight" diyemediler. Bu en azından bir ipucu verirdi.

— Jay

Tamam, açıklama için teşekkürler :-) Bence ilginç bir tuhaf kod örneği

— KajMagnus

31

Bunun için Java dünyasında standart bir kural / kongre yoktur. Bununla birlikte, @colinD'nin de bahsettiği gibi Sınıf adının sonuna "s" eklemeyi tercih ediyorum.

Bu, Master java API Designer Josh Bloch'un yaptığı şey için oldukça standart görünüyor (java koleksiyonu ve google koleksiyonu)

Helper ve Util gittiği sürece, bir paketin belirli bir işlevselliğini elde etmeye yardımcı olan API'lere sahip olduğunda (bir modülü uygulamak için bir paketi düşünerek) bir şeyi Yardımcı olarak adlandıracağım; bir Util herhangi bir bağlamda çağrılabilirken.

Örneğin, banka hesaplarıyla ilgili bir uygulamada, sayıya özgü tüm yardımcı program statik API'leri org.mycompany.util.Numbers

API'lerin gitmesine yardımcı olan tüm "Hesaba" özel iş kurallarının

org.mycompany.account.AccountHelper

Sonuçta, daha iyi dokümantasyon ve daha temiz kod sağlama meselesi.

— yüzük taşıyıcısı
kaynak

5

Bu makul görünüyor, bu Helper Utils'ten daha spesifik olacaktır.

— KajMagnus

1

Evet, bu yaklaşımı seviyorum, daha mantıklı.

— Conan

3

Bağlantı koptu. Başka bir tane buldum .

— Chavjoh

22

Tür bir arabirim veya sizin kontrol etmediğiniz bir sınıf olduğunda, tür adına "s" eklemeyi seviyorum. Bunun JDK'daki örnekleri arasında Collectionsve Executors. Aynı zamanda Google Koleksiyonlarında kullanılan bir sözleşmedir.

Kontrolünüz olan bir sınıfla uğraşırken , fayda yöntemlerinin genel olarak sınıfın kendisine ait olduğunu söyleyebilirim.

— ColinD
kaynak

2

Google Guava da bu kalıbı kullanıyor

— Jherico

11

Bence bu 'utils' paket adı olmalı. Sınıf adları, içindeki mantığın amacını belirtmelidir. -Util (ler) sonekinin eklenmesi gereksizdir.

— Aito
kaynak

2

Bu, 'özelliğe göre paket' yaklaşımında yapılacak doğru şey değildir .

— jpangamarca

1

@jpangamarca Bağlandığınız makale, 'özelliğe göre paket' örneğinde bir "util" paketine sahip. Pratikte bir tür kullanım özelliğinin / katmanının genellikle önlenemeyeceğini düşünüyorum.

— kapex

1

@kapex Yazarın gözünden kaçmış sanırım. Bir tld.organization.app.utilpaket olmamalıdır (olabilir ama olmamalıdır), herhangi bir sayıda tld.organization.app.feature.utilpaket mükemmeldir.

— jpangamarca

3

"Yardımcı" ve "yardımcı programlar" kelimelerinin birbirinin yerine kullanıldığından oldukça eminim. Her neyse, sağladığınız örneklere bakılırsa, sınıf adınızın bir kısaltma olup olmadığını (veya "DomUtil" gibi kısaltmalar içeriyorsa), sonra paketinizi "her neyse.WhateverUtil" (veya paketinizde birden fazla yardımcı program varsa Utils ). Aksi takdirde, bir kısaltma yerine tam bir adı varsa, o zaman "her neyse, her ne işe yarar" olarak adlandırın.

Bu gerçekten size kalmış, ancak kodlayıcılar neden bahsettiğinizi bildiği sürece, gitmekte fayda var. Bunu profesyonel bir şekilde birisinin işi olarak yapıyorsanız, tavsiyemi almadan önce kodlama standartlarının ne olduğunu sorun. İşinizi korumanıza yardımcı olacak ne olursa olsun her zaman mağaza standartlarına uyun. :-)

— KSwift87
kaynak