Klasik OOP'nin Go-like diline göre faydaları

Dil tasarımı ve "ideal" bir programlama dili için hangi öğelerin gerekli olacağı hakkında çok şey düşünüyordum ve Google'ın Go'yu incelemek beni başka türlü ortak bilgiyi sorgulamamı sağladı.

Özellikle Go, nesne yönelimli bir dilin yapısına sahip olmadan nesne yönelimli programlamanın tüm ilginç faydalarına sahip gibi görünüyor . Sınıf yok, sadece yapılar var; sınıf / yapı mirası yoktur - sadece yapı gömme. Herhangi bir hiyerarşi yok, üst sınıf yok, açık arabirim uygulaması yok. Bunun yerine, tür döküm kuralları ördek tiplemesine benzer gevşek bir sisteme dayanır, böylece bir yapı bir "Okuyucu" veya "İstek" veya "Kodlama" öğelerinin gerekli öğelerini uygularsa, onu yayınlayabilir ve kullanabilirsiniz tek olarak.

C ++ ve Java ve C # 'da uygulandığı şekliyle OOP hakkında, Go gibi bir dile geçerken vazgeçmeniz gereken daha güçlü, daha sürdürülebilir, bir şekilde daha güçlü bir şey var mı? Bu yeni paradigmanın temsil ettiği basitliği kazanmak için ne gibi bir avantajınız var?

DÜZENLEME
Okuyucular aşırı asıldı ve çileden gibi görünüyordu "eski" soruyu kaldırıldı.

Soru, ortak dil uygulamalarında sıkça görüldüğü gibi geleneksel nesne yönelimli paradigmanın (hiyerarşiler ve benzerleriyle) bu basit modelde kolayca yapılamayan ne sunması gerektiğidir. Ya da başka bir deyişle, bugün bir dil tasarlayacak olsaydınız, sınıf hiyerarşileri kavramını dahil etmek istemenizin bir nedeni var mı?

Yeni bir paradigma yok. Nesne yönelimi, programları yazmak için kullandığınız ve açıkça tanımlanmamış bir kalıptır. Çeşitli diller, nesne yönelimi (yeni türlerin tanımı, kapsülleme, tür hiyerarşileri, polimorfizm, mesaj iletme ve daha fazlası) gibi çeşitli özellikler sağlar, ancak başkalarını sağlayamayabilir. Bu gibi durumlarda, programcıların ihtiyaç duyulması halinde taklit etmeleri gerekir.

Bu özellikleri sağlayan dillerin çoğunda sınıf kavramının bir analogu yoktur - örneğin Javascript ve Common Lisp. Java benzeri diller tarafından sağlanan uygulama (sınıf tabanlı, tek miras, arabirimler, tür tabanlı gönderim) olasılıklardan sadece bir tanesidir ve en iyisi değildir.

Bu yeni paradigmanın temsil ettiği basitliği kazanmak için ne gibi bir avantajınız var?

Bir yapısal tip sistemi için tip kontrolü, sadece temel sınıfın miras listenizde olup olmadığını kontrol etmekten çok daha karmaşıktır. Sanal dağıtım biraz daha karmaşık ve muhtemelen daha az performansa dönüşür.

Böyle bir sistem OOP kavramını geçersiz kılar mı?

Hayır. Programı, talimatlar listesi veya beyan edilen bir kurallar kümesi veya basamaklı bir işlevler dizisi yerine 'bir şeyler yapan nesneler' açısından yapabileceğiniz sürece ... uygulama önemli değildir. Benzer şekilde, tip sisteminin değiştirilmesi, ortak OO ilkelerinin hiçbirini geçersiz kılmaz.

Hala bir baz türü üzerinde çalışabilir ve gerçek türünü umursamayabilirsiniz. Türleri değiştirmeden yine de genişletebilirsiniz. Yine de bir türün tek bir şey yapmasını sağlayabilirsiniz. Yine de ince taneli arayüzler sağlayabilirsiniz. Yine de türlerinize soyutlamalar sağlayabilirsiniz.

Bir dilin buna nasıl izin verdiği gerçekten önemli değil.

Bence OOP hakkındaki fikriniz biraz kapalı:

'Nesneye Dayalı Programlama' terimini icat ettim ve bu {Java ve C ++} aklımdaki gibi değil.
- Alan Kay .

Yazma (nominative subtyping, yapısal subtyping veya duck tipleme - veya bunların bir kombinasyonu) seçimi büyük ölçüde OOP ile dikeydir. Kalıtım ve sınıflar tamamen OOP'ye diktir. Eğer io ile oynamak için biraz zaman ayırırsanız, bunu görmeye geleceksiniz.

Şimdi hangi tür sistemlerin "daha iyi" olduğunu ve hangi kodun yeniden kullanımı ve kombinasyonunun ne olduğunu sorabilirsiniz. Ve Simula'da yapılan (ve daha sonra C ++, Java ve C # ile yapılan) ve Go'da yapılan seçenekler arasındaki avantajları ve dezavantajları belirlemeye çalışın. Fakat bunların hepsi farklı ve farklı sorular.

Nihayetinde, OOP çok belirsiz bir kavramdır ve onu uygulamak için yapılan tüm girişimler çok çeşitli lezzetlere sahiptir. Ancak işleri gerçekten basitleştirmek için, OOP'un ana fikrinin SOLID alt sistemlerini oluşturmak olduğunu söyleyebilirim . Şimdi bu kesinlikle diğer paradigmalara hitap ediyor, ancak son zamanlarda çok paradigma dillerinin popülaritesinin artmasının ve Google'ın Go ile bu konuda kendi çekimini yapmasının nedeni olduğunu tahmin ediyorum.

OOP kullanılmıyor.

Andrea'nın dediği gibi, sınıflara alternatif olarak önerilen birçok kavram vardır (örneğin: haskell typeclass için). OOP'un büyük bir yararı vardır: birçok yerde öğretilir ve OOP kültürü geliştiriciler arasında büyük ölçüde paylaşılır.

Bu, bir ekip içinde daha zengin iletişim sağlar. Bir bahsedebiliriz fabrikalar daha kolay göre yaklaşık Zygohistomorphic prepromorphisms . OOP, programınız hakkında organize edeceğiniz ve yaygın olarak kullanılan diyagramlarla iletişim kurma şeklinizi yapılandırır. Bu güçlü bir varlıktır.

Hayır, burada yeni bir şey yok, ne de OOP kullanılmıyor. C ++ şablonlar biçiminde de örtülü arabirimlere sahiptir, ancak insanlar hala sanal işlevleri kullanır. İkili arabirimler veya derleme zamanında diğer kodun bilinmediği arabirimlerle başa çıkmak için açık arabirimlere ihtiyacınız vardır.

Bunun açık bir şekilde belirtmekle sonuçlanan bir çıkarım örneği olduğunu iddia edebilirsiniz.