Tek bir uygulama oluşturan çokluk. Umutsuz mu? Servis bulucu mu kullanıyorsunuz?

Enjeksiyonları kabul etmek yerine doğrudan bağımlılıklarını oluşturan 1001 müşterimiz olduğunu varsayalım. Patronumuza göre 1001'i yeniden düzenlemek bir seçenek değil. Aslında kaynaklarına erişime bile izin verilmiyor, sadece sınıf dosyalarına.

Yapmamız gereken, bu 1001 müşterinin geçtiği sistemi "modernize etmek" tir. İstediğimiz her şeyi yeniden düzenleyebiliriz. Bağımlılıklar bu sistemin bir parçasıdır. Ve bu bağımlılıklardan bazıları yeni bir uygulamaya sahip olmak için değiştirmemiz gerekiyor.

Yapmak istediğimiz şey, bu çok sayıda müşteriyi tatmin etmek için farklı bağımlılık uygulamalarını yapılandırma yeteneğine sahip olmaktır. Ne yazık ki, istemciler yapıcılara veya ayarlayıcılara yapılan enjeksiyonları kabul etmediği için DI bir seçenek gibi görünmüyor.

Seçenekler:

1) Müşterilerin kullandığı hizmetin uygulanmasını yeniden düzenleyin, böylece müşterilerin şimdi ihtiyaç duyduklarını yapar. Bang işimiz bitti. Esnek değil. Karmaşık değil.

2) Çalışmayı, bir fabrika aracılığıyla edindiği başka bir bağımlılığa devretmesi için uygulamayı yeniden düzenleyin. Artık fabrikayı yeniden düzenleyerek hepsinin hangi uygulamayı kullandığını kontrol edebiliyoruz.

3) Uygulamayı, bir hizmet bulucu aracılığıyla edindiği başka bir bağımlılığa devredecek şekilde yeniden düzenleyin. Şimdi hashmap, küçük bir dökümün devam ettiği nesnelere bir dizi olabilecek servis bulucuyu yapılandırarak, bunların hangi uygulamayı kullandıklarını kontrol edebiliriz .

4) Henüz düşünmediğim bir şey.

Amaç:

Anlamsız karmaşıklık eklemeden eski kötü tasarlanmış istemci kodunu geleceğe sürükleyerek oluşan tasarım hasarını en aza indirin.

Müşteriler bağımlılıklarının uygulanmasını bilmemeli veya kontrol etmemeli, ancak onları inşa etmekte ısrar ediyorlar new. Kontrol edemiyoruz newama inşa ettikleri sınıfı kontrol ediyoruz.

Benim sorum:

Neyi düşünemedim?

Doc Brown Sorulari

gerçekten farklı uygulamalar arasında konfigürasyon yapma olanağına ihtiyacınız var mı? Ne amaçla?

Çeviklik. Çok bilinmeyen. Yönetim değişim potansiyeli ister. Sadece dış dünyaya olan bağımlılığını yitir. Ayrıca test.

farklı uygulamalar arasında geçiş yapmak için bir çalışma zamanı mekaniğine mi yoksa sadece bir derleme zamanı mekaniğine mi ihtiyacınız var? Neden?

Derleme zamanı mekaniği muhtemelen yeterlidir. Test hariç.

uygulamalar arasında hangi ayrıntı düzeyine geçmeniz gerekiyor? Hepsi birden? Modül başına (her biri bir grup sınıf içerir)? Sınıf başına mı?

1001'den sadece biri sistemde aynı anda çalıştırılır. Tüm istemcilerin bir kerede kullandıklarını değiştirmek büyük olasılıkla iyidir. Bağımlılıkların bireysel kontrolü büyük olasılıkla önemlidir.

anahtarı kimin kontrol etmesi gerekiyor? Yalnızca sizin / geliştirici ekibiniz? Bir yönetici? Her müşteri kendi başına mı? Veya müşterinin kodu için bakım geliştiricileri? Peki mekaniklerin ne kadar kolay / sağlam / kusursuz olması gerekir?

Test için dev. Harici donanım bağımlılıkları olarak yönetici değişir. Test edilmesi ve yapılandırılması kolay olmalıdır.

Amacımız sistemin hızlı ve modernize edilebildiğini göstermektir.

uygulama anahtarı için gerçek kullanım durumu?

Birincisi, donanım çözümü hazır olana kadar bazı veriler yazılım tarafından sağlanacaktır.

Desteklenen çözümlerinizin teknik ayrıntılarını ve tam farklılıklarını tam olarak anladığımdan emin değilim, ancak IMHO'nun ilk önce gerçekten ne tür bir esnekliğe ihtiyacınız olduğunu bulmanız gerekiyor.

Kendinize sormanız gereken sorular:

• gerçekten farklı uygulamalar arasında konfigürasyon yapma olanağına ihtiyacınız var mı? Ne amaçla?

• farklı uygulamalar arasında geçiş yapmak için bir çalışma zamanı mekaniğine mi yoksa sadece bir derleme zamanı mekaniğine mi ihtiyacınız var? Neden?

• uygulamalar arasında hangi ayrıntı düzeyine geçmeniz gerekiyor? Hepsi birden? Modül başına (her biri bir grup sınıf içerir)? Sınıf başına mı?

• anahtarı kimin kontrol etmesi gerekiyor? Yalnızca sizin / geliştirici ekibiniz? Bir yönetici? Her müşteri kendi başına mı? Veya müşterinin kodu için bakım geliştiricileri? Peki mekaniklerin ne kadar kolay / sağlam / kusursuz olması gerekir?

Bu soruların cevaplarını göz önünde bulundurarak, size gerekli esnekliği sağlayan aklınıza gelebilecek en basit çözümü seçin. Ek çaba demekse, "her ihtimale karşı" konusunda emin olmadığınız hiçbir esnekliği uygulamayın.

Yanıtlarınıza yanıt olarak: elinizde en az bir gerçek kullanım durumunuz varsa, tasarım kararlarınızı doğrulamak için kullanın. Sizin için en uygun çözüm türünü bulmak için bu kullanım örneğini kullanın. Sadece bir "fabrika" veya "servis bulucu" size ihtiyacınız olanı sağlıyorsa veya başka bir şeye ihtiyacınız varsa deneyin. Her iki çözümün de davanız için eşit derecede iyi olduğunu düşünüyorsanız, bir zar atın.

Sadece bunu doğru yaptığımdan emin olmak için. Bazı derslerden, bazı servislerden C1,...,Cnve doğrudan arayan bir grup istemciden yapılmış hizmetiniz var new Ci(...). Bu yüzden, çözümünüzün genel yapısına katılıyorum, D1,...,Dnbu da güzel ve modern olan bazı yeni sınıflarla yeni bir iç hizmet yaratmak ve bağımlılıklarını enjekte etmek (yığın aracılığıyla bu tür bağımlılıklara izin vermek) ve sonra anında Cive sığdırmak Di. Soru bunu ve bir çift yollarını önerdi nasıl olduğunu 2ve 3.

Benzer bir öneri vermek 2. Bağımlılık enjeksiyonu boyunca Dive dahili olarak kullanabilir ve daha sonra Rnesne grafiğini oluşturmaktan sorumlu normal bir kompozisyon kökü oluşturabilirsiniz (uygun görürseniz bir çerçeve kullanarak). RStatik bir fabrikanın arkasında durun ve her birinin Cibunu geçmesine izin verin Di. Örneğin,

public class OldClassI {
    private final NewClassI newImplementation;

    public OldClassI(Object parameter) {
        this.newImplementation = CompositionRoot.getInstance().getNewClassI(parameter);
    }
}

Temel olarak bu sizin çözümünüz 2'dir, ancak tüm fabrikalarınızı bağımlılık enjeksiyonunun geri kalanıyla birlikte tek bir yerde toplar.

Basit, süslü, tekil uygulamalarla başlayın.

Daha sonra ek uygulamalar oluşturmanız gerekirse, bu, uygulama kararının ne zaman gerçekleştiği sorusudur.

"Yükleme zamanı" esnekliğine ihtiyacınız varsa (her istemci kurulumu tek bir statik uygulama kullanır), yine de fantezi bir şey yapmanız gerekmez. Sadece farklı DLL'ler veya SO'lar (veya lib biçiminiz ne olursa olsun) sunarsınız. İstemci sadece doğru olanı libklasöre koymalıdır ...

Çalışma zamanı esnekliğine ihtiyacınız varsa, yalnızca ince bir adaptöre ve bir uygulama seçici mekanizmasına ihtiyacınız olacaktır. Bir fabrika, konumlandırıcı veya IoC konteyneri kullanıp kullanmadığınız çoğunlukla tartışmalıdır. Bir adaptör ve bir konumlandırıcı arasındaki tek önemli fark A) Adlandırma ve B) Döndürülen nesnenin tek mi yoksa özel bir örnek mi olduğudur. Ve bir IoC konteyneri ile bir fabrika / konumlandırıcı arasındaki en büyük fark kimin adını verdiği . (Genellikle kişisel tercih meselesi.)