DI / IoC kullanımı, “new” anahtar sözcüğünün tüm oluşumlarını kaldırmalı mıdır?


21

Bağımlılık Enjeksiyonu ve Kontrolün Tersine Çevirilmesi kapsayıcısının kullanılması , " " anahtar sözcüğünün tüm oluşumlarını newkodunuzdan çıkarmalı mı?

Başka bir deyişle, ne kadar basit veya kısa ömürlü olursa olsun, her nesne / bağımlılık IoC kabınıza “kaydedilmeli” ve kullanılmaları gereken yöntem / sınıfa enjekte edilmeli midir?

Hayır ise, IoC kabında hangi bağımlılıkların / nesnelerin kaydedildiği çizgisini çizersiniz, bunun yerine "in-line" newkelimesini somut bir referans olarak neyin oluşturduğu ?


Aynı düşünceyi, "yeni" 4 harfli bir kelime mi? "
Michael Easter

Yanıtlar:


27

Dogmadan kaçının. Doğru hissettiren şeyi yap.

Davranışı olmayan veri yapıları için "yeni" kullanmayı tercih ederim.

Sınıfın davranışı varsa, o zaman bu davranışın kapsamına bakarım. Vatansız ve bağımlılığı yoksa, "yeni" ya doğru eğilirim. DI'ye doğru yeniden yapılanmaya yalnızca durum bilgisi olan kaynaklara (bir veritabanı veya dosya gibi) veya bu kaynaklara sahip diğer sınıflara bağımlılık eklemem gerektiğinde başlıyorum.


15
"Dogmadan kaçın" için +1. Ne olduğunu veya nerede uygun şekilde kullanılması gerektiğini anlamadan hareketleri takip etmenin tuzağına düşmek çok kolay.
Wayne Molina

@Alex Bunu beğendim. Çok pragmatik bir yaklaşım. Yeterince komik, soruma newkendi kodumda bağımlılığımı gösteren soruma bazı kodlar ekleyecektim . İşlevsellik veya "davranış" başına basit bir sınıftı, sadece basit özellikleri.
CraigTP

11

In kitabımda , ben Kararlı ve arasındaki ayrımı sağlamak Uçucu bağımlılıklar . DI'yi Uçucu Bağımlılıklar ile kullanmak çok önemlidir, ancak çoğu zaman Kararlı Bağımlılıkları da soyutlayarak ve enjekte ederek daha gevşek bağlanma elde edebilirsiniz.

DI uygulamasının bir DI Konteynere dayanmaması gerektiğini unutmayın . Durumda Poor Man DI kullanımdayken, hiçbir newanahtar kelimeler kaldırılır - onlar sadece taşınır Kompozisyon Root .

Bazı insanlar aslında Zavallı Adam'ın DI Konteynerleri yerine DI'sini tercih ediyor. Bakım maliyeti daha yüksek olabilir, ancak karşılığında derleme zamanı güvenliği elde edersiniz. Geçenlerde Dan North'un dediği gibi: " newYeni olan new" :)

Bununla kastedilen, Kompozisyon Kökü'nü bir DI Konteyneri ile uygulamak yerine, sadece bir sürü iç içe newifade içerir.


Mark, Twitter yorumumu biraz genişletmek için Programcılar, bir uygulamada belirli bir hatayla ilgilenmeyen kavramsal, beyaz tahta-y soruları için doğru yer.
Adam Lear

3
Stack Overflow'un bağımlılık enjeksiyon etiketinde 2000'den fazla sorusu var ve çoğu bunun gibi. Programcıların aynı etikette 23 sorusu var. Bu rakamlara dayanarak, bir geliştirici, böyle bir soruya cevap alma şansını en yüksek bulmalı mı?
Mark Seemann

1
Bu soruların birçoğu tamamen Programcıları öne çıkarır. Bu site SO'dan kavramsal sorular almak ve onlara özel bir ev vermek için oluşturuldu. Ve hala büyüyoruz. Bu devam eden bir çalışma, ancak ideal olarak belirli uygulama sorunlarını içermeyen sorular buraya taşınır. Bu arada elimizden geleni yapıyoruz.
Adam Lear

3

"yeni" yasaklanmış bir anahtar kelime değildir. Kişisel kurallarım:

Tüm "hizmetler" (bir ve yalnızca bir şeyle ilgili bir veya daha fazla yöntem sağlamak için tasarlanmış bir sınıfı çağırırım; örneğin: veritabanına erişmek, belirli bir etki alanı ile ilgili verileri almak / güncellemek) IOC kapsayıcısına kaydedilir. Hiçbir sınıf, kullanması gereken belirli bir hizmetin uygulanmasını nasıl elde edeceğine karar vermemelidir. Bu nedenle, ne zaman mevcut bir hizmeti kullanmanız gerektiğinde, sınıfınızı ve IOC kabını size sağlayabilmek için yapılandırmalısınız. Uygulamanızın nasıl çalıştığını bilmediğinizi, bir web servisi olabileceğini, umursamadığınızı hayal edin.

Tüm fasulye veya modeller, "varsayılan" anahtar kelimelerle veya bazı varsayılan özelliklerin etkinleştirilmesi gerektiğinde IOC tescilli bir fabrika ile oluşturulmalıdır. Ayrıca yalnızca statik yöntemler içeren özel bir hizmet sınıfı örneği de vardır (örneğin: matematiksel bir hizmet servisi). Tamamen bağımsızlarsa ve herhangi bir veritabanı bağlantısına veya IOC'ye kayıtlı başka bir hizmete gerek duymazlarsa, onları IOC'nin dışında bırakıyorum ve statik olarak çağrılmaları gerekiyor. Ancak, böyle bir sınıfın mevcut bir IOC kayıtlı servisini kullanması gerekiyorsa, onu bir singleton sınıfına değiştirir ve IOC'ye kaydettiririm.


2

Sadece daha önce elde edilen mevcut cevapları eklemek istiyorum new, saf değerli nesneler (yani sadece özelliklere / alıcılara / ayarlayıcılara sahip olan) nesneler oluşturmak için gayet iyi. Daha fazla ayrıntı için Google Test Blog'una bakın .


Bağlantı için +1. Bu blog ilanıyla Nokta 9 sorunun cevabının ve ve olmamalıdır gereken arasındaki pragmatik bir ayrım sağlar new'ed
CraigTP

1

Açıkça kullandığınız dile bağlı. Diliniz sizi hem asıl nesneyi hem de kayıtları (değer nesnesi, yapı) temsil etmek için nesneleri kullanmaya zorlarsa, cevap büyük olasılıkla hayır olur.

Tamamen "gerçek" nesnelerden bahsetmişken, açıkça bir örnek oluştururken yanlış bir şey yoktur. Ancak, akılda tutulması gereken şey, tüm sınıfların tek bir sorumluluk ilkesini izlemesi gerektiğidir. Güvendiği bir hizmetin uygulayıcısını seçmek, bir sınıfın sorumluluğunda olmamalıdır. Ancak, bu kadar sorumluluğa sahip, yani belirli hizmetlerin uygulayıcılarını sağlamak için sınıflar vardır. Bir IoC böyle bir sınıf olabilir. Aslında her tür fabrika böyle bir sınıftır.

Özetlemek gerekirse: Sadece bu tür sınıflar nesneleri doğrudan somutlaştırmalı, kimin kendi sorumluluğunu taşıyacağının seçiminin sorumluluğu kimdir?
Bu kriterleri yararlı bulabilirsiniz: http://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Creator


1

Bir kelime: Hayır.

Daha fazla kelime: Bağımlılık enjeksiyonu aynen öyle Başka bir nesnenin bağlı olduğu, ancak karmaşık ayrıntılarını başka bir kaynaktan bilmemesi gereken kaynakları tanıtmanızın bir yoludur. DI'yi kullanmak, programınızdaki HİÇBİR ŞEYİN başka bir nesneyi nasıl yaratacağını bilmesi gerektiği anlamına gelmez; Aslında, önemsiz olmayan bir programın "yeni" anahtar kelimeden (veya yansıma tabanlı alternatiflerden) tamamen kaçınmasının son derece olanaksız olduğunu kabul ediyorum. Bununla birlikte DI, bu nesneyi diğerine sıkıca bağlayacak çok fazla bağımlılık gerektiren karmaşık nesnelerin nasıl oluşturulacağını bilmemesi gereken nesnelerin, tüm bu sıkı bir şekilde birleştirilen bilgiye sahip olmaması gerektiği anlamına gelir.

İki büyük O / O yazılım tasarımı teorisi olan GRASP ve SOLID'i inceleyeceğim. GRASP size nesnenin amacını incelemenizi ve kendinize “Bu başka türden yeni nesneler oluşturmaktan sorumlu mu olmalı? Bu nesnenin 'iş tanımının bir parçası mı?” Diye soracak. SOLID bir adım daha ileri gidiyor: "S", bir nesnenin bir işe sahip olması gerektiğini açıkça belirten ve bu belirli işi yapan programdaki tek nesne olması gerektiğini belirten "Tek Sorumluluk İlkesi" anlamına geliyor.

Dolayısıyla, GRASP genellikle bu yeni nesneleri yaratan mevcut sınıflarınıza bakmanızı ve bu nesneyi yaratma görevinin, istediğiniz "uygunluk" seviyenizi koruyarak nesnenin zaten ne yaptığına uygun olduğunu bulmanızı teşvik eder. SOLID size uyumun anahtar olduğunu söyleyecektir; Bu nesneleri yaratma görevi, sınıfınıza enjekte edilmesi gereken bazı fabrikalara verilmelidir. Programınızın karmaşıklığı artmaya devam ettikçe, bu yöntemlerden herhangi birine bağlı kalmanın, yeniden yapılandırmaya istekli olmanın, benzer mimarilere yol açacağını düşünüyorum.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.