Neden C #, yöntemleri varsayılan olarak sanal olmayan olarak uygular?

Java'dan farklı olarak, C # neden yöntemleri varsayılan olarak sanal olmayan işlevler olarak ele alıyor? Diğer olası sonuçlardan ziyade bir performans sorunu olması daha olası mıdır?

Anders Hejlsberg'den, mevcut mimarinin ortaya çıkardığı çeşitli avantajlar hakkında bir paragraf okumamı hatırlattım. Peki ya yan etkiler? Varsayılan olarak sanal olmayan yöntemlere sahip olmak gerçekten iyi bir takas mı?

Sınıflar, mirastan yararlanabilmek için tasarlanmalıdır . virtualVarsayılan olarak yöntemlere sahip olmak , sınıftaki her işlevin çıkarılıp başka bir işlevle değiştirilebileceği anlamına gelir ki bu gerçekten iyi bir şey değildir. Hatta birçok insan sınıfların sealedvarsayılan olarak olması gerektiğine inanıyor .

virtualyöntemlerin ayrıca küçük bir performans sonuçları olabilir. Ancak bu, muhtemelen birincil neden değildir.

Burada, varsayılan olarak sanal olmayanın işleri yapmanın doğru yolu olduğu konusunda böyle bir fikir birliği olduğuna şaşırıyorum. Çitin öteki tarafına - pragmatik olduğunu düşünüyorum - aşağı ineceğim.

Gerekçelerin çoğu bana eski "Size güç verirsek kendinize zarar verebilirsiniz" argümanı gibi okunuyor. Programcılardan mı ?!

Bana öyle geliyor ki, kütüphanesini miras ve / veya genişletilebilirlik için tasarlamak için yeterince bilmeyen (veya yeterli zamanı olan) kodlayıcı, tam olarak düzeltmem veya ayarlamam gereken kütüphaneyi üreten kodlayıcıdır - tam olarak geçersiz kılma yeteneğinin en yararlı olacağı kütüphane.

Çirkin, çaresiz bir çözüm kodu yazmak zorunda kaldığım (veya kullanımdan vazgeçip kendi alternatif çözümümü yuvarlamak için) kaç kez geçersiz kılamıyorum çünkü ısırıldığımdan çok daha ağır basmaktadır ( örneğin Java'da) tasarımcının yapabileceğimi düşünmemiş olabileceği yerleri geçersiz kılarak.

Varsayılan olarak sanal olmaması hayatımı zorlaştırıyor.

GÜNCELLEME: Soruyu gerçekten cevaplamadığım [oldukça doğru bir şekilde] belirtildi. Yani - ve geç kaldığım için özür dilerim ...

"C #, yöntemleri varsayılan olarak sanal olmayan olarak uygular, çünkü programlara programcılardan daha fazla değer veren kötü bir karar verildi" gibi özlü bir şey yazabilmek istedim. (Sanırım bu, bu soruya verilecek diğer yanıtlardan bazılarına dayanarak - performans (erken optimizasyon, herhangi biri?) Veya sınıfların davranışını garanti altına alma gibi bir şekilde haklı gösterilebilir.)

Ancak, Stack Overflow'un istediği kesin yanıtı değil, kendi fikrimi ifade ettiğimin farkındayım. Şüphesiz, en üst düzeyde kesin (ama yararsız) cevabın şöyle olduğunu düşündüm:

Varsayılan olarak sanal değillerdir çünkü dil tasarımcılarının vermesi gereken bir karar vardı ve onlar da bunu seçtiler.

Şimdi sanırım bu kararı vermelerinin kesin nedeni, biz asla .... oh, bekle! Bir konuşmanın metni!

Öyleyse, API'leri geçersiz kılma tehlikeleri ve kalıtım için açık bir şekilde tasarlama ihtiyacı hakkındaki cevaplar ve yorumlar doğru yoldadır, ancak hepsinin önemli bir zamansal yönü eksiktir: Anders'in asıl endişesi, bir sınıfın veya API'nin örtülü olarak sürdürülmesiydi. sürümler arasında sözleşme . Ve sanırım aslında, platformun üstündeki kullanıcı kodu değişikliği ile ilgilenmek yerine .Net / C # platformunun kod altında değişmesine izin verme konusunda endişeli. (Ve onun "pragmatik" bakış açısı benimkinin tam tersi çünkü diğer taraftan bakıyor.)

(Ama varsayılan olarak sanal olanı seçip sonra kod tabanında "final" i seçmiş olamazlar mı? Belki de bu tam olarak aynı değildir .. ve Anders açıkça benden daha zeki, bu yüzden yalan söylemesine izin vereceğim.)

Çünkü bir yöntemin geçersiz kılınabileceğini ve bunun için tasarlanmadığını unutmak çok kolaydır. C #, onu sanal yapmadan önce düşünmenizi sağlar. Bunun harika bir tasarım kararı olduğunu düşünüyorum. Hatta bazı insanlar (Jon Skeet gibi) sınıfların varsayılan olarak mühürlenmesi gerektiğini bile söyledi.

Başkalarının söylediklerini özetlemek gerekirse, birkaç neden var:

1- C # 'da, doğrudan C ++' dan gelen sözdizimi ve anlambilimde birçok şey vardır. C ++ 'da varsayılan olarak sanal olmayan yöntemlerin C #' ı etkilediği gerçeği.

2- Her yöntemin varsayılan olarak sanal olması bir performans sorunudur çünkü her yöntem çağrısı nesnenin Sanal Tablosunu kullanmalıdır. Dahası, bu Just-In-Time derleyicisinin yöntemleri satır içi yapma ve diğer optimizasyon türlerini gerçekleştirme becerisini büyük ölçüde sınırlar.

3- En önemlisi, eğer yöntemler varsayılan olarak sanal değilse, sınıflarınızın davranışını garanti edebilirsiniz. Java'da olduğu gibi varsayılan olarak sanal olduklarında, basit bir alıcı yönteminin amaçlandığı gibi yapacağını garanti edemezsiniz, çünkü türetilmiş bir sınıfta herhangi bir şey yapmak geçersiz kılınabilir (tabii ki yapabilir ve yapmalısınız) yöntem ve / veya sınıf finali).

Zifre'nin bahsettiği gibi, C # dilinin neden bir adım daha ileri gitmediğini ve sınıfları varsayılan olarak mühürlemediğini merak edebilirsiniz. Bu, çok ilginç bir konu olan uygulama kalıtımının sorunları hakkındaki tüm tartışmanın bir parçası.

C #, C ++ 'dan (ve daha fazlasından) etkilenir. C ++, varsayılan olarak dinamik dağıtımı (sanal işlevler) etkinleştirmez. Bunun için bir (iyi?) Argüman şu sorudur: "Bir sınıf hiearchy'nin üyeleri olan sınıfları ne sıklıkla uygularsınız?". Varsayılan olarak dinamik gönderimi etkinleştirmekten kaçınmanın bir başka nedeni de bellek ayak izidir. Sanal bir tabloya işaret eden bir sanal işaretçisi (vpointer) olmayan bir sınıf , tabii ki geç bağlamanın etkinleştirildiği karşılık gelen sınıftan daha küçüktür.

Performans sorununun "evet" veya "hayır" demesi o kadar kolay değil. Bunun nedeni, C # 'da bir çalışma zamanı optimizasyonu olan Just In Time (JIT) derlemesidir.

Hakkında başka, benzer bir soru " sanal aramaların hızı .. "

Bunun basit nedeni, performans maliyetlerine ek olarak tasarım ve bakım maliyetidir. Bir sanal yöntemin, sanal olmayan bir yönteme kıyasla ek maliyeti vardır çünkü sınıfın tasarımcısı, yöntem başka bir sınıf tarafından geçersiz kılındığında ne olacağını planlamalıdır. Belirli bir yöntemin iç durumu güncellemesini veya belirli bir davranışa sahip olmasını bekliyorsanız, bu büyük bir etkiye sahiptir. Artık türetilmiş bir sınıf bu davranışı değiştirdiğinde ne olacağını planlamalısınız. Bu durumda güvenilir kod yazmak çok daha zordur.

Sanal olmayan bir yöntemle tam kontrole sahip olursunuz. Yanlış giden her şey orijinal yazarın hatasıdır. Kod hakkında akıl yürütmek çok daha kolaydır.

Tüm C # yöntemleri sanal olsaydı, vtbl çok daha büyük olurdu.

C # nesneleri yalnızca, sınıfın tanımlanmış sanal yöntemlere sahip olması durumunda sanal yöntemlere sahiptir. Tüm nesnelerin bir vtbl eşdeğeri içeren tür bilgilerine sahip olduğu doğrudur, ancak hiçbir sanal yöntem tanımlanmadıysa yalnızca temel Object yöntemleri mevcut olacaktır.

@Tom Hawtin: C ++, C # ve Java'nın C dil ailesinden olduğunu söylemek muhtemelen daha doğru olacaktır :)

Perl arka planından gelen C #, yeni sınıfın tüm kullanıcılarını potansiyel olarak sahne arkasından haberdar olmaya zorlamadan sanal olmayan bir yöntem aracılığıyla temel sınıfın davranışını genişletmek ve değiştirmek isteyebilecek her geliştiricinin kıyametini mühürlediğini düşünüyorum. detaylar.

List sınıfının Add yöntemini düşünün. Bir geliştirici, belirli bir Liste 'Eklendiğinde' birkaç potansiyel veritabanından birini güncellemek isterse ne olur? Eğer 'Ekle' varsayılan olarak sanal olsaydı, geliştirici, tüm istemci kodunu normal bir 'Liste' yerine bir 'BackedList' olduğunu bilmeye zorlamadan 'Add' yöntemini geçersiz kılan bir 'BackedList' sınıfı geliştirebilirdi. Tüm pratik amaçlar için 'BackedList', müşteri kodundan başka bir 'Liste' olarak görülebilir.

Bu, bir veritabanındaki bir veya daha fazla şema tarafından desteklenen bir veya daha fazla liste bileşenine erişim sağlayabilen büyük bir ana sınıf açısından anlamlıdır. C # yöntemlerinin varsayılan olarak sanal olmadığı göz önüne alındığında, ana sınıf tarafından sağlanan liste basit bir IEnumerable veya ICollection veya hatta bir List örneği olamaz, ancak bunun yerine istemciye yeni sürümün Doğru şemayı güncellemek için 'Ekle' işleminin bir kısmı çağrılır.

Kesinlikle bir performans sorunu değil. Sun'ın Java tercümanı, aynı kodu göndermek için ( invokevirtualbayt kodu) kullanır ve HotSpot, tamamen aynı kodu üretir veya üretmez final. Tüm C # nesnelerinin (ancak yapıların değil) sanal yöntemlere sahip olduğuna inanıyorum, bu nedenle her zaman vtbl/ runtime sınıf tanımlamasına ihtiyacınız olacak . C #, "Java benzeri dillerin" bir lehçesidir. C ++ 'dan geldiğini öne sürmek tamamen dürüst değil.

"Miras için tasarlamanız, yoksa onu yasaklamanız" gerektiği fikri var. Bu, hızlı bir şekilde düzeltmeniz gereken ciddi bir iş durumunuz olduğu ana kadar harika bir fikir gibi geliyor. Belki de kontrol etmediğiniz koddan miras alırsınız.