Tüm statik yöntemleri kullanamaz mıyım?

Aşağıdaki iki UpdateSubject yöntemi arasındaki fark nedir? Sadece varlıklarla çalışmak istiyorsanız statik yöntemler kullanmanın daha iyi olduğunu hissettim. Statik olmayan yöntemlerle hangi durumlarda gitmeliyim?

public class Subject
{
    public int Id {get; set;}
    public string Name { get; set; }

    public static bool UpdateSubject(Subject subject)
    {
        //Do something and return result
        return true;
    }
    public bool UpdateSubject()
    {
        //Do something on 'this' and return result
        return true;
    }
}

Bu gerçekten sinir bozucu bir soru için topluluktan çok fazla vuruş yapacağımı biliyorum ama sormayı kendimi durduramadım.

Miras ile uğraşırken bu pratik olmaz mı?

Güncelleme:
Şimdi bizim işyerinde oluyor. 5 geliştiriciyle 6 aylık bir asp.net web uygulaması üzerinde çalışıyoruz. Mimarımız, tüm API'ler için tüm statik yöntemleri kullanmaya karar verdi. Statik yöntemler olmasının gerekçesi hafif olup, sunucu yükünü düşük tutarak web uygulamalarına yarar sağlar.

Açık bir şekilde "this" parametreleri olan statik yöntemlerin en belirgin problemlerine gideceğim:

1. Sanal gönderimi ve ardından polimorfizmi kaybedersiniz. Türetilmiş bir sınıfta bu yöntemi hiçbir zaman geçersiz kılamazsınız. Elbette türetilmiş bir sınıfta bir new( static) yöntemi tanımlayabilirsiniz, ancak erişen herhangi bir kod tüm sınıf hiyerarşisinin farkında olmalı ve açık bir kontrol ve döküm yapmalıdır, ki bu tam olarak OO'dan kaçınması gereken şeydir .

2. # 1 uzantısına göre sınıfın örneklerini bir arabirimle değiştiremezsiniz , çünkü arabirimler (çoğu dilde) staticyöntemleri bildiremez .

3. Gereksiz ayrıntı. Hangisi daha okunaklı: Subject.Update(subject)ya da sadece subject.Update()?

4. Argüman kontrolü. Yine dile bağlı, ancak birçoğu, thisbağımsız nullbir referans hatasının güvenli olmayan çalışma zamanı koşulları (türden bir arabellek taşması) oluşturmasını engellemek için argüman olmadığından emin olmak için gizli bir denetim derleyecek . Örnek yöntemleri kullanmıyorsanız, bu çeki, her yöntemin başında açıkça eklemeniz gerekir.

5. Kafa karıştırıcı. Normal, makul programcı bir gördüğünde staticyöntemi, o doğal olarak o varsaymak gidiyor gelmez (bir karşılaştırma veya eşitlik yöntemiyle gibi birden çok örneğini alır veya üzerinde işlem yapabilmek için beklenen sürece geçerli örneği gerektirir nullreferanslar) . Bu şekilde kullanılan statik yöntemleri görmek bize iki ya da üçlü bir çekim yapmamızı sağlayacak ve 4. ya da 5. zamandan sonra stresli ve öfkeli olacağız ve ev adresinizi bildiğimizde Tanrı size yardımcı olacaktır.

6. Bu bir çoğaltma şekli. Bir örnek yöntemi çağırdığınızda gerçekte olan şey, derleyici veya çalışma zamanının, türün yöntem tablosundaki yöntemi araştırması ve thisbağımsız değişken olarak kullanmaya çağırmasıdır . Temel olarak, derleyicinin zaten ne yaptığını yeniden uyguluyorsunuz. Sen ihlal ettiğinize KURU İhtiyaç olmadığında zaman farklı yöntemlerde tekrar tekrar aynı parametreyi tekrarlayarak.

Örnek yöntemleri statik yöntemlerle değiştirmek için iyi bir neden düşünmek zor . Lütfen yapma

Sadece statik yöntemlerin mevcut olduğu C'deki OOP'yi tam olarak nasıl yaptığınızı ve "this" nin bir yapı göstericisi olduğunu hemen hemen anlattınız. Ve evet, yapı sırasında bir eleman olarak depolanacak bir işlev gösterici belirterek C cinsinden çalışma zamanı polimorfizmini yapabilirsiniz. Diğer dillerde mevcut olan örnek metotlar, esasen tam olarak aynı şeyi kaputun altında yapan sözdizimsel şekerdir. Python gibi bazı diller, "self" parametresinin açıkça listelendiği yerlerin arasındadır, ancak onu çağırmak için özel bir sözdizimi kalıtım ve polimorfizmi sizin için işler.

Statik yöntemle ilgili sorun, bir alt sınıfa ihtiyaç duyduğunuz anda ortaya çıkar.

Statik yöntemler alt sınıflarda geçersiz kılınamaz, bu nedenle yeni sınıflarınız metotların yeni uygulamalarını sağlayamaz, bu da onları daha az kullanışlı yapar.

Bir yöntem bildirirseniz, yöntemi yürütmek için staticsınıftan ( newanahtar sözcük kullanarak ) bir nesneyi başlatmanız gerekmez . Bununla birlikte, statik olmadıkça, üye değişkenlere başvuramazsınız ; bu durumda, bu üye değişkenler sınıfa ait belirli bir nesneyi değil sınıfa aittir .

Başka bir ifadeyle, staticanahtar kelime, bildirimin sınıf tanımının bir parçası olmasına neden olur, bu nedenle sınıfın tüm örneklerinde (sınıftan başlatılan nesneler) tek bir referans noktası haline gelir .

Ardından, sınıfınızın birden fazla çalışan kopyası istiyorsanız ve durumun (üye değişkenleri) çalışan tüm kopyalarınız arasında paylaşılmasını istemiyorsanız (yani, her nesne kendi benzersiz durumunu tutuyorsa), o zaman izlersiniz. Bu üye değişkenlerini statik olarak ilan edemiyorum.

Genel olarak, staticsınıfları ve yöntemleri yalnızca bir veya daha fazla parametre kabul eden yardımcı yöntem oluştururken kullanmalısınız ve herhangi bir yan etki olmadan bir tür nesne döndürün (örn. Sınıftaki durum değişkenlerinde yapılan değişiklikler)

İnsanların “statik yöntemlerin kötü tasarım gösterdiğini” iddia etmelerinin sebebi, mutlaka yöntemler değil, aslında statik verilerdir, örtük veya açık. Örtük olarak, programda, dönüş değerleri veya parametrelerinde bulunmayan HERHANGİ bir durum anlamına gelir. Statik bir fonksiyonda durumun değiştirilmesi, prosedürel programlamanın bir gerilemesidir. Ancak, işlev durumu değiştirmezse veya durum değiştirmeyi bileşen nesne işlevlerine devrettiğinde, yordamdan ziyade işlevsel bir paradigma ortaya çıkar.

Durum değiştirmiyorsanız, statik yöntemlerin ve sınıfların birçok yararı olabilir. Bir yöntemin saf olduğundan ve bu nedenle yan etkilerden ve herhangi bir hatadan tamamen çoğaltılabildiğinden emin olmayı çok kolaylaştırır. Ayrıca, paylaşılan bir kütüphane kullanan birden fazla uygulamadaki farklı yöntemlerin aynı girdiyi vererek aynı sonuçları elde etmelerini sağlayarak hem hata izlemeyi hem de birim testini çok daha kolay hale getirmelerini sağlar.

Sonuçta, 'StateManager' gibi yaygın olarak görülen büyük nesneler ile statik veya global veriler arasında pratikte fark yoktur. Doğru kullanılan statik yöntemlerin faydası, yazarın durumu daha sonra revize edenlere değiştirmeme niyetini gösterebilir.

Dile ve ne yapmaya çalıştığınıza bağlı olarak, cevabı çok fazla fark olmadığı, ancak staticsürümün biraz daha fazla dağınıklığı olduğu olabilir.

Örnek sözdiziminizin Java veya C # 'yu önerdiği gibi, Thorbjørn Ravn Andersen' ın geçersiz kılma (geç bağlanma ile) sorununu belirtmekte haklı olduğunu düşünüyorum. Statik bir yöntemle, geç bağlanmanın temellendirilmesi için "özel" bir parametre yoktur, bu nedenle geç bağlanmaya sahip olamazsınız.

Aslında, statik bir yöntem, bir modülde sadece bir işlevdir, bu modül sınıfla aynı ada sahip - gerçekten bir OOP yöntemi değil.

Bunu yaparken temelde nesnelerin tüm noktasını yeniyorsun. Prosedürel koddan nesne yönelimli koda geçiş yapmamızın iyi bir nedeni var.

Ben ediyorum ASLA bir parametre olarak sınıf türünü aldı statik bir yöntem bildirmek. Bu sadece kazancı olmayan kodları daha karmaşık hale getirir.

Burada bir sürü harika cevap var ve onlar bir cevap olarak bulabileceğim herhangi bir şeyden çok daha anlayışlı ve bilgili, ama adress edilmeyen küçük bir şey olduğunu hissediyorum:

"Mimarımız, tüm API'ler için tüm statik yöntemleri kullanmaya karar verdi. Statik olmasının gerekçesi hafif ve sunucu uygulamalarını düşük tutarak web uygulamalarına fayda sağlıyor ."

(kalın vurgu benimdir)

Sorunun bu bölümünde benim 2c bu:

Teorik olarak söylenen doğru olanı: Statik bir metot çağırmak, aslında bu metodu çağırmak için yeterli olmaz. Statik olmayan (örnek) bir yöntem çağırmak, ilk önce nesneyi somutlaştırmanın ek yükünü ve bir noktada örneği yok etmeyi sağlar (manuel olarak veya kullanılan platforma bağlı olarak otomatik çöp toplama biçimi aracılığıyla).

Oyun biraz şeytanın savunucusu: Bu daha ileri gidebiliriz ve şöyle şeyler söyleyebiliriz:

• (örnek) yönteminin her çağrılması için bir örnek oluşturulduğunda bu gerçekten kötü hale gelebilir (yalnızca durağan bırakmak ve buna benzer şekilde adlandırmak yerine)

• Yapıcının karmaşıklığına, tip hiyerarşisine, diğer örnek üyelere ve diğer bilinmeyen faktörlere bağlı olarak, statik olmayan yöntem çağrısının ek yükü değişebilir ve gerçekten büyük olabilir

Gerçekte, IMHO, yukarıdaki hususlar (ve “daha ​​hızlı oldukları için statik kullanalım.” Genel yaklaşımı) saman adam argümanları / değerlendirmeleri:

• eğer kod iyi ise ve bu argümana daha özelse, örnekler yalnızca gerektiğinde oluşturulduysa (ve optimal bir şekilde imha edildiyse), uygun olduğunda delirik yöntemler kullanmaya fazladan bir ek yük alamazsınız (çünkü sadece ihtiyaç duyulan nesneleri yarat, bu yöntem statik olarak ilan edilse bile yaratılmış olacaktı;

• Statik yöntemler bildirimini bu şekilde kötüye kullanarak, örneklerin nasıl oluşturulduğuna ilişkin olarak kodunuzla ilgili bazı sorunları gizlemek mümkündür (yöntem statik olduğundan, yanlış bir deneme kodu daha sonra farkedilmeden geçebilir ve bu asla iyi olmaz).

Bu, sormakta olduğunuz topluluğa bağlı olarak çok farklı cevaplar alma eğiliminde olan çok ilginç bir sorudur. Diğer cevaplar C # veya java önyargısı gibi görünmektedir: (çoğunlukla) saf nesne yönelimli ve nesne yöneliminin ne olduğuna dair bir tür deyimsel bakış açısına sahip bir programlama dili.

C ++ gibi diğer topluluklarda, nesne yönelimi daha serbest bir şekilde yorumlanmaktadır. Bazıları uzmanların konuyu araştırdıklarını ve aslında, serbest işlevlerin kapsüllemeyi iyileştirdiği sonucuna vardıklarını bilir (vurgu benimdir):

Bir sınıftaki kapsülleme miktarını ölçmenin makul bir yolunun, sınıfın uygulaması değiştiğinde kırılabilecek fonksiyonların sayısını saymak olduğunu gördük. Bu durumda, n üye işlevli bir sınıfın, n + 1 üye işlevli bir sınıftan daha kapsüllenmiş olduğu anlaşılmaktadır. Ve bu gözlem, üye olmayan arkadaş olmayan işlevleri üye işlevlerine tercih etme argümanımı haklı çıkarıyor.

Scott Meyers

C ++ terminolojisine aşina olmayanlar için:

• üye işlevi = yöntem
• üye olmayan işlev = statik yöntem
• arkadaş olmayan = yalnızca herkese açık API kullan
• üye olmayan arkadaş olmayan işlev = yalnızca genel API kullanan statik yöntem

Şimdi, size soruyu cevaplamak için:

Tüm statik yöntemleri kullanamaz mıyım?

Hayır, her zaman statik yöntemler kullanmamalısınız.

Ancak, yalnızca bir sınıfın genel API'sini kullanmanız gerektiğinde bunları kullanmalısınız .

Java’da ...

Statik yöntemlerin üzerine yazılmaz, bunun yerine gizlenir ve bu nedenle sınıfı genişletme durumunda büyük bir fark olur (sorun?).

Diğer taraftan, Java programcılarının gerçekten nedenini anlamadan, nesnenin KADAR OLMALI olduğunu düşünme eğiliminde olduğunu fark ettim ve katılmıyorum.

Statik sınıfa özel kod için kullanılmalıdır. Statik miras ile iyi çalışmıyor.

statik yöntemlerin kullanımına ilişkin bazı iyi örnekler, yan etkisi olmayan bağımsız işlevlerdir.

Ayrıca, senkronize edilmiş anahtar kelimeyi de görün ...