Çoğunlukla statik sınıfları kullanarak rüzgar için Tamam mı?

6 Cevap php

CMS çoğunlukla inceliğini kalır yani, ama sadece istemci tarafı - Şu anda bir e-shop yeniden yazıyorum. Sistem CMS ile geriye dönük uyumluluğu korumak için olduğu gibi ben, bir pre-built çerçevesini kullanarak değilim ve ben kod yapısının tam özgürlük olması gerekir.

Yeni sistem tamamen MVC tabanlı ve güncel uri ve gerçek iş için son kullanım modellerine dayanan denetleyicileri yükleyen bir Önyükleyicisi var olduğunu - oturumları ve veritabanı ile hem.

tl;dr Bu bir ön-inşa çerçeve olmadan benim ilk projem.

Bu desen tasarımı geldiğinde ben çok tecrübesiz değilim. Ben nasıl popüler olanlar çoğu işe biliyorum ama kullanmak için onları koymak hiç var.

Benim modellerin her statik yöntemler tamamen oluşur sınıfları çünkü Şimdi ben kod kokuyor şüphelenen. Ben farklı bir şekilde bunları yaparken hiç avantajları bulabilirsiniz. Ben rutin kod boyunca çeşitli yerlerde yöntemlerden bazılarını gerekir. Yani Ben kontrolör tarafından, ana düzeninde kullanıcı oturum açmış getirme bootstraper Geçerli sayfayı görmek için kullanıcı haklarını kontrol, ekran kullanıcı paneli gerekir. Ben yeniden örneğini bir nesne her zaman gerekiyor veya statik kullanılarak değildi eğer küresel bir tutmak istiyorum. Ayrıca, aynı anda birden fazla böyle bir sınıf için bir ihtiyaç söz konusu değildir.

Ben OOP kullanmak bile, bazıları benim sınıflar sadece anlamsız yöntemleri için konteynerler (ve bazen özel değişkenlerin bir çift) çünkü ben, bir şey eksik gerekir. Ben sadece PHP4 ve basit fonksiyonlarını kullanarak olabilirdi.

Herhangi bir yorum veya öneri son derece mutluluk duyacağız.

EDIT: Bunca eğitimli cevapları rağmen, ben ikna kalır. Çünkü deneyimi benim eksikliği çoğu muhtemelen rağmen, ben hala bir şey mevcut kurulum ile yanlış gidiyor görmüyorum. Ben bile şimdi olduğu gibi kod mimarisi nedeniyle herhangi bir sakıncaya olurdu bir durum anlamak yok demek. Bir şey değiştirmek için çok geç olduğunda ben sert bir ders alamadım umarım ...

6 Cevap

Haklısınız, bu bir kod koku ve herkes baaaad size söyleyecektir.

Yani burada ben bir self-assessment sorunun şiddetine yapmak oldukça öneririm:

  • Eğer birçok sınıfları var mı getter and setter?

  • Mısınız static functions aşağıdaki gibi?

    Eğer evet ise, zaten yol daha OO olacağını MyClass sınıfında mantığı taşımak deneyin. Bu usul / scripting dünyasından klasik bir hata.


 static void myMethod( MyClass anObject )
 {
     // get value from anObject
     // do some business logic
     // set value of anObject
 }

  • Böyle geçerli oturumdan almak veri olarak, global state bir şey var mı?

    Eğer evet ise, bunu değiştirmek isteyip istemediğinizi bir değerlendirme yapmak. OO yolu çağrı zinciri aşağı oturumu geçmek olacaktır. Fakat pratikte, küresel bir nesne olarak oturumu erişmek için uygundur. Ama edilebilirliğini engellemektedir. Bazı küresel durumu kaldırmak ve geçmek ve yöntemleri işlemek düzenli nesne içine açmak için çalışın.

Bu değerlendirmeyi yapmak, ve utility sınıfları, services sınıfları ve business objects belirlemeye çalışın. Utility sınıfı statik olabilir yardımcı yöntemler (örneğin biçimlendirme, dönüştürme, vb) ile yardımcı sınıflardır. Hizmet sınıfı bazı iş mantığı yapmak ama vatansız ve bir örneği kâfi olmalıdır. İş nesneleri sizin çaba konsantre gerekir nerede, vb user, products, article vardır. Embed bazı davranış ile nesnelerin içine düz verileri açmak için çalışın.

should entity be dumb bakabilirsiniz. Bu java için olsa bile, kavramlar geneldir.

EDIT

İşte Yorumlarınız dayanarak benim analizi:

  • Sen kuruluşlar ile bir etki alanı modeli yok. Doğrudan veritabanına işlemek.
  • Eğer modeli dediğimiz, ben services diyoruz ve veri işlemek iş mantığını gerçekleştirmek nerede. Hizmet sınıfları doğru olan stateless vardır. Eğer soru işaret ettiği gibi, daha sonra da sürekli onları yeniden oluşturmak bir küresel örneğini oluşturmak, ya da statik yöntemler kullanmak gerekir.

OO paradigma Eğer varlıklar ile veritabanı Haritayı etki modeli için denemek gerektiğini söyleyebilirim. En azından bir anemic domain model kişiler / veritabanında kalıcı yüklenen donuk veri konteyner nerede var. Ardından OO paradigma da mümkünse kişilerin mantık biraz koymak söyleyebilirim.

Ayrıca, kompozisyon ve yeniden kullanımını kolaylaştıracak nesneleri içine hizmetlerini açmak için söyleyebilirim. Bu böyleydi Eğer örneğin / durdurma işlemleri başlatmak veya statik yöntemleri ile yapmak mümkün olmayacaktır bazı güvenlik denetimini yapmak için bir dinleyici olan tüm hizmetleri sarın.

Eğer tarif ne (hiçbir kişiler + vatansız usul hizmetleri) büyük bir OO tasarım kabul edilmez. Ben en azından bir anemik etki modelini tanıtmak ve DAO öneririm. Sateless usul hizmetleri ile ilgili olarak, bu aslında birçok web uygulamalarının gerçek - daha fazla ihtiyacım yok, bunu sopa olabilir.

Benim 2 sent

Eğer statik sınıfları kullanarak ağırlıklı olarak sadece o zaman gerçekten nesne yönelimli programlama dışarı nesneyi dışarı attık. Ben senin sistem OOP yaramak gerektiğini belki söylüyorum, yanlış şeyler yapıyorsun demiyorum. Belki (vb, e-posta gönderir) bazı temel yarar fonksiyonları gerektiren basit bir uygulama. Bu durumda, kod en çok prosedürel olur.

Veritabanları ile ilgili iseniz statik db sınıfı ve basit bir iş katmanı olabilir, ve php app sırayla veritabanı katmanı ile etkileşime iş katmanı ile etkileşime girer. Bu, tipik 3-katmanlı mimari (bazı insanlar 4 t-iers olarak bakın ve veri katmanı, aynı şey gelen gerçek bir veritabanı ayırmak gibi) olur.

Gerçekten ne kendinize sormak için sadece bir soru, bu statik sınıfların tüm nokta daha bir nesne gerektirmeyen yöntemler arayarak değilseniz.

Görebileceğiniz bir şey olduğunu size muhtemelen statik sınıflar ve yöntemler alay etmek kolay değildir çünkü zor bir zaman var olacak stubbing / alaycı birim test her türlü yapmayı planlıyorsanız, saplama ya da test.

Ben web uygulamaları statik değişkenler ve sınıflarını kullanma hakkında dikkatli olacaktır. Eğer gerçekten kullanıcılar arasındaki bir örneğini paylaşmak gerekir, o zaman tek bir örneği (arama "Singleton" tasarım deseni) var ok olmalıdır.

Ancak, sayfalar arasında durumunu korumak için çalışırken, sen ViewState kullanarak aracılığıyla veya Session nesnesi kullanarak yapmalıdır.

Eğer global bir statik değişkeni var olsaydı, eşzamanlı kullanıcılar aynı değeri güncelleştirmek için savaşan bir durum olabilir.

Kısa cevap: Tamam ama sen OOP faydaları yukarıdaki vardır.

Nesneleri kullanarak arkasında bir mantık çoğu zaman bir rol yapar nesnenin birden fazla türü olmasıdır. Örneğin aynı arayüze sahip bir DBVendor2 veri erişim nesnesi ile DBVendor1 veri erişim nesnesi takas edebilirsiniz. Bu, özellikle kullanışlı Ünite testleri kullanarak ve kukla nesneleri (mocks ve taslakları) ile gerçek bir iş yapmak nesneleri takas gerekir eğer. Birbirine uygun ve kolayca değiştirilebilir farklı renklerle Lego tuğla gibi aynı arayüzü ile nesnelerin düşünün. Ve sadece statik nesneler ile bunu yapamazsınız.

Tabii ki, nesnelerin artan esneklik bir fiyata geliyor: nesnelerin başlatma ve birlikte koyarak daha fazla iş (yazdığın gibi) ve daha fazla kod ve diğer nesneleri bir araya nesnelere yol açar. builder ve benzeri yaradılış tasarım desenleri factory devreye girer yerdir.

Eğer bu yolu gitmek istiyorsanız, ben size dependency injection ve DI framework kullanma hakkında okumanızı tavsiye ederiz.

Teknik bunu yaparken yanlış bir şey yok. Ama pratikte nesne yönelimli programlama yarar yeri kaybediyor. Ayrıca örneğin .. ait kodu / işlevselliği yazmak:

 user.doSomeTask()

kullanıcı nesnesi daha mantıklı daha kolaylaştırır üzerinde

 UserUtils.doSomeTask(User user)

Eğer aittir ve gelecekte daha kolay statik yöntemleri kullanarak daha işlevselliğini genişletmek, kodunuzu değiştirmek yardımcı olur işlevselliğini OOP kavramları soyut kullanma.