Java'da bir dizi junit test sınıfı yazıyorum. Birkaç sabit vardır, örneğin farklı test sınıflarında ihtiyaç duyacağım dizeler. Onları tanımlayan bir arayüz düşünüyorum ve her test sınıfı bunu uygulayacaktır.
Gördüğüm faydalar:
MY_CONSTANTonun yerine
ThatClass.MY_CONSTANT
Bu yaklaşım oldukça iyi veya kötü bir uygulama mı? Bunu yapmak arayüz kavramını kötüye kullanmak gibi bir şey gibi hissediyorum.
Genel olarak arayüzler/sabitler hakkında değil, aynı zamanda özel bir şey varsa birim testleri hakkında da cevap verebilirsiniz.
Joshua Bloch Etkili Java başlıklı kitabında buna karşı tavsiyede bulunur:
Bir sınıfın dahili olarak bazı sabitleri kullanması bir uygulama detayıdır. Sabit bir arabirim uygulamak, bu uygulama ayrıntısının sınıfların dışa aktarılan API'sına sızmasına neden olur. Bir sınıfın kullanıcıları için, sınıfın sabit bir arabirim uygulaması önemli değildir. Aslında, onları karıştırabilir. Daha da kötüsü, bir taahhüdü temsil eder: eğer ileriki bir sürümde, sınıf artık sabitleri kullanması gerekmeyecek şekilde değiştirilirse, ikili uyumluluğu sağlamak için hala arabirimi uygulamalıdır.
Aynı efekti sabitleri tanımlayan normal bir sınıfla alabilir ve sonra
import static com.example.Constants.*;
Bizim durumumuzda bunu yapıyoruz, çünkü sabitlerin değerleri, bir hizmet uygulamasının sağlaması gereken son durumlar için bir sözleşmeyi temsil eder. Bu sabitleri arabirime koymak, sözleşmenin bir parçası olarak bitiş durumlarını belirtir ve arabirimin herhangi bir uygulaması bunları kullanmazsa, işini yapmaz.
SOMETIMES sabitleri uygulama ayrıntılarıdır. BAZI DEĞİLDİR. Her zamanki gibi, bir mühendisin ne yapacağına karar vermek için beynini kullanması gerekir ve süpürme desenine veya pratiğine güvenmez.
Ben sabitler için arayüzler sadece iyi bir şey olduğunu sanmıyorum.
Ancak davranışı tanımlayan bir arabirim (sınıfları uygulayan yöntemler uygulamak zorundadır), sabitleri varsa, sorun olmaz. API'ya "uygulayıcının bazı ayrıntılarını sızdırıyorsa" , olması gerektiği gibi olmasıdır. Ayrıca uygulayıcının
.foo() ve
.bar() yöntemlerini uyguladığını sızdırıyorlar.
Örneğin
Java.awt.Transparency Arayüzünü ele alalım.
OPAQUE,
BITMASK ve
TRANSLUCENT sabitleri vardır ancak
.getTransparency() yöntemine sahiptir.
Tasarımcı bu sabitleri oraya koyarsa, bunun nedeni
.getTransparency() gibi arayüzün bir parçası olacak kadar kararlı olacağını düşündüğü içindir.
Çalıştığım bir şirket arayüz ithalinden yoğun olarak yararlandı1 sabitler. Herhangi bir zararı hissetmiyorum.
Kendinize sormanız gereken soru --- adınız sizin için ne kadar önemli? Sabitler söz konusu olduğunda, bu gerçekten bir sınıf gibi davranır. Binlerce sabitiniz varsa, bu sabitlerin hepsinin her zaman kullanılabilir olmasını istemeyebilirsiniz.
Arayüzler ile ilgili en güzel şey, size her iki şekilde de çalışma avantajı sağlamasıdır - ihtiyacınız olan tüm ad alanlarını veya hiçbirini getirmeyin (ve
MyInterface.CONSTANT İle açıkça erişin).
import static MyInterface.* İle hemen hemen aynı şey, ama biraz daha açık.
1: Java'ya aşina değilseniz,
import anahtar kelimesini kastetmiyorum, sadece
implements MyConstantsInterface
Sözleşme ile tasarımın yaygın olduğu yerlerde çoğunlukla popüler bir bakış açısı olduğunu düşünün.
Arayüzler sözleşmelerdir. Sabitleri arabirimlere yerleştirmek, sözleşmeye uyan her sınıfın, sabit tarafından tanımlanan değer/kavramı kabul ettiği anlamına gelir.
Hayır, genel bir kötü uygulama değil.
Mesele şu ki, diğer herhangi bir artefakt gibi sabitler, minimum görünürlük ve uygun soyutlama seviyesi kuralları altında sokulmalıdır.
Sözdizimini sadece yapabildiğiniz için kullanmak asıl sorun.
Çoğunlukla öncelikle 'Ada yolu' ve '.Net yolu' ndan etkilenen bir arka plandan geliyorum. Hayır diyebilirim, muhtemelen arayüzler içindeki sabitleri bildirmek en iyisi değildir. Teknik olarak c # 'a izin verilmez.
Hayır dememizin nedeni, bir arayüzün, durumu veya yapıyı değil, davranışı tanımlayan bir sözleşme biçimi olmasıdır. Sabit, bir tür durum (ilkel) veya durumun bir yönünü (bileşik veya toplam) ifade eder.
Varsayılanları ve önceden tanımlanmış değerleri arabirimi uygulayan herkes için kullanılabilir hale getirme isteğini takdir edebilirim, ancak belki de varsayılan durum, varsayılanların en az minimum içeriğe sahip olacağı bir soyut veya değer nesnesinde veya şablonunda daha iyi açıklanabilir.
Daha teknik bir kılavuz için: download.Oracle.com/javase/1.5.0/docs/guide/language/static-import.html