ServiceLocator ve Açık / Kapalı Prensibi

2 Cevap php

Ben isterim:

  1. Onlara ihtiyacımız tüm sınıflar için görünür yaygın gerekli hizmetleri yapmak,
  2. Bir Demirbaş minimum ve ile
  3. edilebilirliğini ödün vermeden!

Bu küçük bir proje var ve ben DI overkill olabileceğini düşünüyorum, ama belki yanılıyorum? Her neyse, ben ServiceLocator pattern as described by Martin Fowler üzerinde yoğunlaştık

Bir istemci sınıf 'kurucu olarak, böyle bir şey var:

this->db = Locator::getDb();
this->log = Locator::getLogger();

Sonra sınıf 'yöntemler kalanı, bu üye nitelikleri aracılığıyla örneğin hizmete erişmek:

this->fooModel = new fooModel(this->db);
fooItem1234 = this->fooModel->findById(1234);

Ancak onlar birkaç farklı yerlerden erişilen çünkü ben de (yukarıda fooModel gibi) "model" nesneler için görünürlük bu düzeyde istiyorum ve birden fazla örneği olması için gerek yoktur.

Yani benim ilk düşünce bir ::getFooModel() var Locator uzatmak oldu ama şimdi ben Locator ben yeni bir model sınıfını tanıtmak her zaman değiştirmek zorunda olacak çünkü ben, Açık / Kapalı prensibi ihlal ediyorum görünüyor.

OCP karşılamak için, ben yeterince açık değil yani ancak ben tamamen, onun gibi aynı nedenlerle bu satılan değilim (aynı zamanda Fowler sayfasında açıklanan) Dinamik Hizmet Locator kullanabilirsiniz.

Başka bir çözüm sadece tüm modeller 'yöntemleri statik yapmak olacaktır. Yani:

fooItem1234 = FooModel::findById(1234);

Sıfır klişe çünkü ben beğendim. Ben sadece yeni bir model sınıfı oluşturmak ve tek bir çizgi ile her yerden çağrı başlatabilirsiniz. Ama şimdi modeli DB bağlantısını bulmak için Belirleme bağlıdır ve ben bu konuda hissediyorum nasıl emin değilim. Şimdiye kadar ayrı veritabanı bağlantıları açık iki fooModels için gerekli eğer biri için, bir karışıklık ve / veya imkansız olurdu. O dedi, ben aslında şu anda bu seçenek biraz cazip görünüyor yapmak gerekmez.

Son olarak, DI var. Ama dediğim gibi ben bu küçük proje için çok fazla olabileceğini düşünüyorum yukarıda söyledi.

Sonuç: Ben burada takılıp biraz kulüpler ve StackOverflow uzmanları bazı tavsiye seviniriz!

2 Cevap

Neden DI projeniz için overkill olduğunu düşünüyorsunuz? Böyle Constructor Injection olarak DI desenler Hizmet Locator (Ben bir anti-desen düşünün ki) daha yolu basit ve temiz.

Bunun bağımlılık yerinde olması gerekir API kullanıcıya tamamen opak beri ben Hizmeti Locator bir anti-desen olarak düşünün; Böylece, kolayca Hizmet Belirleme atmak istiyorsunuz bağlamında nesneler üzerinde yöntemlerini çağırmak olabilir ve API bu durumda kesinlikle hiçbir ipucu verir.

Sen DI kullanmak için DI Kabı gerekmez. Sadece basit bir proje varsa, Poor Man's DI elle bağımlılıkları kadar tel nerede olarak bilinen kullanabilirsiniz.

... Ve birden fazla örneği için hiçbir gerek yoktur.

Sen elma ve portakal karıştırma ediyoruz. Eğer sadece bir uygulama için bir sınıfın bir örneğini ihtiyaç olması, bu örnek dünyada kullanılabilir hale getirmek için iyi bir fikir olarak aynı şey değildir. DI ile önem düzeyi değişiklik yok - sadece bir örnek hala var. Ne değiştirmek adres örneği olduğunu söyledi değişkenlerin kapsamı. Bir fark var.