Statik yöntemler neden geçersiz kılınmamalıdır?

Bu sorunun cevabında genel fikir birliği, statik yöntemlerin geçersiz kılınmayacağı yönündeydi (ve bu nedenle C # 'daki statik fonksiyonlar sanal veya soyut olamaz). Yine de bu sadece C # 'da değildir; Java da bunu yasaklıyor ve C ++ da hoşuna gitmiyor. Ancak, bir alt sınıfta geçersiz kılmak istediğim birçok statik işlev örneğini düşünebilirim (örneğin, fabrika yöntemleri). Teoride, etraflarında dolaşmanın yolları olsa da, hiçbiri temiz veya basit değildir.

Statik fonksiyonlar neden geçersiz kılınmamalıdır?

Statik yöntemlerle, geçersiz kılma mekanizmasının uygun kontrolünü sağlamak için hiçbir nesne yoktur.

Normal sınıf / örnek sanal yöntem mekanizması, geçersiz kılmaların hassas şekilde ayarlanmasına aşağıdaki gibi izin verir: her gerçek nesne tam olarak bir sınıfın örneğidir. Bu sınıf geçersiz kılmaların davranışını belirler; sanal yöntemlerde her zaman ilk çatlağı alır. Daha sonra uygulanması için ana yöntemi doğru zamanda çağırmayı seçebilir. Daha sonra her bir üst yöntem, üst yöntemini çağırmak için sıra alır. Bu, nesne yöneliminin bilindiği kodun yeniden kullanılma kavramlarından birini gerçekleştiren hoş bir üst düzey çağırmalarla sonuçlanır. (Burada temel / süper sınıfların kodu nispeten karmaşık bir şekilde yeniden kullanılıyor; OOP'ta başka bir dikey kod yeniden kullanımı kavramı, aynı sınıfın birden çok nesnesine sahip olmaktır.)

Temel sınıflar çeşitli alt sınıflar tarafından yeniden kullanılabilir ve her biri rahatça bir arada bulunabilir. Kendi davranışlarını dikte eden nesneleri, barışçıl ve eşzamanlı olarak diğerleriyle birlikte varolan nesneleri somutlaştırmak için kullanılan her sınıf. İstemci, hangi davranışları istediğini ve bir nesneyi örneklemek ve istendiği gibi başkalarına iletmek için hangi sınıfı kullanacağını seçerek kontrol eder.

(Bu mükemmel bir mekanizma değildir, elbette desteklenmeyen yetenekleri her zaman tanımlayabilir, bu yüzden fabrika yöntemi ve bağımlılık enjeksiyonu gibi desenler üstte katmanlıdır.)

Yani, başka bir şey değiştirmeden statik için bir geçersiz kılma yeteneği yapacak olsaydık, geçersiz kılmaları sipariş etmekte zorluk çekerdik. Geçersiz kılmanın uygulanabilirliği için sınırlı bir bağlam tanımlamak zor olacaktır, bu nedenle geçersiz kılmayı nesnelerde olduğu gibi yerel olarak değil küresel olarak elde edersiniz. Davranışı değiştirecek örnek nesne yok. Birisi, başka bir sınıf tarafından geçersiz kılınmış olan statik yöntemi çağırdıysa, geçersiz kılma kontrol altına almalı mı değil mi? Bu tür birden çok geçersiz kılma varsa, önce kontrolü kim alır? ikinci? Örneğin nesne geçersiz kılmalarıyla, bu soruların hepsinin anlamlı ve iyi gerekçeli cevapları vardır, ancak statik ile yoktur.

Statik için geçersiz kılmalar büyük ölçüde kaotik olurdu ve bunun gibi şeyler daha önce yapılmıştı.

Örneğin, Mac OS System 7 ve önceki sürümlerde, işletim sisteminden önce uygulama tarafından yapılan sistem çağrılarının kontrolünü alarak sistemi genişletmek için bir tuzak yama mekanizması kullanılmıştır. Sistem çağrısı yama tablosunu, tek bir genel tablo olması dışında, örneğin nesneler için bir vtable gibi bir işlev işaretçileri dizisi olarak düşünebilirsiniz .

Bu, tuzak yamalarının düzensiz doğası nedeniyle programcılar için anlatılmamış kedere neden oldu. Kim tuzağa düşürmek isterse, temelde kazandı, istemeseler bile. Tuzağın her bir kullanıcısı, son derece kırılgan olan bir tür üst çağrı yeteneği için önceki tuzak değerini yakalayacaktır. Bir tuzak yamasını kaldırmak, bir sistem çağrısı hakkında artık bilgi sahibi olmanız gerekmediğinde, yamanızın gerçekten kaldırılması için gerekli bilgilere sahip olmadığınız için kötü bir form olarak kabul edildiğini söyleyin (eğer yaptıysanız, takip eden diğer yamaları da kaldıracaksınız) sen).

Bu, statiklerin geçersiz kılınması için bir mekanizma oluşturmanın imkansız olduğu anlamına gelmez, ancak bunun yerine muhtemelen tercih etmeyi tercih ettiğim, statik alanları ve statik yöntemleri örnek alanlarına ve metasınıfların örnek yöntemlerine dönüştürmektir, böylece normal nesne oryantasyon teknikleri uygulanacaktır. Bunu da yapan sistemlerin olduğuna dikkat edin: CSE 341: Smalltalk sınıfları ve metasınıfları ; Ayrıca bkz: Java statikinin Smalltalk eşdeğeri nedir?

Makul bir şekilde çalışmasını sağlamak için ciddi bir dil özelliği tasarımı yapmanız gerektiğini söylemeye çalışıyorum. Bir örnek olarak, saf bir yaklaşım yapılmış, topallamış, ancak çok sorunlu ve tartışmasız (yani tartışacağım) eksik ve kullanımı zor bir soyutlama sağlayarak mimari olarak kusurluydu.

Statik geçersiz kılma özelliğini iyi çalışacak şekilde tasarladığınızda, OOP'un sınıf tabanlı yöntemlere doğal bir uzantısı olan bir çeşit metasınıf icat etmiş olabilirsiniz. Yani, bunu yapmamak için hiçbir neden yok - ve bazı diller aslında yapıyor. Belki bir takım dillerin yapmamayı seçmesi biraz daha zorlayıcıdır.

Geçersiz kılma sanal gönderime bağlıdır: thishangi yöntemi çağıracağınıza karar vermek için parametrenin çalışma zamanı türünü kullanırsınız . Statik bir yöntemin thisparametresi yoktur , bu nedenle gönderilecek hiçbir şey yoktur.

Bazı diller, özellikle Delphi ve Python, aşağıdakileri sağlayan bir "arada" kapsamına sahiptir: sınıf yöntemleri. Bir sınıf yöntemi sıradan bir örnek yöntemi değildir, ancak statik de değildir; o türün bir örneğinden ziyade nesne türünün kendisine referans olan bir selfparametre (eğlenceli bir şekilde, her iki dil de thisparametre olarak adlandırılır self) alır. Bu değerle, artık sanal dağıtım yapmak için kullanabileceğiniz bir türünüz var.

Ne yazık ki, ne JVM ne de CLR'nin karşılaştırılabilir bir şeyi yoktur.

Sen sor

Statik fonksiyonlar neden geçersiz kılınmamalıdır?

soruyorum

Geçersiz kılmak istediğiniz işlevler neden statik olmalıdır?

Bazı diller gösteriyi statik bir yöntemle başlatmaya zorlar. Ancak bundan sonra daha fazla statik yöntem olmadan çok fazla sorunu çözebilirsiniz.

Bazı insanlar, bir nesnede duruma bağımlı olmadığında statik yöntemleri kullanmayı severler. Bazı insanlar diğer nesnelerin inşası için statik yöntemler kullanmayı sever. Bazı insanlar statik yöntemlerden mümkün olduğunca kaçınmayı sever.

Bu insanların hiçbiri yanlış değil.

Geçersiz kılmanız gerekirse, statik olarak etiketlemeyi bırakın. Hiçbir şey kırılamayacak çünkü etrafta vatansız bir cisim var.

Statik yöntemler neden geçersiz kılınmamalıdır?

Bu bir "zorunluluk" meselesi değil.

"Geçersiz kılma", " dinamik olarak gönderme" anlamına gelir . "Statik yöntem", "statik olarak gönderme" anlamına gelir. Bir şey statikse, geçersiz kılınamaz. Bir şey geçersiz kılınabilirse, statik değildir.

Sorunuz şu soruyu sormak istiyor: "Üç tekerlekli bisikletler neden dört tekerleğe sahip olamıyor?" Tanımı "üç tekerlekli bisiklet" o üç tekerleği var olduğunu. Bir üç tekerlekli bisikletse, dört tekerleği olamaz, dört tekerleği varsa, bir üç tekerlekli bisiklet olamaz. Benzer şekilde, "statik yöntem" tanımı statik olarak gönderilmesidir. Statik bir yöntemse, dinamik olarak gönderilemez, dinamik olarak gönderilebilirse, statik bir yöntem olamaz.

Elbette, geçersiz kılınabilecek sınıf yöntemlerine sahip olmak mükemmel bir şekilde mümkündür . Veya sınıf gibi diğer nesneler gibi nesneler olduğu ve böylece sınıf yöntemlerine olan ihtiyacı tamamen ortadan kaldıran örnek yöntemlere sahip olabileceği Ruby gibi bir dile sahip olabilirsiniz. (Ruby'nin yalnızca bir tür yöntemi vardır: örnek yöntemleri. Sınıf yöntemleri, statik yöntemler, yapıcılar, işlevler veya yordamlar yoktur.)

bu nedenle C # 'daki statik fonksiyonlar sanal veya soyut olamaz

C # 'da, her zaman sınıfı kullanarak statik üyeleri çağırırsınız, örneğin BaseClass.StaticMethod(), değil baseObject.StaticMethod(). Sonuç olarak, ChildClassdevralınan BaseClassve childObjectbir örneğiniz ChildClassvarsa, statik yönteminizi şundan çağıramazsınız childObject. Her zaman açıkça gerçek sınıfı kullanmanız gerekecek, bu yüzden static virtualmantıklı değil.

Yapabileceğiniz şey, staticalt sınıfınızda aynı yöntemi yeniden tanımlamak ve newanahtar kelimeyi kullanmaktır .

class BaseClass {
    public static int StaticMethod() { return 1; }
}

class ChildClass {
    public static new int StaticMethod() { return BaseClass.StaticMethod() + 2; }
}

int result;    
var baseObj = new BaseClass();
var childObj = new ChildClass();

result = BaseClass.StaticMethod();
result = baseObj.StaticMethod(); // DOES NOT COMPILE

result = ChildClass.StaticMethod();
result = childObj.StaticMethod(); // DOES NOT COMPILE

Aramak mümkün baseObject.StaticMethod()olsaydı, sorunuz mantıklı olurdu.