it-swarm.dev

Arayüzler ayrı bir pakete yerleştirilmeli mi?

Oldukça büyük bir proje üzerinde çalışan ve birçok bileşeni ve bağımlılığı olan bir ekipte yeniyim. Her bileşen için, o bileşen için açıkta kalan arabirimlerin yerleştirildiği bir interfaces paketi vardır. Bu iyi bir uygulama mı?

Her zamanki pratikim her zaman arayüzlerdi ve uygulamalar aynı pakette yapıldı.

67
kctang

Hem arabirimi hem de uygulamayı yerleştirmek çok yaygındır ve bir sorun gibi görünmemektedir.

Örneğin, Java API'sini ele alın - çoğu sınıfta hem arayüzler hem de uygulamaları aynı pakette bulunur. 

Örneğin, Java.util paketini alın:

Set, Map, List gibi arayüzleri içerir, ayrıca HashSet, HashMap ve ArrayList gibi uygulamaları da içerir.

Ayrıca, Javadocs, dokümantasyon paket içeriğini görüntülerken Arayüzler ve Sınıflar görünümlerine ayırdığı için bu koşullarda iyi çalışacak şekilde tasarlanmıştır.

Çok fazla sayıda arayüz olmadıkça, sadece arayüzler için paketlere sahip olmak aslında biraz fazla olabilir. Ancak, kötü uygulama gibi ses çıkarması için arayüzleri kendi paketlerine ayırmak.

Bir arabirimin adını bir uygulamadan ayırt etmek gerekirse, arabirimlerin tanımlanmasını kolaylaştırmak için bir adlandırma kuralı olabilir:

  • Arayüz adını bir I ile önekleyin. Bu yaklaşım, .NET çerçevesindeki arayüzlerle birlikte alınır. IList bir liste için bir arabirim olduğunu söylemek oldukça kolay olurdu.

  • -able sonekini kullanın. Bu yaklaşım, Java API'sinde, Comparable, Iterable ve Serializable gibi birkaç tanesine sıkça rastlanır.

85
coobird

Herhangi bir dil için, bunları aynı pakette bir araya getirmek iyidir. Önemli olan, dış dünyaya maruz kalan şey ve dışardan nasıl göründüğüdür. Uygulamanın aynı pakette olup olmadığını kimse bilmeyecek veya önemsemeyecektir.

Bu özel örneğe bakalım.

Eğer bir paketin içinde herkese açık bir şeyler varsa ve kamuya açık olmayan başka bir pakette özel şeyler varsa, kütüphanenin müşterisi bir paket görür. Özel şeyleri, kamuya açık olan şeylerle birlikte pakete taşırsanız, ancak paketin içinden çıkarmazsanız, müşteri de aynı şeyi görür.

Bu nedenle, bunun iyi bir nedeni olmayan bir kural kokusu vardır: Bu, herhangi bir kararın aleni olarak görülebilen herhangi bir etkisi olmayan, herkes tarafından görülebilen bir şeye dayanarak karar vermesini sağlar.

Bununla birlikte, herhangi bir özel durumda arayüzü ve uygulamayı paketleri ayırmak için bölmek iyi bir fikir gibi görünüyorsa, hemen ilerleyin ve bunu yapın. Bunu aklınıza getirme nedenleri, paketin çok büyük olması veya standart bir paket yerine bağlamak isteyebileceğiniz alternatif bir uygulamanız olması.

17
Curt J. Sampson

OSGi gibi birçok çerçevede, neredeyse yapmak zorundasınız. Bence bu, kavanoz seviyesi yerine paketinde daha gevşek bağlamayı teşvik ediyor.

9
javamonkey79

Arayüzleri farklı paketlere koymanın bir argümanı, ürününüzün veya hizmetinizin tüketicilerine dağıtılabilecek 'api' kavanozları oluşturmanın daha kolay olmasıdır. Arayüzler ve uygulamalar ile birlikte bunu yapmak gerçekten mümkün, ancak farklı paketlerdeyse komut dosyası yazmak daha kolay.

7
Cameron Pope

Pratik Yazılım Mühendisliği: Bir Vaka Çalışması Yaklaşımı, ayrı proje/paketlere arayüz yerleştirmeyi savunuyor. 

Kitabın bahsettiği PCMEF + mimarisi aşağıdaki ilkelere sahiptir:

  1. Aşağıya Bağımlılık İlkesi (DDP)
  2. Yukarı Bildirim Prensibi (UNP)
  3. Komşu İletişim Prensibi (NCP)
  4. Açık Ortaklık Prensibi (EAP)
  5. Döngü Eliminasyon Prensibi (CEP)
  6. Sınıf Adlandırma İlkesi (CNP)
  7. Tanışma Paketi Prensibi (APP)

İlke # 3 ve # 7'nin açıklaması neden bunun iyi bir fikir olduğunu açıklar:

Komşu İletişim İlkesi bir paketin sadece doğrudan komşu paketi ile iletişim kurar. Bu ilke .__ sağlar. sistemin sıkıştırılamaz bir ağa parçalanmaması. iletişim kurabilen nesneler. Bu prensibi uygulamak için, iletiyi geçme komşu olmayan nesneler arasında yetkilendirme kullanılır (Bölüm 9.1.5.1). İçinde daha karmaşık senaryolar, tanışma paketi (Bölüm 9.1.8.2) olabilir. meşgul yapan işbirliğine yardımcı olmak için arayüzleri gruplamak için kullanılır. uzak paketler.

Tanışma Paketi Prensibi, Komşu .__'nın sonucudur. İletişim prensibi Tanışma paketi, aşağıdakilerden oluşmaktadır. Bir nesnenin somut nesneler yerine geçtiği arayüzler, yöntem çağrılarına argümanlar. Arayüzler herhangi bir .__ ile uygulanabilir. PCMEF paketi. Bu etkili arasında bağımlılık yönetimini merkezileştirirken komşu olmayan paketler a tek tanışma paketi. Tanışma paketine duyulan ihtiyaç, Bölüm 9.1.8.2'de açıklanmıştır ve PCMEF .__ 'da tekrar tartışılmaktadır. bağlamı.

Bu bağlantıya bakınız: http://comp.mq.edu.au/books/pse/about_book/Ch9.pdf

5
Kenci

Evet, çok iyi bir uygulamadır, çünkü uygulamanızı yayınlamadan arayüzü yayınlamanıza izin verir. Bununla birlikte, harici arayüzleri yayınlamaya gerek duymuyorsanız, arayüz tanımlarını uygulama ile aynı pakete koymakta sorun yoktur.

4
Paul Sonier

Çalıştığım yerde bunu yaparız (yani: bir pakette arabirim koymak ve diğerinde uygulama koymak) ve bundan elde ettiğimizin en büyük avantajı uygulamalar arasında kolayca yer değiştirebilmemizdir.

3
hhafez

Bunu bir projede yapıyorum ve bu nedenlerden dolayı benim için iyi çalışıyor:

  • Ayrı ayrı paketlenmiş arayüzler ve uygulamalar, çeşitli Harita veya Set türlerinden farklı bir kullanım durumu içindir. Sadece ağaçlar için bir pakete sahip olmak için hiçbir sebep yoktur (Java.util.tree.Map, Java.util.tree.Set). Bu sadece standart bir veri yapısıdır, bu nedenle diğer veri yapılarıyla birlikte koyun. Ancak, gerçekten basit bir hata ayıklama arayüzü ve güzel bir üretim arayüzü olan bir bulmaca oyunuyla uğraşıyorsanız, ön uçunun bir parçası olarak bir com.your.app.skin.debug ve bir com.your.app kullanabilirsiniz. .skin.pretty. Bunları aynı pakete koymaydım, çünkü farklı şeyler yapıyorlar ve aynı pakette olsaydı ikisi için gayri resmi bir ad alanı oluşturmak için bazı SmurfNamingConvention (DebugAttackSurface, DebugDefenceSurface, PrettyAttackSurface vb.) 'A başvuracağımı biliyorum.

  • Ayrı paketlerde bulunan ilgili arayüzleri ve uygulamaları bulma sorununa yönelik geçici çözümüm, paketlerim için bir adlandırma yapılandırması benimsemektir. Örneğin. Tüm arayüzlerimi com.your.app.skin.framework adresinde bulabilirim ve paket ağacının aynı seviyesindeki diğer paketlerin de uygulama olduğunu biliyorum. Dezavantajı bunun alışılmadık bir kongre olmasıdır. Dürüst olmak gerekirse, bu sözleşmenin 6 ay sonra ne kadar iyi olduğunu göreceğim :)

  • Bu tekniği dini olarak kullanmıyorum. Sadece belirli bir uygulamada mantıklı olan arayüzler vardır. Onları çerçeve paketine sokmam. 40 farklı uygulama sınıfı oluşturacağım gibi görünmediği bazı paketler var, bu yüzden rahatsız etmiyorum.

  • Uygulamam guice kullanıyor ve çok fazla arayüze sahip.

Program tasarımının soruları genellikle yararları ve sakıncaları içerir ve tek bir boyuta uygun cevap yoktur. Mesela neden bu tekniği 200 satırlık küçük bir programda kullandınız? Diğer mimari tercihlerime göre, benim özel problemim için benim için anlamlı. :)

2
Moray Jaundice

Java deneyimim çok fazla değildi, ama bunu C # /. NET'te iyi bir uygulama olarak yapmaktan hoşlanıyorum, çünkü arayüzleri uygulayan somut sınıflara sahip montajların tamamen aşağıya dağıtılamayacağı gelecekteki genişlemeye olanak tanıyor Bir aracı servis fabrikası tarafından ya da bir web servisi senaryosunda kablo üzerinden proxy'ler yapıldığı için müşteri.

2
Jesse C. Slicer

Normalde uygulamayla Arayüzler koyarım, ancak neden ayrı tutmak isteyebileceğinizi bir türlü anlayabilirim. Örneğin, birisi sizin arayüzlerinize dayanarak sınıfları yeniden düzenlemek istiyor, sadece arayüzler yerine uygulamanızla bir jar/lib/etc'ye ihtiyaç duyacaklarını söylüyorlar. Onlarla ayrı olarak, “İşte bu arayüz benim uygulamalarım” diyebilir ve onunla iş yapabilirsiniz. Dediğim gibi, ne yaptığımı değil ama neden bazılarını isteyebileceğini anlayabilirim.

1
Matt_JD

Onları aynı pakette tercih ediyorum. Özellikle arayüzler için bir paket oluşturmak anlamsız geliyor. Bu, özellikle arayüz öneklerini ve soneklerini seven takımlar için gereksizdir (örneğin, Java için "I" ve "Impl").

Genel API olarak bir dizi arayüz yayınlama ihtiyacı varsa, bunları tamamen ayrı bir projede tutmak ve bunun yerine proje bağımlılıkları oluşturmak daha mantıklı olur. Fakat her şey sanırım durumun tercihi ve rahatlığına bağlı.

0
aberrant80

OSGi çerçevesi için, uygulama paketlerini saklarken kolayca bir paketin tamamını dışa aktarabilmeniz için farklı paketlerde olmalarının daha iyi olduğunu düşünüyorum.

0
jkabugu

Bunları projelerinizi yansıtan paketlere koyun. Eğer aynı projenin bir parçasıysanız arayüzleri ve uygulamaları bir araya getirmek iyi ve yaygındır, ancak bir API yazıyorsanız, o zaman bir başkası projelerine uygun bir paket adı seçiyor olabilir.

Genel olarak, eğer aynı proje içinse, arayüzleri uygulamalarından ayrı bir pakette tutmanın yararını görmüyorum. Karmaşıklaşırsa, arabirim düzenlemesinden bağımsız olarak başka paket adlandırma sorunları olabilir.

0
Rog