Bağımlılık enjeksiyonunun faydalarını anlıyorum. Mesela Baharı ele alalım. Ayrıca AOP, farklı türden yardımcılar gibi diğer Spring özelliklerinin faydalarını da anlıyorum. XML yapılandırmasının aşağıdaki gibi faydalarının neler olduğunu merak ediyorum:
<bean id="Mary" class="foo.bar.Female">
<property name="age" value="23"/>
</bean>
<bean id="John" class="foo.bar.Male">
<property name="girlfriend" ref="Mary"/>
</bean>
düz eski java koduyla karşılaştırıldığında, örneğin:
Female mary = new Female();
mary.setAge(23);
Male john = new Male();
john.setGirlfriend(mary);
bu daha kolay hata ayıklama, derleme zamanı kontrol etme ve yalnızca java bilen herkes tarafından anlaşılabilir. Öyleyse bir bağımlılık enjeksiyon çerçevesinin temel amacı nedir? (veya faydalarını gösteren bir kod parçası.)
GÜNCELLEME:
Durumunda
IService myService;// ...
public void doSomething() {
myService.fetchData();
}
Birden fazla varsa, IoC çerçevesi myService'in hangi uygulamasının enjekte edilmesini istediğimi nasıl tahmin edebilir? Verilen arayüzün yalnızca bir uygulaması varsa ve IoC konteynerinin onu kullanmaya otomatik olarak karar vermesine izin verirsem, ikinci bir uygulama göründükten sonra kırılacaktır. Ve bir arayüzün kasıtlı olarak yalnızca bir olası uygulaması varsa, onu enjekte etmenize gerek yoktur.
IoC'nin faydalarını gösteren küçük bir yapılandırma parçası görmek gerçekten ilginç olurdu. Spring'i bir süredir kullanıyorum ve böyle bir örnek veremem. Ve hazırda bekletme, dwr ve kullandığım diğer çerçevelerin faydalarını gösteren tek satırlar gösterebilirim.
GÜNCELLEME 2:
IoC yapılandırmasının yeniden derlenmeden değiştirilebileceğinin farkındayım. Gerçekten o kadar iyi bir fikir mi? Birisi yeniden derlemeden DB kimlik bilgilerini değiştirmek istediğinde anlayabiliyorum - geliştirici olmayabilir. Uygulamanızda, geliştiriciden başka biri IoC yapılandırmasını ne sıklıkla değiştiriyor? Geliştiriciler için yapılandırmayı değiştirmek yerine belirli bir sınıfı yeniden derleme çabası olmadığını düşünüyorum. Ve geliştirici olmayanlar için muhtemelen hayatını kolaylaştırmak ve daha basit bir yapılandırma dosyası sağlamak istersiniz.
GÜNCELLEME 3:
Arayüzler ve somut uygulamaları arasında haritalamanın harici konfigürasyonu
Onu dıştan yapmakta bu kadar iyi olan nedir? Kodunuzun tamamını harici yapmazsınız, ancak kesinlikle - ClassName.java.txt dosyasına yerleştirin, anında manuel olarak okuyun ve derleyin - vay, yeniden derlemekten kaçındınız. Derlemeden neden kaçınılmalı ?!
Eşlemeleri prosedürel kodda değil, bildirimli olarak sağladığınız için kodlama süresinden tasarruf edersiniz
Bazen bildirimsel yaklaşımın zaman kazandırdığını anlıyorum. Örneğin, bir bean özelliği ile bir DB sütunu arasındaki bir eşlemenin yalnızca bir kez beyan ederim ve hazırda bekletme bu eşlemeyi HSQL'e dayalı olarak SQL oluştururken, kaydederken, kullanır. Bu, bildirimsel yaklaşımın çalıştığı yerdir. Bahar durumunda (benim örneğimde), beyan daha fazla satıra sahipti ve karşılık gelen kodla aynı ifadeye sahipti. Böyle bir beyanın koddan daha kısa olduğu bir örnek varsa - onu görmek isterim.
Kontrolü Ters Çevirme ilkesi, gerçek uygulamaları sahte olanlarla değiştirebileceğiniz için kolay birim testine izin verir (SQL veritabanını bellek içi biriyle değiştirmek gibi)
Kontrol faydalarının tersine çevrilmesini anlıyorum (Burada tartışılan tasarım modelini Bağımlılık Enjeksiyonu olarak adlandırmayı tercih ediyorum, çünkü IoC daha geneldir - birçok kontrol türü vardır ve biz sadece birini tersine çeviriyoruz - başlatma kontrolü). Neden birinin bunun için bir programlama dilinden başka bir şeye ihtiyacı olduğunu soruyordum. Gerçek uygulamaları kesinlikle kod kullanarak sahte olanlarla değiştirebilirim. Ve bu kod, konfigürasyonla aynı şeyi ifade edecek - alanları sahte değerlerle başlatacak.
mary = new FakeFemale();DI'nin faydalarını anlıyorum. Aynı şeyi yapan kodu yapılandırmaya kıyasla harici XML yapılandırmasının hangi faydaları eklediğini anlamıyorum. Derlemeden kaçınılması gerektiğini düşünmüyorum - her gün derliyorum ve hala hayattayım. DI yapılandırmasının bildirimsel yaklaşımın kötü bir örneği olduğunu düşünüyorum. Bildirim, bir kez bildirilirse VE farklı şekillerde birçok kez kullanılırsa yararlı olabilir - örneğin, bean özelliği ile DB sütunu arasındaki eşlemenin, kaydetme, yükleme, arama sorguları oluşturma vb. İçin kullanıldığı hazırda bekletme cfg gibi. Spring DI yapılandırması, kolayca tercüme edilebilir Bu sorunun başında olduğu gibi kod yapılandırmak, değil mi? Ve sadece fasulye başlatmak için kullanılıyor, değil mi? Bu, bildirimsel yaklaşımın buraya hiçbir şey eklemediği anlamına gelir, değil mi?
Hazırda bekletme eşleştirmesini ilan ettiğimde, sadece bazı bilgileri hazırda bekletme moduna alıyorum ve buna göre çalışıyor - ne yapacağımı söylemiyorum. İlkbahar durumunda, beyanım ilkbahara tam olarak ne yapması gerektiğini söylüyor - öyleyse neden ilan etsin, neden sadece yapmayasın?
SON GÜNCELLEME:
Beyler, birçok cevap bana iyi olduğunu bildiğim bağımlılık enjeksiyonu hakkında konuşuyor. Soru, kodu başlatmak yerine DI konfigürasyonunun amacı ile ilgilidir - kodu başlatmanın daha kısa ve daha net olduğunu düşünüyorum. Soruma şu ana kadar aldığım tek cevap, konfigürasyon değiştiğinde yeniden derlemeyi engellemesi. Sanırım bir soru daha yazmalıyım, çünkü bu benim için büyük bir sır, bu durumda neden derlemeden kaçınılmalı.