“Fonksiyonlar ve veriler arasında sıkı bağlantı” neden kötü?

Bu alıntıyı " Clojure'nin Sevinci" sinde p. 32, ancak birileri geçen hafta akşam yemeğinde bana aynı şeyi söyledi ve ben de başka yerlerde duydum:

Nesne yönelimli programlamanın dezavantajı [A], fonksiyon ve veri arasındaki sıkı bağlantıdır.

Bir uygulamada gereksiz eşlemenin neden kötü olduğunu anlıyorum. Ayrıca değişken durum ve kalıtımın, Nesneye Yönelik Programlama'da bile, kaçınılması gerektiğini söyleyerek rahatım. Ancak sınıflara yapıştırma işlevlerinin neden doğal olarak kötü olduğunu göremiyorum.

Yani, bir sınıfa işlev eklemek Gmail'de bir posta etiketlemek veya bir dosyayı bir klasöre yapıştırmak gibi görünüyor. Onu tekrar bulmanıza yardımcı olan örgütsel bir tekniktir. Bazı kriterleri seçiyorsun, sonra bir şeyler yap. OOP'tan önce, programlarımız dosyalarda oldukça büyük yöntem torbalarıydı. Yani, işlevleri bir yere koymak zorundasın. Neden onları organize etmiyorsun?

Bu, türlere örtülü bir saldırı ise, neden giriş ve çıkış türlerinin bir işlevle sınırlandırılmasının yanlış olduğunu söylemiyorlar? Buna katılıp katılamayacağımı bilmiyorum, ama en azından pro ve con tipi güvenliği tartışıyorlar. Bu bana çoğunlukla ayrı bir endişe gibi geliyor.

Elbette, bazen insanlar bunu yanlış anlar ve işlevselliği yanlış sınıfa koyar. Ancak diğer hatalarla karşılaştırıldığında, bu çok küçük bir rahatsızlık gibi görünüyor.

Öyleyse, Clojure'un ad alanları var. OOP'taki bir sınıfa bir işlevin Clojure'da bir isim alanına işlevin yapıştırılmasından farklı olması ve neden bu kadar kötü? Unutmayın, bir sınıftaki işlevler mutlaka yalnızca o sınıfın üyeleri üzerinde işlemez. Java.lang.StringBuilder'a bakın - herhangi bir referans tipinde veya otomatik boks yoluyla herhangi bir tipte çalışır.

Not: Bu alıntı okumadığım bir kitaba atıfta bulunuyor: Leda'da Multiparadigm Programlama: Timothy Budd, 1995 .

Teoride, gevşek fonksiyon-veri birleştirme aynı veri üzerinde çalışmak için daha fazla fonksiyon eklemeyi kolaylaştırır. Aşağı tarafı, veri yapısını değiştirmeyi zorlaştırmaktadır, bu nedenle pratikte iyi tasarlanmış işlevsel kod ve iyi tasarlanmış OOP kodunun çok benzer bağlanma seviyelerine sahip olmaları gerekir.

Örnek veri yapısı olarak yönlendirilmiş bir asiklik grafik (DAG) alın. İşlevsel programlamada, kendini tekrarlamaktan kaçınmak için hala bir soyutlamaya ihtiyaç duyarsınız, böylece düğüm ve kenarları ekleme ve silme, belirli bir düğümden erişilebilen düğümleri bulma, topolojik sıralama oluşturma, vb. İşlevler içeren bir modül yapacaksınız. derleyici tarafından zorlanmadığı halde verilere etkili bir şekilde sıkı sıkıya bağlıdırlar. Bir düğümü zor yoldan ekleyebilirsiniz, ama neden istemesin ki? Bir modüldeki yapışkanlık, sistem genelinde sıkı bağlantıyı önler.

Tersine, OOP tarafında, temel DAG işlemleri dışındaki tüm işlevler, ayrı bir "görünüm" sınıfında, DAG nesnesi parametre olarak geçirildiğinde gerçekleştirilecektir. DAG verileri üzerinde çalışan, işlevsel programda bulacağınız aynı düzeyde işlev verisi ayrıştırma düzeyini yaratarak istediğiniz kadar görünüm eklemek kolaydır. Derleyici, her şeyi tek bir sınıfa sıkıştırmaktan alıkoymayacak, ancak meslektaşlarınız olacak.

Programlama paradigmalarını değiştirmek en iyi soyutlama, uyum ve eşleştirme uygulamalarını değiştirmez, sadece derleyiciyi uygulamanıza yardımcı olan uygulamaları değiştirir. İşlevsel programlamada, işlev-veri birleşimi istediğinizde, derleyici yerine beyler sözleşmesi ile uygulanır. OOP'de model-görünüm ayrımı, derleyici yerine beyler sözleşmesiyle uygulanır.

Bilmiyorsanız, bu görüşü zaten almalısınız: Nesne yönelimli ve kapanış kavramları aynı madalyonun iki yüzüdür. Yani, kapanış nedir? Değişkenleri veya verileri çevreleyen kapsamdan alır ve işlevin içine bağlar ya da bir OO perspektifinden, örneğin bir şeyi bir kurucuya iletirken aynı şeyi etkili bir şekilde yaparsınız; bu örneğin bir üye işlevindeki veri parçası. Ancak işleri çevreleyen kapsamdan almak iyi bir şey değildir - çevreleyen kapsam ne kadar büyükse, bunu yapmak o kadar kötüdür (pragmatik olarak, işlerin yapılması için genellikle bazı kötülükler gerekir). Küresel değişkenlerin kullanımı, bunu, bir programdaki işlevlerin program kapsamındaki değişkenleri kullandığı aşırı noktaya götürüyor - gerçekten çok kötü. VarKüresel değişkenlerin neden kötü olduğu konusunda başka yerlerde iyi açıklamalar .

Eğer OO tekniklerini takip ediyorsanız, temelde programınızdaki her bir modülün belli bir minimum kötülük seviyesine sahip olacağını kabul etmiş olursunuz. Programlamaya işlevsel bir yaklaşım izlerseniz, programınızdaki hiçbir modülün kapanma kötülüğü içermeyeceği, hala bazılarınız olmasına rağmen, OO'dan çok daha az olacağı bir ideali hedefliyorsunuz.

Bu, OO'nun dezavantajıdır - bu tür bir kötülüğü teşvik eder, veriyi kapama standartlarını (bir çeşit kırık pencere programlama teorisi gibi) yaparak işlevini yerine getirir .

Tek artı tarafı, başlamak için çok sayıda kapak kullanacağınızı biliyorsanız, OO en azından ortalama bir programcının anlayabilmesi için bu yaklaşımı düzenlemenize yardımcı olacak fikirsel bir çerçeve sunar. Özellikle kapatılmakta olan değişkenler, sadece bir işlev kapatmasında dolaylı olarak ele alınmak yerine kurucuda açıktır. Çok fazla kapama kullanan fonksiyonel programlar, genellikle daha az zarif olmasa da, eşdeğer OO programından daha fazla şifrelidir :)

Bu tür kaplin hakkında:

Bu nesne üzerinde çalışmak üzere bir nesneye yerleşik bir işlev, diğer nesne türlerinde kullanılamaz.

Haskell'de, tip sınıflarına karşı çalışmak için fonksiyonlar yazıyorsunuz - bu nedenle, herhangi bir fonksiyonun üzerinde çalışabileceği , fonksiyonun üzerinde çalıştığı belirli bir sınıfın türü olduğu sürece, üzerinde çalışabileceğiniz birçok farklı türde nesne vardır .

Serbest duran fonksiyonlar, fonksiyonlarınızı A tipinde çalışmak üzere yazmaya odaklandığınızda elde edemediğiniz dekuplajlara izin verir, çünkü fonksiyonun bir A tipi örneğine sahip değilseniz kullanamazsınız. Aksi halde B tipi bir vakada veya C tipi vakada kullanılacak kadar genel olabilir.

Java ve OOP benzeri enkarnasyonlarında, örnek yöntemler (serbest işlevler veya uzatma yöntemlerinin aksine) diğer modüllerden eklenemez.

Yalnızca örnek yöntemleriyle uygulanabilecek arabirimleri düşündüğünüzde, bu bir kısıtlama haline gelir. Farklı modüllerde bir arabirim ve bir sınıf tanımlayamaz ve sonra bunları bir araya getirmek için üçüncü bir modülün kodunu kullanabilirsiniz. Haskell'in tipi sınıfları gibi daha esnek bir yaklaşım bunu yapabilmelidir.

Nesne Oryantasyonu temel olarak Prosedürel Veri Soyutlama ile ilgilidir (veya dikey bir sorun olan yan etkileri ortadan kaldırırsanız, İşlevsel Veri Soyutlama). Bir anlamda, Lambda Matematik, en eski ve en saf Nesne Yönelimli dildir, çünkü yalnızca İşlevsel Veri Özeti sağlar (çünkü işlevlerin dışında herhangi bir yapıya sahip değildir).

Yalnızca tek bir nesnenin işlemleri, o nesnenin veri temsilini denetleyebilir. Aynı tipteki diğer nesneler bile bunu yapamaz. (Nesne Yönelimli Veri Soyutlama ve Soyut Veri Tipleri arasındaki temel fark budur: ADT'ler ile aynı tip nesneler birbirlerinin veri temsilini inceleyebilir, yalnızca diğer tiplerdeki nesnelerin gösterimi gizlenir.)

Bunun anlamı, aynı tipteki birkaç nesnenin farklı veri gösterimlerine sahip olabileceğidir. Aynı nesnenin bile farklı zamanlarda farklı veri gösterimleri olabilir. (Örneğin, Scala'da Maps ve Sets, eleman sayısına bağlı olarak bir dizi ile bir karma değer arasında geçiş yapar, çünkü çok küçük sayılar için bir dizideki doğrusal arama çok küçük sabit faktörler nedeniyle bir arama ağacındaki logaritmik aramadan daha hızlıdır. .)

Bir nesnenin Dışarıdan, sen, olmamalı olamaz , veri temsilini biliyoruz. Bu sıkı kaplin karşıtıdır .

Veri ve fonksiyonlar arasındaki sıkı bağlantı, çünkü her birini diğerinden bağımsız olarak değiştirebilmeniz ve sıkı bağlantı, bunu zorlaştırır, çünkü birisini diğerine habersiz ve muhtemelen değişmeden değiştiremezsiniz.

İşlevde sunulan farklı verilerin, işlevde herhangi bir değişiklik gerektirmesini istemez ve benzer şekilde, bu işlev değişikliklerini desteklemek için üzerinde çalıştığı verilerde herhangi bir değişiklik yapmadan, işlevde değişiklik yapabilmek istersiniz.