Java kod tabanımızda aşağıdaki modeli görmeye devam ediyorum:
/**
This is a stateless utility class
that groups useful foo-related operations, often with side effects.
*/
public class FooUtil {
public int foo(...) {...}
public void bar(...) {...}
}
/**
This class does applied foo-related things.
*/
class FooSomething {
int DoBusinessWithFoo(FooUtil fooUtil, ...) {
if (fooUtil.foo(...)) fooUtil.bar(...);
}
}Beni rahatsız eden şey, FooUtil her yerde , çünkü test.
- Yapamam
FooUtilYöntemlerini statik , çünkü her ikisini deFooUtilve istemci sınıflarını test etmek için onları alay edemeyeceğim . - İle
FooUtiltüketim yerinde bir örnek oluşturamıyorumnew, çünkü test için alay edemeyeceğim.
En iyi seçeneğimin enjeksiyon kullanmak olduğunu düşünüyorum (ve yapıyorum), ancak kendi zorluklarını ekliyor. Ayrıca, birkaç util örneğinin iletilmesi, yöntem parametre listelerinin boyutunu şişirir.
Görmediğim kadar iyi idare etmenin bir yolu var mı?
Güncelleme: yardımcı sınıflar vatansız olduğundan, muhtemelen test için sınıfın temel statik alanını güncelleme yeteneğini korurken statik bir tekil INSTANCEüye veya statik bir getInstance()yöntem ekleyebilirim . Çok temiz görünmüyor.
4
Ve birim testleri etkili bir şekilde yapmak için tüm bağımlılıkların alay konusu olması gerektiği varsayımı doğru değil (yine de bunu tartışan soruyu arıyorum).
—
Telastyn
Bu yöntemler neden verilerini işledikleri sınıfın üyeleri değil?
—
Jules
FooUtility ise statik fns adını veren ayrı bir Junit setine sahip olun. Sonra alay etmeden kullanabilirsiniz. Eğer taklit etmeniz gereken bir şey varsa, o zaman sadece bir yardımcı program değil, bazı IO veya iş mantığı yapıyor ve aslında bir sınıf üyesi referansı olmalı ve yapıcı, init veya setter yöntemi ile başlatılmalıdır.
—
tgkprog
Jules yorumu için +1. Util sınıfları bir kod kokusudur. Anlambilime bağlı olarak daha iyi bir çözüm olmalıdır. Belki
—
valenterry
FooUtilyöntemlerin içine konulması FooSomething, belki de bu yöntemlerin FooSomethingdeğiştirilmesi / genişletilmesi gereken özellikler vardır, böylece FooUtilyöntemlere artık ihtiyaç duyulmaz. Lütfen bize FooSomethingbu sorulara iyi bir cevap sunmamıza yardımcı olacak daha somut bir örnek verin.
@valenterry: util sınıflarının kod kokusu olmasının tek nedeni Java'nın bağımsız işlevlere sahip olmak için iyi bir yol sunmamasıdır. Sınıflara özgü olmayan işlevlere sahip olmanın çok iyi nedenleri vardır.
—
Robert Harvey