Kodlarımın bazılarında buna benzer statik bir fabrika var:
public class SomeFactory {
// Static class
private SomeFactory() {...}
public static Foo createFoo() {...}
public static Foo createFooerFoo() {...}
}
Kod incelemesi sırasında bunun bir singleton olması ve enjekte edilmesi önerildi. Yani, bu gibi görünmeli:
public class SomeFactory {
public SomeFactory() {}
public Foo createFoo() {...}
public Foo createFooerFoo() {...}
}
Vurgulanması gereken birkaç şey:
- Her iki fabrika da vatansız.
- Yöntemler arasındaki tek fark, kapsamlarıdır (örnek vs statik). Uygulamalar aynıdır.
- Foo, arayüzü olmayan bir fasulyedir.
Statik olma konusunda sahip olduğum argümanlar şuydu:
- Sınıf vatansız, bu nedenle somutlaştırılması gerekmiyor
- Statik bir yöntem çağırabilmek bir fabrikayı canlandırmaktan daha doğal görünüyor
Tekton olarak fabrika argümanları:
- Her şeyi enjekte etmek iyi
- Fabrikanın vatansızlığına rağmen, enjeksiyonla test yapmak daha kolaydır (takması kolaydır)
- Tüketici test edilirken alay edilmeli
Singleton yaklaşımı ile ilgili ciddi sorunlarım var çünkü hiçbir yöntemin statik olmaması gerektiğini gösteriyor. Aynı zamanda StringUtilsaptalca görünen, sarılmış ve enjekte edilmiş gibi yardımcı programların da olduğu anlaşılıyor. Son olarak, doğru görünmeyen bir noktada fabrika ile alay etmeye ihtiyacım olacağı anlamına geliyor. Fabrika ile ne zaman alay etmem gerektiğini düşünemiyorum.
Topluluk ne düşünüyor? Singleton yaklaşımını sevmiyorum, ancak buna karşı oldukça güçlü bir tartışmaya sahip görünmüyorum.
DateTimeve Filesınıfların aynı nedenlerle test edilmesi çok zordur. Örneğin yapıcıdaki Createdtarihi ayarlayan bir sınıfınız varsa, DateTime.Now5 dakika arayla oluşturulan bu iki nesneden oluşan bir birim testi oluşturmaya ne dersiniz? Peki ya yıllar sonra? Bunu gerçekten yapamazsınız (çok fazla iş olmadan).
privatekurucusu ve bir getInstance()yöntemi yok mu? Üzgünüz, çözülemez nit-toplayıcı!