OOP olmayan paradigmalar kapsülleme gibi kavramları destekliyor mu?

Nesneye Yönelik Programlamadaki önemli kavramlardan biri Kapsülleme'dir. Ancak, son zamanlarda yazılım dünyası fonksiyonel programlama gibi diğer paradigmalar lehine hareket ediyor gibi görünüyor.

Beni enkapsülasyon ve diğer OOP ilkeleri hakkında düşündürüyor? Yanlış mı?

OOP yanlış uygulanmış mı? Örneğin Alan Kay, OOPSLA'97 Açılış Konuşmasında şunları söyledi: "Nesne yönelimli terimini icat ettim ve aklımda C ++ bulunmadığımı söyleyebilirim."

Joe Armstrong - "Nesneler bölünmez birimlerde fonksiyonları ve veri yapılarını birbirine bağlar. Bence bu fonksiyonlar ve veri yapıları tamamen farklı dünyalara ait olduğu için temel bir hatadır."

Burada gördüğünüz tuzak, herhangi bir programlama paradigmasının (yapılandırılmış, nesne yönelimli, fonksiyonel, vb.) Katı bir tanımı olduğunu düşünüyor.

İki farklı geliştiriciye OOP'un ne anlama geldiğini sorarsanız, iki farklı cevap alırsınız. Evet, bir meslek olarak, üniversitedeki herhangi bir OOP yazılım mühendisliği sınıfının kapsadığı kapsülleme, veri gizleme vb. Gibi birkaç ortak tema olduğunu kabul ediyoruz.

Bununla birlikte , gerçek dünyada, işler o kadar kesilmiş ve kuru değildir, bu yüzden iki geliştirici iki farklı cevap verecektir. Belki de OOP kavramlarını farklı ifade eden farklı dillerde uzmandırlar. Dil paradigmaları örtüşme eğilimindedir. 2013 yılı itibarıyla en son öfke, kapaklar veya lambdalar aracılığıyla nesne yönelimli dillerde fonksiyonel programlamayı birleştirmektir. Java 8 nesne yönelimli veya işlevsel mi? Ben işlevsel bir çizgi ile nesne odaklı diyebilirim. Başka biri bunu farklı tanımlayabilir.

OOP yanlış uygulanmış mı?

Hayır, sorun şu ki, çeşitli diller programlama kavramlarını farklı ifade ediyor. Belki bir dil bir OOP kavramını bırakır ve başka bir dil onu içerir, ancak farklı bir OOP kavramını bırakır. Diller genellikle bir amaç için tasarlanmıştır: diğer görevleri daha zor hale getirme pahasına belirli bir görevi kolaylaştırmak. Bu ne doğru ne de yanlıştır, kaçınılması imkansız olan gerçek dünyadaki bir ödünleşmedir.

Gerçek dünya sınıf değildir . Kavramsal programlama paradigmalarını soyut düzeyde tartışmamız ya da yararlı olabilmek için ödünleşmeye zorlanan gerçek programlama dillerini tartışmamız gerekir. Bir programlama dili çoğunlukla OOP'nin soyut bir tanımı ile tanımlandığı sürece, dili o gruba dahil edebiliriz.

Ancak, son zamanlarda yazılım dünyası fonksiyonel programlama gibi diğer paradigmalar lehine hareket ediyor gibi görünüyor.

Bu tartışmalıdır. İlk olarak, OOP ve fonksiyonel programlamanın yanı sıra geniş bir şekilde tartışılan başka paradigmalar görmüyorum, bu yüzden "gibi diğer paradigmalar" ifadesini unutabiliriz, FP hakkında konuşalım, başka bir şey yok.

İşlevsel programlamanın son yıllarda bu kadar popüler olmasının nedenleri, buradaki diğer sorularda derinlemesine tartışıldı, bunu tekrar etmeyeceğim ( örneğin buraya veya buraya bakın ). Ancak, bence bu "OOP büyük bir hataydı" ya da "İşlevsel ve OOP birbirini dışlayan" değil, daha çok araç kutularını genişleten ve her iki dünyanın en iyisini elde etmeye çalışan insanlar gibi değil. Tamam, kesinlikle bir diğerini tercih eden hardliner uzmanları var, ancak bu adamları her iki tarafta da bulacaksınız.

Beni enkapsülasyon ve diğer OOP ilkeleri hakkında düşündürüyor? Yanlış mı?

Kapsüllemenin birçok farklı lezzeti vardır. Fonksiyonel programlama dilleri ve dil yapıları, nesne yönelimli diğerleri gibi belirli kapsülleme formları sağlar. Fonksiyonel araçlarla kapsülleme örnekleri arıyorsanız, kapaklarla başlayın .

"Diğer ilkeler" ile ilgili olarak: hayır, yanlış değiller, ancak yüksek ölçekli paralelleştirme gibi belirli senaryolar için, işlevsel yaklaşımlar muhtemelen daha iyi ölçeklenir. İyi tasarlanmış UI çerçeveleri oluşturmak gibi diğer senaryolar için, OOP yaklaşımları muhtemelen daha iyi ölçeğe sahiptir (YMMV, sadece daha iyi bir örneğim yok). Dahası, çoğu gerçek dünya senaryosu için, belirli bir sistemin ne kadar iyi ölçekleneceği favori programlama paradigmasıyla ekibin bilgi ve deneyimine bağlı olduğundan eminim.

OOP yanlış uygulanmış mı? Örneğin Alan Kay, OOPSLA'97 Açılış Konuşmasında şunları söyledi: "Nesne yönelimli terimini icat ettim ve aklımda C ++ bulunmadığımı söyleyebilirim."

Şüphesiz OOP çoğu insan tarafından yanlış uygulanır, ancak eminim FP için de geçerlidir. Ve John Mc Carthy (Lisp tasarımcısı) fonksiyonel programlama hakkında düşünürken Javascript gibi bir şey olsaydı şaşıracaktım (bana merhamet et, bu karşılaştırma için beni çok fazla alevlendirme ;-)

Joe Armstrong - "Nesneler bölünmez birimlerde fonksiyonları ve veri yapılarını birbirine bağlar. Bence bu fonksiyonlar ve veri yapıları tamamen farklı dünyalara ait olduğu için temel bir hatadır."

Sanırım Erlang'ın mucidinin bazı iyi argümanları var, ama aynı zamanda kendi bakış açısına sahip, bu yüzden ona fikrini vermesine ve kendi fikrini oluşturmasına izin ver. Bu konuda farklı bir fikri olan birçok uzman var.

Elbette:

struct Foo
{
    string bar;
    int bux;
}

Ne diyeceğinizi biliyorum: "Ama bu aynı zamanda davranışı da kapsama almıyor!" Bu konuda Joe Armstrong ile birlikteyim: birinci sınıf nesneler gerektirmeden tüm programları veya işletim sistemlerini yazabilirsiniz. Linux bunu kanıtlıyor.

Javascript programcıları , sınıfları değil , işlevleri ve kapanışları durum ve davranışlarını rutin olarak kapsüllemektedir .

Buradaki ana sorun, Kapsüllemenin katı bir şekilde tanımlanmamış bir kavram olmadığı ve neden yararlı olduğudır. Bazı araştırmalar yapmak, insanların kapsüllemeyi nasıl gördüğünü çok tartışıldığını ve birçok insanın Soyutlama ile karıştırdığını gösteriyor.

Eğer ilk tanım bulacak olan

Kapsülleme, verileri ve verileri işleyen işlevleri birbirine bağlayan bir kavramdır ...

Bu sizin tanımınızsa, dillerin çoğunda bu veriler üzerinde çalışan verileri ve işlevleri sınıflar, modüller, kütüphaneler, ad alanları vb.

Ancak, bu tanım devam ettiği için kapsüllemenin ana amacı olmadığını iddia ediyorum:

... ve bu hem dış müdahalelerden hem de yanlış kullanımdan korunuyor.

Wikipedia ayrıca şunu da kabul eder :

Nesnenin bazı bileşenlerine doğrudan erişimi kısıtlayan bir dil mekanizması.

Ancak şimdi, "girişim ve kötüye kullanım" ile neyin kastedildiğini ve verilere doğrudan erişimin neden kısıtlanması gerektiğini sormalıyız. İki sebebi olduğuna inanıyorum.

Birincisi, verilerin mutasyona uğratılabileceği sınırlama kapsamının geliştiricinin yararına olmasıdır. Çok sık değer ayarlanmadan önce / sonra mantığa ihtiyaç vardır. Ve değerin ayarlanabileceği sınırlı sayıda yere sahip olmak son derece değerlidir. OOP dillerinde bu sınıflar kullanılarak yapılabilir. "Değişken" işlevsel dillerde kapaklar aynı amaca hizmet eder. Ve sınıfları = kapanışları bildiğimiz için, değişken işlevsel diller OOP'tan farklı "paradigma" dan daha tartışmalıdır.

Peki ya değişmez diller? Değişkenleri değiştirme sorunu yoktur. Burada ikinci sayı devreye giriyor: ciltleme fonksiyonları ve veriler bu verilerin geçerli durumda kalmasına izin veriyor. Değişmez bir yapıya sahip olduğunuzu düşünün Email. Bu yapının tek bir stringalanı vardır. Tür değeriniz varsa, Emailbu alanın geçerli adres içermesi gibi gereksinimlerimiz vardır . OOP'nin kapsüllenmesinde, bu alanın ilan edilmesi private, sadece Getyöntem sağlanması veconstructor methodancak dize iletilirse geçerli adres başarılı olur. Kapaklar ile benzer şey. Şimdi, değişmez bir dil için, yapının sadece belirli bir fonksiyonla başlatılabileceğini ve bu fonksiyonun başarısız olabileceğini söylemek gerekir. Ve bu kriterlere uyan herhangi bir dilin farkında değilim (belki yorumlardaki biri beni aydınlatabilir).

Son konu, dilin "destekleyici" kapsüllenmesiyle kastedilen şeydir. Bir tarafta kapsüllemenin uygulanmasına izin veren diller vardır, böylece kapsüllemenin bozulması durumunda kod derlenmez. Öte yandan, dil kapsülleme yapmanın bir yolunu sağlayabilir, ancak bunu zorlamaz ve geliştiriciyi kendileri zorlamaya bırakmaz. İkinci durumda, yapıları ve işlevleri olan herhangi bir dil çalışabilir. Dinamik diller ve Haskell akla geliyor. Ve ben spektrumun diğer tarafına düşen çok fazla dil olmadığını söyleyebilirim. Nesneleri için kapsüllemeyi zorlamada gerçekten iyi olan C # bile yansıma kullanılarak atlanabilir. Ama görmek C # büyük kod kokusu olarak kabul edilir ve hiçbir aklı başında C # geliştirici bunu isteyerek yapardı.