Java'da arayüz adlandırma [kapalı]

Çoğu OO dili arayüz adlarına büyük harf I ekler, Java neden bunu yapmaz? Bu sözleşmeyi izlememenin mantığı neydi?

Ne demek istediğimi göstermek için, bir Kullanıcı arayüzü ve bir Kullanıcı uygulaması olmasını istersem, Java'da iki seçeneğim olurdu:

1. Class = Kullanıcı, Arayüz = UserInterface
2. Class = UserImpl, Arayüz = Kullanıcı

Çoğu dilde:

Sınıf = Kullanıcı, Arayüz = IUser

Şimdi, kullanıcı uygulaması için her zaman en açıklayıcı bir ad seçebileceğinizi ve sorun ortadan kalktığını iddia edebilirsiniz, ancak Java şeylere ve çoğu IOC kapsayıcılarına bir POJO yaklaşımı zorluyor DynamicProxies'i yoğun olarak kullanıyor. Bu iki şey birlikte, tek bir POJO uygulamasıyla çok sayıda arayüzünüz olacağı anlamına gelir.

Yani, sanırım sorum şu şekilde kayboluyor: "Özellikle Java Frameworks'in gittiği yer ışığında daha geniş Arayüz adlandırma kuralını izlemeye değer mi?"

Arayüzlerde bir önek kullanmamayı tercih ederim:

• Önek okunabilirliği incitir.

• İstemcilerde arabirimleri kullanmak, programlamanın standart en iyi yoludur, bu nedenle arabirim adları mümkün olduğunca kısa ve keyifli olmalıdır. Uygulama sınıfları, kullanımlarını caydırmak için daha çirkin olmalıdır.

• Soyut bir sınıftan bir arayüze geçerken, önek ile bir kodlama kuralı, sınıfın tüm oluşumlarını yeniden adlandırmayı ima eder - iyi değil!

Gerçekten arasında bir fark var mı:

class User implements IUser

ve

class UserImpl implements User

tüm konuştuğumuz konvansiyonları isimlendirmekse?

Şahsen ben arabirime Ikodlama yapmak istediğim için arabirimden önce DEĞİL tercih ediyorum ve adlandırma kuralı açısından daha önemli olduğunu düşünüyorum . Arayüzü çağırırsanız, IUsero sınıfın her tüketicisi onun bir IUser. Sınıfı çağırırsanız, UserImplsadece sınıf ve DI konteyneriniz Implparçayı bilir ve tüketiciler bir ile çalıştıklarını bilirler User.

Sonra tekrar, Impldaha iyi bir isim kendini göstermediği için kullanmaya zorlandığım zamanlar çok azdı ve uygulama arasında uygulamaya göre adlandırıldığından önemli olduğu için, örneğin

class DbBasedAccountDAO implements AccountDAO
class InMemoryAccountDAO implements AccountDAO

Java'nın genellikle IUser kuralını kullanmamasının birkaç nedeni olabilir.

1. Nesneye Dayalı yaklaşımın bir parçası, istemcinin bir arabirim mi yoksa bir uygulama sınıfı mı kullandığını bilmeniz gerekmemesidir. Bu nedenle, List bile bir arabirimdir ve String gerçek bir sınıftır, her ikisinden de bir yöntem geçirilebilir - arabirimleri görsel olarak ayırt etmek mantıklı değildir.

2. Genel olarak, istemci kodunda arayüzlerin kullanımını tercih edeceğiz (örneğin, ArrayList'e Liste'yi tercih edin). Bu nedenle, arayüzleri istisna olarak öne çıkarmak mantıklı değil.

3. Java adlandırma kuralı, Macarca tarzı öneklerin gerçek anlamlarıyla daha uzun adları tercih eder. Böylece bu kod mümkün olduğu kadar okunabilir olacaktır: bir Liste bir listeyi temsil eder ve Kullanıcı bir IUser değil bir kullanıcıyı temsil eder.

Bahar da dahil olmak üzere birçok açık kaynaklı proje tarafından kullanılan başka bir sözleşme daha var.

interface User {
}

class DefaultUser implements User {
}

class AnotherClassOfUser implements User {
}

Ben şahsen "I" öneki gibi basit bir nedeni onun isteğe bağlı bir sözleşmeyi sevmiyorum. Bunu benimsersem IIOPConnection, IOPConnection için bir arayüz anlamına mı geliyor? Sınıf "I" önekine sahip değilse, o zaman onun bir arabirim olmadığını biliyor muyum ... burada cevap hayır, çünkü kurallar her zaman takip edilmez ve onları polislik kuralın kendisinin kaydettiği daha fazla iş yaratacaktır.

Başka bir afişin dediği gibi, genellikle arabirimlerin tür değil yetenekleri tanımlaması tercih edilir. "Kullanıcı" gibi bir şeyi "uygulamama" eğilimindeydim ve bu yüzden "IUser" genellikle burada açıklanan şekilde gerçekten gerekli değildir. Sınıfları sık sık isim ve arayüz olarak sıfat olarak görüyorum:

class Number implements Comparable{...}  
class MyThread implements Runnable{...}
class SessionData implements Serializable{....}

Bazen bir Sıfat mantıklı gelmez, ancak yine de genellikle davranışları, eylemleri, yetenekleri, özellikleri, vb. Türleri modellemek için arayüzler kullanırdım.

Ayrıca, gerçekten sadece bir Kullanıcı yapacak ve Kullanıcı olarak adlandıracak olsaydınız, bir IUser arayüzüne sahip olmanın anlamı nedir? Ortak bir arabirim uygulaması gereken birkaç farklı kullanıcı türüne sahip olacaksanız, arabirime bir "I" eklemek, uygulamaların adlarını seçmenize ne kazandırır?

Bence daha gerçekçi bir örnek, bazı kullanıcıların belirli bir API'ya giriş yapabilmeleri gerektiğidir. Bir Login arayüzü tanımlayabiliriz ve daha sonra SuperUser, DefaultUser, AdminUser, AdministrativeContact, vs suclasses içeren bir "User" üst sınıfına sahip olabiliriz, bunlardan bazıları Login (Loginable?) Arayüzünü gerektiği gibi uygular veya uygulamaz.

Bob Lee bir sunumda şunları söyledi:

sadece bir uygulamanız varsa bir arabirimin amacı nedir.

yani, tek bir uygulama ile başlarsınız, yani bir arabirim olmadan. daha sonra karar verirseniz, burada bir arayüze ihtiyaç vardır, böylece sınıfınızı bir arayüze dönüştürürsünüz.

o zaman belli olur: orijinal sınıfınıza Kullanıcı adı verildi. arayüzünüz artık Kullanıcı olarak adlandırılmaktadır. belki bir UserProdImpl ve bir UserTestImpl var. uygulamanızı iyi tasarladıysanız, her sınıf (Kullanıcıyı başlatanlar hariç) değişmeyecek ve aniden bir arayüzden geçtiklerini fark etmeyecektir.

böylece netleşir -> Arayüz Kullanıcı uygulaması UserImpl.

C # 'da

public class AdminForumUser : UserBase, IUser

Java der ki

public class AdminForumUser extends User implements ForumUserInterface

Bu nedenle, arayüzler için java'da sözleşmelerin neredeyse önemli olduğunu düşünmüyorum, çünkü miras ve arayüz uygulaması arasında açık bir fark var. Tutarlı olduğunuz ve insanlara bunların arayüz olduğunu göstermek için bir şey kullandığınız sürece, istediğiniz herhangi bir adlandırma kuralını seçmenizi söyleyebilirim. Birkaç yıl içinde java yapmadım, ancak tüm arayüzler sadece kendi dizinlerinde olacaktı ve kongre buydu. Gerçekten hiçbir sorun yaşamadım.

Deneyimlerime göre, "I" kuralı, özellikle arabirimin kendisi sınıfın soyut bir nosyonu değilse, bir sınıfa sözleşme yapmayı amaçlayan arabirimler için geçerlidir.

Örneğin, sizin durumunuzda, sadece IUsersahip olmayı planladığınız tek kullanıcının olup olmadığını görmeyi beklerim User. Farklı kullanıcı türlerine sahip olmayı planlıyorsanız - NoviceUser, ExpertUservb. - Bir Userarayüz görmeyi beklerim (ve belki de AbstractUserbazı ortak işlevleri uygulayan bir sınıf get/setName()).

Ben de yetenekleri tanımlayan arayüzleri beklenebilir - Comparable, Iterablevb - Böyle adlandırılmış değil gibi olmak IComparableya IIterable.

İyi OO prensiplerine uygun olarak, kodunuz (mümkün / mümkün olduğu ölçüde) somut sınıflardan ziyade soyutlamalara bağlı olmalıdır. Örneğin, genellikle böyle bir yöntem yazmak daha iyidir:

public void doSomething(Collection someStuff) {
    ...
}

Bundan daha:

public void doSomething(Vector someStuff) {
    ...
}

Bu fikri izlerseniz, "IUser", "UserInterface" veya diğer varyasyonlar yerine "Kullanıcı" ve "BankAccount" (örneğin) gibi arayüz adları verirseniz kodunuzun daha okunabilir olmasını sağlarım.

Gerçek beton sınıflarına önem vermesi gereken tek kod parçası, beton sınıflarının yapıldığı yerlerdir. Diğer her şey arayüzler kullanılarak yazılmalıdır.

Bunu yaparsanız, "UserImpl" gibi "çirkin" somut sınıf adları, "nice" arabirim adlarını kullanarak nadiren devam edebilen kodun geri kalanından güvenle gizlenmelidir.

= v = "I" öneki, hızlıca alıştığım Wicket çerçevesinde de kullanılıyor. Genel olarak, hantal Java sınıf adlarını kısaltan herhangi bir konvansiyona hoş geldiniz. Bununla birlikte, her şey dizinlerde ve Javadoc'ta "I" altında alfabetik olarak yazılmıştır.

Wicket kodlama uygulaması Swing'e benzer, çünkü birçok kontrol / widget örneği satır içi yöntem bildirimleriyle anonim iç sınıflar olarak inşa edilir. Can sıkıcı bir şekilde Swing'den 180 ° farklıdır, çünkü Swing uygulama sınıfları için bir önek ("J") kullanır.

"Impl" soneki, mantıklı bir kısaltmadır ve iyi uluslararasılaştırılmamıştır. En azından "İmp" ile gitmiş olsaydık, daha şirin (ve daha kısa) olurdu. "Impl" IOC, özellikle Spring için kullanılıyor, bu yüzden şimdilik onunla sıkışıp kaldık. Bununla birlikte, bir kod tabanının üç farklı bölümünde 3 farklı konvansiyonun ardından biraz şizo alır.

Bu gerçek anlamda daha geniş bir adlandırma kuralı mı? Daha fazla C ++ tarafındayım ve gerçekten Java ve torunlarında değilim. I kuralını kaç dil topluluğu kullanıyor?

Burada dilden bağımsız bir mağaza standart adlandırma kuralınız varsa onu kullanın. Değilse, dil adlandırma kuralına gidin.