Bir PHP projesinde, yardımcı nesneleri depolamak, bunlara erişmek ve bunları organize etmek için hangi modeller vardır? [kapalı]

PHP tabanlı, nesne yönelimli bir projede veritabanı motoru, kullanıcı bildirimi, hata işleme gibi yardımcı nesneleri nasıl düzenler ve yönetirsiniz?

Büyük bir PHP CMS'im olduğunu varsayalım. CMS, çeşitli sınıflarda düzenlenmiştir. Birkaç örnek:

• veritabanı nesnesi
• Kullanıcı yönetimi
• öğeleri oluşturmak / değiştirmek / silmek için bir API
• son kullanıcıya mesajları görüntülemek için bir mesajlaşma nesnesi
• sizi doğru sayfaya götüren bir bağlam işleyici
• düğmeleri gösteren bir gezinme çubuğu sınıfı
• bir günlük nesnesi
• muhtemelen, özel hata işleme

vb.

Sonsuz soruyla uğraşıyorum, bu nesneleri ihtiyaç duyan sistemin her parçası için en iyi şekilde nasıl erişilebilir kılacağım.

Yıllar önce ilk yaklaşımım, bu sınıfların başlatılmış örneklerini içeren global bir $ uygulamasına sahip olmaktı.

global $application;
$application->messageHandler->addMessage("Item successfully inserted");

Daha sonra Singleton modeline ve bir fabrika işlevine geçtim:

$mh =&factory("messageHandler");
$mh->addMessage("Item successfully inserted");

ama bundan da memnun değilim. Birim testleri ve kapsülleme benim için gittikçe daha önemli hale geliyor ve anladığım kadarıyla küresellerin / tekillerin arkasındaki mantık temel OOP fikrini yok ediyor.

O zaman elbette her bir nesneye ihtiyaç duyduğu yardımcı nesnelere bir dizi işaretçi verme olasılığı vardır, muhtemelen en temiz, kaynak tasarrufu sağlayan ve test etmeye uygun yol, ancak bunun uzun vadede sürdürülebilirliği konusunda şüphelerim var.

Baktığım çoğu PHP çerçevesi, ya tekli kalıbı ya da başlatılmış nesnelere erişen işlevleri kullanmayı araştırdı. İkisi de iyi yaklaşımlar, ama dediğim gibi ikisinden de memnun değilim.

Burada hangi ortak modellerin var olduğuna dair ufkumu genişletmek istiyorum. Bunu uzun vadeli , gerçek dünya perspektifinden tartışan kaynaklara yönelik örnekler, ek fikirler ve işaretler arıyorum .

Ayrıca, konuya özel, niş veya düpedüz tuhaf yaklaşımlar hakkında bilgi almakla ilgileniyorum .

Flavius ​​tarafından önerilen Singleton yaklaşımından kaçınırdım. Bu yaklaşımdan kaçınmak için çok sayıda neden vardır. İyi OOP ilkelerini ihlal ediyor. Google test blogu, Singleton ve bundan nasıl kaçınılacağı hakkında bazı iyi makaleler içeriyor:

http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html http://googletesting.blogspot.com/2008/05/tott-using-dependancy -injection-to.html http://googletesting.blogspot.com/2008/08/where-have-all-singletons-gone.html

Alternatifler

1. bir servis sağlayıcı

   http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html

2. bağımlılık ekleme

   http://en.wikipedia.org/wiki/Dependency_injection

   ve bir php açıklaması:

   http://components.symfony-project.org/dependency-injection/trunk/book/01-Dependency-Injection

Bu, bu alternatifler hakkında güzel bir makale:

http://martinfowler.com/articles/injection.html

Bağımlılık ekleme (DI) uygulama:

• Yapıcıda nesnenin çalışması için neye ihtiyaç duyulduğunu sormanız gerektiğine inanıyorum :new YourObject($dependencyA, $dependencyB);

• Gerekli nesneleri (bağımlılıkları) manuel olarak sağlayabilirsiniz ( $application = new Application(new MessageHandler()). Ancak bir DI çerçevesi de kullanabilirsiniz (wikipedia sayfası, PHP DI çerçevelerine bağlantılar sağlar ).

  Önemli olan, diğer nesnelere ihtiyaç duydukları için yalnızca gerçekte kullandığınız şeyi iletirsiniz (bir eylem çağırırsınız). İşte 'Bob amca'dan (Robert Martin), manuel DI ile çerçeve kullanma arasındaki ilişkiyi tartışan son bir gönderi .

Flavius'un çözümü hakkında biraz daha düşünce. Bu gönderinin bir anti-posta olmasını istemiyorum, ancak bağımlılık enjeksiyonunun neden en azından benim için küresellerden daha iyi olduğunu görmenin önemli olduğunu düşünüyorum.

'Gerçek' bir Singleton uygulaması olmasa da, yine de Flavius'un yanlış anladığını düşünüyorum. Küresel durum kötü . Bu tür çözümlerin statik yöntemleri test etmesi zor olduğunu unutmayın .

Birçok insanın bunu yaptığını, onayladığını ve kullandığını biliyorum. Ancak Misko Heverys blog makalelerini ( bir google test edilebilirlik uzmanı ) okumak , yeniden okumak ve söylediklerini yavaşça sindirmek tasarıma bakışımı çok değiştirdi.

Uygulamanızı test edebilmek istiyorsanız, uygulamanızı tasarlamak için farklı bir yaklaşım benimsemeniz gerekir. Önce test programlaması yaptığınızda, aşağıdaki gibi şeylerde zorluk yaşarsınız: 'Şimdi bu kod parçasına günlük kaydı uygulamak istiyorum; Önce temel bir mesajı kaydeden bir test yazalım 've ardından sizi değiştirilemeyen global bir kaydedici yazmaya ve kullanmaya zorlayan bir test oluşturalım.

Hala o blogdan aldığım tüm bilgilerle mücadele ediyorum ve uygulanması her zaman kolay olmuyor ve birçok sorum var. Ama Misko Hevery'nin söylediklerini kavradıktan sonra daha önce yaptığım şeye (evet, küresel durum ve Singletons (büyük S)) geri dönmem mümkün değil :-)

class Application {
    protected static $_singletonFoo=NULL;

    public static function foo() {
        if(NULL === self::$_singletonFoo) {
            self::$_singletonFoo = new Foo;
        }
        return self::$_singletonFoo;
    }

}

Ben böyle yaparım. Nesneyi talep üzerine oluşturur:

Application::foo()->bar();

Benim bunu yapma şeklim bu, OOP ilkelerine saygı duyuyor, şu anda yaptığınızdan daha az kod ve nesne yalnızca kod ilk kez ihtiyaç duyduğunda yaratılıyor.

Not : Sunduğum şey gerçek bir tekil kalıp bile değil. Bir singleton, yapıcıyı (Foo :: __ constructor ()) özel olarak tanımlayarak kendisinin yalnızca bir örneğine izin verir. Bu, tüm "Uygulama" örneklerinde kullanılabilen yalnızca "genel" bir değişkendir. Bu nedenle, iyi OOP ilkelerini göz ardı etmediği için kullanımının geçerli olduğunu düşünüyorum. Tabii ki, dünyadaki herhangi bir şey gibi, bu "kalıp" da aşırı kullanılmamalıdır!

Bunun birçok PHP çerçevesinde, aralarında Zend Framework ve Yii'de kullanıldığını gördüm. Ve bir çerçeve kullanmalısınız. Size hangisi olduğunu söylemeyeceğim.

Eklenti Aranızda TDD hakkında endişelenenler için , yine de onu bağımlılık enjekte etmek için bazı kablolama yapabilirsiniz. Şöyle görünebilir:

class Application {
        protected static $_singletonFoo=NULL;
        protected static $_helperName = 'Foo';

        public static function setDefaultHelperName($helperName='Foo') {
                if(is_string($helperName)) {
                        self::$_helperName = $helperName;
                }
                elseif(is_object($helperName)) {
                        self::$_singletonFoo = $helperName;
                }
                else {
                        return FALSE;
                }
                return TRUE;
        }
        public static function foo() {
                if(NULL === self::$_singletonFoo) {
                        self::$_singletonFoo = new self::$_helperName;
                }
                return self::$_singletonFoo;
        }
}

İyileştirme için yeterince yer var. Bu sadece bir PoC, hayal gücünüzü kullanın.

Neden böyle yapıyorsun? Pekala, uygulama çoğu zaman birim testine tabi tutulmayacak, umarız bir üretim ortamında çalıştırılacaktır . PHP'nin gücü hızıdır. PHP DEĞİLDİR ve asla Java gibi "temiz bir OOP dili" olmayacaktır.

Bir uygulama içinde, yalnızca bir Uygulama sınıfı ve yardımcılarının her birinin yalnızca bir örneği vardır (yukarıdaki gibi yavaş yüklemeye göre). Elbette, singletonlar kötüdür, ama yine de, sadece gerçek dünyaya bağlı kalmazlarsa. Benim örneğimde yapıyorlar.

"Tek tonlar kötüdür" gibi kalıplaşmış "kurallar" kötülüğün kaynağıdır, kendileri için düşünmeye istekli olmayan tembel insanlar içindir.

Evet, biliyorum, PHP manifestosu teknik olarak KÖTÜ. Yine de hile tarzında başarılı bir dil.

ek

Bir işlev stili:

function app($class) {
    static $refs = array();

    //> Dependency injection in case of unit test
    if (is_object($class)) {
        $refs[get_class($class)] = $class;
        $class = get_class($class);
    }

    if (!isset($refs[$class]))
        $refs[$class] = new $class();

    return $refs[$class];
}

//> usage: app('Logger')->doWhatever();

Bağımlılık Enjeksiyonu kavramını beğendim:

"Bağımlılık Enjeksiyonu, bileşenlerin bağımlılıklarının oluşturucuları, yöntemleri veya doğrudan alanlara verildiği yerdir. ( Pico Container Web Sitesinden )"

Fabien Potencier, Dependency Injection ve bunları kullanma ihtiyacı hakkında gerçekten güzel bir makale dizisi yazdı . Ayrıca , kullanmayı çok sevdiğim Pimple adında güzel ve küçük bir Bağımlılık Enjeksiyon Kabı sunuyor ( github hakkında daha fazla bilgi ).

Yukarıda belirtildiği gibi, Tekil kullanımından hoşlanmıyorum. Singleton'ların neden iyi bir tasarım olmadığına dair iyi bir özet burada Steve Yegge'in blogunda bulunabilir .

En iyi yaklaşım, bu kaynaklar için bir tür konteynere sahip olmaktır . Bu kapsayıcıyı uygulamanın en yaygın yollarından bazıları :

Singleton

Test edilmesi zor olduğu ve küresel bir durumu ifade ettiği için önerilmez. (Singletonitis)

Kayıt

Tektoniti ortadan kaldırır, hata kaydını da önermem çünkü bu da bir tür singleton. (Birim testi zor)

miras

Yazık ki, PHP'de çoklu kalıtım yoktur, bu yüzden bu hepsini zincirle sınırlar.

Bağımlılık enjeksiyonu

Bu daha iyi bir yaklaşım ama daha büyük bir konu.

Geleneksel

Bunu yapmanın en basit yolu yapıcı veya ayarlayıcı enjeksiyonu kullanmaktır (bağımlılık nesnesini ayarlayıcı kullanarak veya sınıf yapıcısında geçirin).

çerçeveler

Kendi bağımlılık enjektörünüzü veya bazı bağımlılık enjeksiyon çerçevelerini kullanabilirsiniz, örn. yadif

Uygulama kaynağı

Kaynaklarınızın her birini uygulama önyüklemesinde (bir kapsayıcı görevi gören) başlatabilir ve önyükleme nesnesine erişen uygulamanın herhangi bir yerinde bunlara erişebilirsiniz.

Zend Framework 1.x'te uygulanan yaklaşım budur

Kaynak yükleyici

İhtiyaç duyulan kaynağı yalnızca gerektiğinde yükleyen (oluşturan) bir tür statik nesne. Bu çok akıllıca bir yaklaşım. Bunu eylemde görebilirsiniz, örneğin Symfony's Dependency Injection bileşenini uygularken

Belirli katmana enjeksiyon

Kaynaklara uygulamanın herhangi bir yerinde her zaman ihtiyaç duyulmaz. Bazen bunlara, örneğin kontrolörlerde (MV C ) ihtiyaç duyarsınız . O zaman kaynakları sadece oraya enjekte edebilirsiniz.

Buna genel yaklaşım, enjeksiyon meta verilerini eklemek için docblock açıklamalarını kullanmaktır.

Bu konudaki yaklaşımımı burada görün:

Zend Framework'te bağımlılık enjeksiyonu nasıl kullanılır? - Yığın Taşması

Sonunda, burada çok önemli bir şey hakkında bir not eklemek istiyorum - önbelleğe alma.
Genel olarak, seçtiğiniz tekniğe rağmen, kaynakların nasıl önbelleğe alınacağını düşünmelisiniz. Önbellek, kaynağın kendisi olacaktır.

Uygulamalar çok büyük olabilir ve tüm kaynakları her istek üzerine yüklemek çok pahalıdır. Bu php uygulama sunucusu - Google Code'da Proje Barındırma dahil olmak üzere birçok yaklaşım vardır .

Nesneleri küresel olarak kullanılabilir yapmak istiyorsanız, kayıt defteri kalıbı sizin için ilginç olabilir. İlham almak için Zend Registry'ye bir göz atın .

Aynı zamanda Tescil ve Singleton sorusu.

PHP'deki nesneler, muhtemelen birim testlerinizden de gördüğünüz gibi, iyi miktarda bellek kaplar. Bu nedenle, diğer işlemler için bellek tasarrufu sağlamak için ihtiyaç duyulmayan nesneleri mümkün olan en kısa sürede yok etmek idealdir . Bunu aklımda tutarak her nesnenin iki kalıptan birine uyduğunu görüyorum.

1) Nesnenin birçok yararlı yöntemi olabilir veya birden fazla çağrılması gerekebilir, bu durumda bir singleton / kayıt defteri uygularım:

$object = load::singleton('classname');
//or
$object = classname::instance(); // which sets self::$instance = $this

2) Nesne yalnızca, onu çağıran yöntem / işlevin ömrü boyunca var olur; bu durumda, kalan nesne referanslarının nesneleri çok uzun süre canlı tutmasını önlemek için basit bir oluşturma yararlıdır.

$object = new Class();

Geçici nesneleri HER YERDE depolamak bellek sızıntılarına neden olabilir çünkü bunlara yapılan başvurular, nesneyi betiğin geri kalanı için bellekte tutma konusunda unutulabilir.

Başlatılmış nesneleri döndüren işlev için giderdim:

A('Users')->getCurrentUser();

Test ortamında, maketler döndürmek için tanımlayabilirsiniz. Hatta debug_backtrace () kullanarak işlevi kimin çağırdığını tespit edebilir ve farklı nesneler döndürebilirsiniz. Programınızda gerçekte neler olup bittiğini anlamak için hangi nesnelere sahip olmak isteyenlerin içine kayıt olabilirsiniz.

Neden iyi kılavuzu okumuyorsunuz?

http://php.net/manual/en/language.oop5.autoload.php