Neden birçok ördek tipi dinamik programlama dili prototip tabanlı OOP yerine sınıf tabanlı bir yaklaşım kullanıyor?

23

Oldukça dinamik programlama dilleri ördek yazma özelliğine sahip olduklarından ve istedikleri zaman ( Ruby ve Python gibi ) sınıf veya örnek yöntemlerini açıp değiştirebilirler .

Soru 1) Dinamik bir dilde bir sınıfa ihtiyaç var mı? Dil neden bir sınıfı prototip yapmak yerine bir çeşit “şablon” olarak kullanmak ve sadece bir nesne kullanmak için tasarlanmıştır?

Ayrıca JavaScript prototip temellidir, ancak CoffeeScript (JavaScript'in geliştirilmiş sürümü) sınıf tabanlı yolu seçer. Lua (prototip tabanlı) ve MoonScript (sınıf tabanlı) için de aynı şey geçerli . Ayrıca, ES 6'da sınıf var.

Soru 2) Prototip tabanlı bir dili geliştirmeye çalışırsanız, diğer şeylerin yanı sıra, onu sınıf tabanlı olarak değiştirmeniz gerektiğini mi tavsiye ediyor? Eğer değilse, neden bu şekilde tasarlandı?

— ICEX
kaynak

9

Birçok programcı yeni bir şeyler öğrenmekten rahatsız olmak istemez. (Çok yabancı ve "zor"). Bu nedenle, tüm bu sınıf tabanlı kütüphaneler ve onları derleyen diller.

— Thomas Eding

1

Thomas ile aynı fikirdeyim, ama komik olan, dinamik yaklaşımı öğrendikten sonra, aslında daha kolay (zor değil). Nesneler kavramı hala orada, sadece bazı aptal bir "plan" yeniden derlemeden nesnelerin değiştirilebilir. Bir sandalyeye 5. bacak koymak istersem, önce bir planı değiştirmek zorunda kalmak istemiyorum, sadece bacağını eklemek istiyorum. Dinamik diller bence gerçekliği daha yakından modelliyor.

— Lonnie En İyi

1

OOP, türlerin bildirilmesi gereken statik olarak yazılmış bir bağlamda icat edildi. Orada, sınıflar kayıtlardan ve modüllerden ileriye doğru mantıklı bir adım. Prototip tabanlı OOP, Self dili için sadece ilginç bir araştırma konusu olmuştur ve bir şekilde JavaScript'i temelde işlevsel bir dil için “OOP” kelimesini işaretlemenin en basit yolu olarak kullanmıştır. İşin güzel yanı, sınıfları prototipler üzerine uygulayabilmeniz. Meta-nesnelerden hoşlanırken, sınıfları örneklerinden ayırmak, iyi faktörlü, basit, gevşek bir şekilde birleştirilmiş kod yazmayı kolaylaştırır.

— amon

3

İlk önce ilk: JavaScript bir classsonraki ECMAScript standardından (ECMAScript 6) itibaren anahtar kelimeyi desteklemektedir . JavaScript'te sınıflar için destek uzun süredir planlanmıştır. Şimdi, ne olduğu için - sınıflar sadece sözdizimsel şekerdir, aynı tip nesneler için model hakkında akla gelmesi daha kolaydır. JS'de bu şekildedir ve Python'da ve diğer dinamik dillerde de böyledir.

— Benjamin Gruenbaum

1

@BenjaminGruenbaum "... sınıflar sadece sözdizimsel şeker ..." vay, bu benim için oldukça yeni bir fikir. Şablon olarak sınıf — - ikisi de anında değiştirilebilir. Ve miras ile nasıl başa çıkacakları da önemli değil. Bu yüzden, belki de dinamik bir dil için sınıf tabanlı yaklaşım ile prototip tabanlı yaklaşım arasında ayrım yapmaya gerek yoktur :)

— iceX

12

Soru 1) Dinamik bir dilde bir sınıfa ihtiyaç var mı? Dil neden bir sınıfı bir tür “şablon” olarak kullanacak ve prototip olarak kullanacak ve sadece bir nesne kullanacak şekilde tasarlandı?

İlk OO dili ("OO" olarak adlandırılmamış olmasına rağmen) Simula, mirasa sahip değildi. Miras Simula-67'ye eklendi ve sınıflara dayanıyordu.

Aynı zamanda Alan Kay, daha sonra "Nesne Yönelimi" olarak adlandırdığı yeni bir programlama paradigması fikri üzerine çalışmaya başladı. Mirastan gerçekten çok hoşlandı ve kendi dilinde olmasını istedi, ancak sınıflardan gerçekten hoşlanmadı. Bununla birlikte, sınıfsız miras almanın bir yolunu bulamadı ve bu yüzden sınıfları mirastan daha fazla hoşlanmadığına karar verdi ve Smalltalk, Smalltalk-72'nin ilk versiyonunu sınıfsız ve böylece mirassız tasarladı.

Birkaç ay sonra Dan Ingalls, sınıfların kendilerinin nesneler olduğu, yani metasınıfların örnekleri olduğu bir sınıf tasarımı geliştirdi. Alan Kay bu tasarımı eskilerine göre biraz daha az göreceli olarak buldu, bu yüzden Smalltalk-74 sınıflarla ve sınıflara dayalı kalıtımla tasarlandı.

Smalltalk-74'ten sonra Alan Kay, Smalltalk'ın yanlış yöne gittiğini hissetti ve aslında OO'nun neyle ilgili olduğunu temsil etmedi ve ekibin Smalltalk'ı terk edip taze başladığını önerdi, ancak oy kullandı. Böylece Smalltalk-76, Smalltalk-80 (araştırmacılara yayınlanacak ilk Smalltalk sürümü) ve nihayet Smalltalk-80 V2.0 (ticari olarak piyasaya sürülen ilk sürüm ve ANSI Smalltalk için temel olan sürüm) takip edildi. .

Simula-67 ve Smalltalk-80, tüm OO dillerinin büyükanne ve büyükbabaları olarak kabul edildiğinden, hemen ardından gelen tüm diller, sınıfların tasarımını ve sınıflara dayalı kalıtımın gözünü kopyaladı. Birkaç yıl sonra, su yüzüne çıkarılan sınıflara dayanan miras, fikir yerine miras yerine nesnelere dayanan delegasyon gibi diğer fikirler ortaya çıktığında, sınıf temelli miras çoktan kök salmıştı.

İlginçtir ki, Alan Kay'ın mevcut dili prototip delegasyonuna dayanıyor.

— Jörg K Mittag
kaynak

“... Alan Kay'ın şu anki dili…” hangisi ...?

— Javier,

@Javier: Bir adı olduğunu sanmıyorum ve sistemin adı sürekli değişiyor.

— Jörg W Mittag

Bu bir dahaki sefere bir kişinin mirasını OO için bir gereklilik olarak listelediğine işaret etmek için iyi bir cevap olmalı :)

— Hey

1

@iceX: Alan Kay fikirleri üzerinde çalışmak için Viewpoints Araştırma Enstitüsü'nü kurdu . Ne yazık ki, bilgiler web sitesinde gerçekten dağınık.

— Jörg W Mittag

3

Alan Kay, OO'dan alıntı: "OOP bana sadece mesajlaşma, yerel tutma ve devlet sürecinin korunması ve gizlenmesi ve her şeyin aşırı geç bağlanması anlamına gelir. Smalltalk ve LISP'de yapılabilir. Muhtemelen başka sistemler de vardır. bu mümkün, ama ben onların farkında değilim. "

— Joeri Sebrechts

23

Birçok programcı sınıflarla çalışmayı tercih eder. Bu, dünyayla ilgili insan düşünce süreçlerinin iyi bir modeli olan, anlaşılması kolay bir kavramdır (yani, gerçek nesneleri içgüdüsel olarak, kendilerine ait olduğunu düşündüğümüz soyut sınıf grubuyla ilişkilendiririz. . Ayrıca, sınıflar nesne türleri hakkında akıl yürütmeyi kolaylaştırır: sınıf temelli bir dilde, Liskov ikamesi gibi prensipleri uygulamak , farklı yöntemlere sahip olan veya çalışma anında türü bile değişebilen nesneler olan bir dilden daha basittir. , JavaScript'te olduğu gibi.

JavaScript'te bile çok fazla sayıda kodun sınıfları taklit etmek için prototip özelliğini kullandığını unutmayın. Bunun nedeni çoğu programcının bu şekilde düşünmeyi tercih etmesidir.

Sınıf temelli dillerin tercih edilmesinin bir başka nedeni de var: Bunları verimli koda hazırlamak daha kolay. En verimli JavaScript VM'leri, yöntemleri ve prototipleri değiştikçe JavaScript nesnelerinin türlerini temsil etmek için etkin bir şekilde sınıfları oluşturur. Bunun neden yapıldığına dair bir gerekçe için V8'in uygulamasının bu açıklamasına bakınız .

— Jules
kaynak

4

Son paragrafınız aslında söylediklerinizin tam tersini destekliyor: V8 verimli sınıf tabanlı kodları derlemek için dilde sınıflara ihtiyacınız olmadığını kanıtlıyor .

— Jörg W Mittag

4

Evet, onlara ihtiyacınız yok - ama V8'in (ve bu sistemin tasarımı hakkında pek fazla bir şey okumamıştım, ancak muhtemelen kendi kendime) etkili bir şekilde sanal sınıflar yaratması, geleneksel olarak kullanılan bir dilden başlayarak, neredeyse sınıflar olduğu anlamına gelir. kesinlikle daha kolay ve bu nedenle muhtemelen JIT’in kodu derlemek için daha az zaman harcamasına ihtiyaç duyacak.

— Jules

11

Elbette, ve V8'in etkili bir şekilde GOTOs ve kayıt oluşturması, tüm soyutlamaları bırakmanın ve doğrudan montajda yazmanın neredeyse kesinlikle daha kolay olduğu ve bu nedenle muhtemelen JIT'nin kodu derlemek için daha az zaman harcamasına ihtiyaç duyacağı anlamına gelir. Üst düzey soyutlamaları desteklemek bir derleyicinin işidir.

— Jörg W Mittag

1

Evet, ancak bu bir takas, çünkü üst seviye soyutlama çoğu durumda uygulanması zor ve çoğu zaman bir AOT derleyicisinden ziyade bir JIT ile çalışırken bir çalışma süresi performans cezası veriyor. Birçok dil tasarımcısının bu nedenlerden biri veya her ikisi için de sınıf temelli bir yapı seçtiğinden şüpheleniyorum; Bu yüzden üzerinde çalıştığım (aksi halde dinamik) bir dil için sabit üyeli sınıfları seçtiğimi biliyorum, ancak yalnızca diğer diller hakkında tahminde bulunabilir.

— Jules

1

Programcıların “sınıflarda düşünmeyi” tercih etmelerinin tek yolunun, çoğumuzun böyle öğretildiği içindir. Yine de, birkaç yıl boyunca gerçekten temel Nesneye Dayalı Kavramları kavrama ve anlama konusunda güçlük çeken üniversite arkadaşlarımın birçoğunu kesinlikle hatırlayabilirim. Sadece görüşte açık ve kolay görünüyor.

— KChaloux

3

İnsanların ekiplerinin aynı kod üzerinde birlikte çalıştığı büyük projelerde, esnek dillerin (çalışma sırasında nesnenin özelliklerini ve yöntemlerini değiştirebileceğiniz) diğer ekip üyelerinin istemediği özgürlükler olduğunu duydum. sahip olmak.

Bir nesneyle uğraşırken, nesnenin tam planın söylediği gibi hareket edeceğini ve başka bir hırslı geliştiricinin kendi görevini tamamlamak için onu değiştirmeye karar verdiğine karar vermeyeceğini bilmek isterler.

Bu yüzden, birisinin bu harika dinamik dillerin sunduğu esneklikleri istememesi gerektiğini düşünebilmemin tek nedeni, ekip geliştirmeyi, hata ayıklamayı ve otomatik dokümantasyonu basitleştirmek istemeleridir.

Şahsen, her iki metodolojide de uygulamalar geliştirdim ve işleri dinamik dillerle daha hızlı yapıyorum. Dinamik dilimi tekrar sınıf temelli bir dile çevirmek için tasarlanan bu çerçevelerin hiçbirini kullanmıyorum. Bu şeyler zevklerime bir gerilemedir.

— Lonnie Best
kaynak

1

OOP benim için sadece mesajlaşma, yerel tutma ve devlet sürecinin korunması ve saklanması ve her şeyin aşırı geç bağlanması anlamına gelir - Alan Kay

Yani burada söylediği şey, OO'nun tamamen mesajlara cevap veren kara kutular yapmak olduğu. Bir şekilde REST, fiilleri (yani bir mesajı) ve kaynakları (yani bazı verileri içeren bir opak kutuyu) kullandığı nihai OO sistemidir.

Öyleyse neden bazılarının sınıf tabanlı ve diğerlerinin prototip tabanlı olduğu sorusu, gerçekten önemli olmadığı noktasını gözden kaçırıyor, ikisi de yalnızca birer uygulama. Metod çağrıları yerine sadece mesajlaşmayı kullanan bir sistem, bahsettiğiniz iki örnek kadar OO'dur.

— gbjbaanb
kaynak