Bağımlılık enjeksiyonunu veya tekil kalıbı ne zaman kullanacağımızı nasıl belirleyebiliriz? "Tekil kalıp yerine Bağımlılık enjeksiyonu kullanın" dedikleri birçok web sitesinde okudum. Ama onlara tamamen katılıp katılmadığımdan emin değilim. Küçük veya orta ölçekli projelerim için kesinlikle tekli desen kullanımını basit görüyorum.
Örneğin Logger. Kullanabilirim Logger.GetInstance().Log(...)
Ama bunun yerine neden oluşturduğum her sınıfa logger örneğiyle enjekte etmem gerekiyor?
Yanıtlar:
Bir testte nelerin kaydedildiğini doğrulamak istiyorsanız, bağımlılık enjeksiyonuna ihtiyacınız var. Ayrıca, bir kaydedici nadiren tekildir - genellikle her sınıfınız için bir kaydediciniz vardır.
Test edilebilirlik için Nesne odaklı tasarım hakkındaki bu sunumu izleyin ve tekillerin neden kötü olduğunu göreceksiniz.
Tekillerle ilgili sorun, özellikle testlerde tahmin edilmesi zor olan küresel bir durumu temsil etmeleridir.
Bir nesnenin fiilen tek başına olabileceğini, ancak yine de yoluyla değil, bağımlılık enjeksiyonu yoluyla elde edilebileceğini unutmayın Singleton.getInstance().
Misko Hevery'nin sunumunda değindiği bazı önemli noktaları listeliyorum. Bunu izledikten sonra bunu bir nesne tanımlamak için neden daha iyi olduğunu tam perspektif kazanacak neyi bağımlılıkları vardır, ama bir yolunu tanımlamak değil nasıl oluşturulacağını onları.
Singleton'lar komünizm gibidir: her ikisi de kağıt üzerinde harika ses çıkarır, ancak pratikte problemlerle patlar.
Tekil desen, nesnelere erişim kolaylığına orantısız bir vurgu yapar. Her tüketicinin AppDomain kapsamlı bir nesne kullanmasını gerektirerek bağlamdan tamamen kaçınır ve değişen uygulamalar için hiçbir seçenek bırakmaz. Tamamen sıfır ifade gücü GetInstance()eklerken , altyapı bilgisini sınıflarınıza yerleştirir (çağrı ) . Ne için değiştirmeden bir sınıfı tarafından kullanılan uygulama değiştiremezsiniz çünkü Aslında, sizin ifade gücünü azaltır hepsi bunlardan. Tek seferlik işlevsellik ekleyemezsiniz.
Sınıf Ayrıca, ne zaman Foobağlıdır Logger.GetInstance(), Fooetkin bir tüketicilerden bağımlılıklarından saklıyor. Bu Foo, kaynağını okumadıkça ve bağlı olduğu gerçeğini ortaya çıkarmadıkça onu tam olarak anlayamayacağınız veya güvenle kullanamayacağınız anlamına gelir Logger. Kaynağa sahip değilseniz, bu, bağlı olduğunuz kodu ne kadar iyi anlayabileceğinizi ve etkili bir şekilde kullanabileceğinizi sınırlar.
Statik özelliklerle / yöntemlerle uygulandığı şekliyle tekli desen, bir altyapının uygulanmasına yönelik bir saldırıdan biraz daha fazlasıdır. Alternatifler üzerinde fark edilebilir bir fayda sunmazken sizi sayısız şekilde sınırlar. İstediğiniz gibi kullanabilirsiniz, ancak daha iyi tasarımı destekleyen uygulanabilir alternatifler olduğu için, bu asla önerilen bir uygulama olmamalıdır.
Diğerleri sorunu genel olarak tekli tonlarla çok iyi açıkladı. Logger'ın özel durumu hakkında bir not eklemek istiyorum. Statik getInstance()veya getRootLogger()yöntem aracılığıyla bir Logger'a (veya kesin olarak kök kaydediciye) tekil olarak erişmenin genellikle sorun olmadığı konusunda sizinle aynı fikirdeyim . (eğer test ettiğiniz sınıf tarafından nelerin kaydedildiğini görmek istemiyorsanız - ancak deneyimlerime göre bunun gerekli olduğu bu tür durumları pek hatırlayamıyorum. Sonra yine, diğerleri için bu daha acil bir sorun olabilir).
IMO, test ettiğiniz sınıfla ilgili herhangi bir durum içermediğinden, genellikle tek bir kaydedici endişe değildir. Yani, kaydedicinin durumunun (ve olası değişikliklerinin) test edilen sınıfın durumu üzerinde hiçbir etkisi yoktur. Dolayısıyla birim testlerinizi daha da zorlaştırmaz.
Alternatif olarak, günlükçüyü oluşturucu aracılığıyla uygulamanızdaki (neredeyse) her sınıfa enjekte etmek olabilir. Alternatif o noktada keşfettiklerinde olurdu - arayüzleri tutarlılık için, söz konusu sınıf şu anda herhangi bir şey log olmasa bile enjekte edilmelidir şimdi böylece, bu sınıftan bir şey giriş yapmanız, bir logger gerek DI için tüm istemci kodunu bozarak bir yapıcı parametresi eklemeniz gerekir. Bu iki seçenekten de hoşlanmıyorum ve günlük kaydı için DI kullanmanın, herhangi bir somut fayda olmaksızın teorik bir kurala uymak için hayatımı karmaşıklaştıracağını düşünüyorum.
Sonuç olarak benim alt satırım: (neredeyse) evrensel olarak kullanılan, ancak uygulamanızla ilgili durumu içermeyen bir sınıf, Singleton olarak güvenle uygulanabilir .
Çoğunlukla, ancak tamamen testlerle ilgili değil. Singltonlar popülerdi çünkü onları tüketmek kolaydı, ancak tekillerin bazı dezavantajları var.
DI size bağımlı sınıflarınızın kolay kullanımını sağlar - sadece yapıcı parametrelerine koyun ve sistem bunu size sağlar - aynı zamanda size test ve yapım esnekliği verir.
Bağımlılık Enjeksiyonu yerine bir Singleton kullanmanız gereken tek zaman, Singleton'un List.Empty veya benzeri gibi (değişmez listeler varsayılarak) değişmez bir değeri temsil etmesidir.
Bir Singleton için bağırsak kontrolü "Bu bir Singleton yerine global bir değişken olsaydı uygun olur muydum?" Değilse, global bir değişkeni yazmak için Singleton modelini kullanıyorsunuz ve farklı bir yaklaşım düşünmelisiniz.
Monostate makalesine baktım - bu Singleton'a güzel bir alternatif, ancak bazı garip özelliklere sahip:
class Mono{
public static $db;
public function setDb($db){
self::$db = $db;
}
}
class Mapper extends Mono{
//mapping procedure
return $Entity;
public function save($Entity);//requires database connection to be set
}
class Entity{
public function save(){
$Mapper = new Mapper();
$Mapper->save($this);//has same static reference to database class
}
$Mapper = new Mapper();
$Mapper->setDb($db);
$User = $Mapper->find(1);
$User->save();
Bu tür korkutucu değil mi - çünkü Eşleştirici, save () işlemini gerçekleştirmek için veritabanı bağlantısına gerçekten bağımlıdır - ancak daha önce başka bir eşleyici oluşturulmuşsa, bağımlılıklarını edinirken bu adımı atlayabilir. Derli toplu olsa da, biraz dağınık değil mi?
Singleton'a başka alternatifler de var: Proxy ve MonoState modelleri.
http://www.objectmentor.com/resources/articles/SingletonAndMonostate.pdf