İlk kez okuduğum Modüllere Ayrıştırma Sistemlerinde Kullanılacak Kriterler Üzerine adlı klasik bir makale var . Bana çok mantıklı geliyor ve muhtemelen OOP'un dayandığı makalelerden biri. Sonuç:

Bu örneklerle, bir sistemin bir akış şeması temelinde modüllere ayrıştırılmasının başlamasının neredeyse her zaman yanlış olduğunu göstermeye çalıştık. ... Her modül daha sonra böyle bir kararı diğerlerinden gizlemek için tasarlandı.

Eğitim ve deneyimsiz görüşüme göre, işlevsel programlama bu makalenin tam tersini tavsiye eder. Anladığım kadarıyla fonksiyonel programlama veri akışını deyimsel kılıyor. Veri, fonksiyondan fonksiyona aktarılır, her fonksiyon verinin yakından farkındadır ve yol boyunca "onu değiştirir" . Ve veri gizlemenin nasıl abartıldığına veya gereksiz olduğuna dair konuştuğu bir Rich Hickey konuşması gördüğümü düşünüyorum, ama kesin olarak hatırlayamıyorum.

1. Öncelikle değerlendirmemin doğru olup olmadığını bilmek istiyorum. FP paradigması ve bu makale felsefi olarak aynı fikirde mi?
2. Katılmadıklarını varsayarak, FP veri gizlememe eksikliğini "nasıl telafi ediyor"? Belki veri gizlemeyi feda ediyorlar, ancak X, Y ve Z'yi kazanıyorlar. X, Y ve Z'nin neden veri gizlemeden daha faydalı olduğu düşüncesini bilmek istiyorum.
3. Veya, aynı fikirde olmadıklarını varsayarak, belki de FP veri saklamanın kötü olduğunu düşünüyor. Öyleyse, neden veri gizlemenin kötü olduğunu düşünüyor?
4. Kabul ettiklerini varsayarak, FP'lerin veri gizleme uygulamasının ne olduğunu bilmek istiyorum. Bunu OOP'da görmek çok açık. privateSınıf dışında kimsenin erişemediği bir alana sahip olabilirsiniz. FP'de bunun bana açık bir benzetmesi yok.
5. Sormam gereken başka sorular olduğunu düşünüyorum ama sormam gerektiğini bilmiyorum. Bunları da cevaplamaktan çekinmeyin.

Güncelleştirme

Neal Ford'un bu konuşmasını , içinde çok alakalı bir kaymaya sahip buldum . Ekran görüntüsünü buraya gömeceğim:

Bahsettiğiniz makale genel olarak modülerlikle ilgili ve yapısal, işlevsel ve nesne yönelimli programlara eşit olarak uygulanacak. Bu makaleyi daha önce büyük bir OOP adamı olan birinden duymuştum, ancak genel olarak programlama hakkında bir makale olarak okudum, OOP'a özgü bir şey değil. İşlevsel programlama, Neden İşlevsel Programlamanın Önemi Olduğu ve sonucunun ilk cümlesi hakkında ünlü bir makale var: “Bu yazıda modülerliğin başarılı programlamanın anahtarı olduğunu savunduk.” Yani (1) 'e verilen cevap hayır.

İyi tasarlanmış işlevler, verileri hakkında ihtiyaç duyduklarından daha fazlasını varsaymazlar; bu nedenle "verilerin tamamen farkında olma" kısmı yanlıştır. (Ya da en azından OOP'ın olduğu kadar yanlış. Yüksek bir soyutlama düzeyinde kesinlikle programlayamaz ve herhangi bir paradigmada sonsuza dek tüm ayrıntıları görmezden gelemezsiniz. Sonunda, programın bir kısmının aslında bilmesi gerekenler vardır. verinin belirli ayrıntıları.)

Veri gizleme, OOP'a özgü bir terimdir ve makalede tartışılan bilgi gizleme ile tam olarak aynı değildir. Makalede yer alan bilgilerin saklanması, yapılması zor veya değişmesi muhtemel tasarım kararları ile ilgilidir. Bir veri formatıyla ilgili her tasarım kararının zor olması veya değişmesi muhtemel değildir ve değişmesi zor veya değişmesi muhtemel her karar bir veri formatıyla ilgili değildir. Şahsen, OO programcılarının neden her şeyin bir nesne olmasını istediğini anlayamıyorum . Bazen, basit bir veri yapısı tek ihtiyacınız olan şeydir.

Düzenleme: Rich Hickey ile yaptığım röportajdan alakalı bir teklif buldum .

Fogus: Bu fikrin ardından - bazı insanlar Clojure'un türleri üzerinde veri gizleme enkapsülasyonu yapmamasına şaşırıyor. Neden veri gizlemeyi bırakmaya karar verdiniz?

Hickey: Clojure'un soyutlamalar için programlamayı güçlü bir şekilde vurguladığını açıklayalım. Yine de bir noktada, birisinin verilere erişmesi gerekecek. Ve eğer “özel” kavramına sahipseniz, ilgili imtiyaz ve güven kavramlarına ihtiyacınız vardır. Bu da bir ton karmaşıklık ve az değer katar, bir sistemde sağlamlık yaratır ve sık sık yapmaması gereken yerlerde yaşamaya zorlar. Bu, basit bilgiler sınıflara alındığında meydana gelen diğer kayıplara ek olarak verilir. Verilerin değişmez olduğu ölçüde, birisinin değişebilecek bir şeye bağlı olabileceği dışında, erişim sağlayabilecek çok az zararı vardır. Pekala, tamam, insanlar bunu gerçek hayatta her zaman yaparlar ve işler değiştiğinde adapte olurlar. Eğer rasyonellerse, Gelecekte uyum sağlamaları gerekebilecek olanı değiştirebilecek bir şeye dayanarak karar verdiklerini biliyorlar. Bu yüzden, bu bir risk yönetimi kararıdır, bence programcılar yapmakta özgür olmalı. Eğer insanlar soyutlamaları programlamak ve uygulama detaylarıyla evlenmek konusunda temkinli olmak istemiyorlarsa, o zaman asla iyi programcılar olmayacaklardır.

... ve muhtemelen OOP'un dayandığı makalelerden biridir.

Gerçekten değil, ama tartışmaya, özellikle de o zamanlar, makalesinde tanımladığı ilk kriterleri kullanarak sistemleri parçalamak için eğitilmiş olan uygulayıcılara ekledi.

Öncelikle değerlendirmemin doğru olup olmadığını bilmek istiyorum. FP paradigması ve bu makale felsefi olarak aynı fikirde mi?

Hayır. Ayrıca, gözlerime göre bir FP programının neye benzediğini açıklamanız, prosedürleri veya işlevleri kullanan diğerlerinden farklı değildir:

Veri, fonksiyondan fonksiyona aktarılır, her fonksiyon verinin yakından farkındadır ve yol boyunca "onu değiştirir".

... “samimiyet” kısmı dışında , kesinlikle samimiyetten kaçınmak için soyut veriler üzerinde çalışan fonksiyonlara sahip olabilirsiniz (ve çoğu zaman yaparsınız). Böylece, bu "samimiyet" üzerinde bir kontrole sahipsiniz ve saklamak istediğiniz şeyler için arayüzler (yani fonksiyonlar) kurarak dilediğiniz gibi düzenleyebilirsiniz.

Bu nedenle, Parnas'ın bilgi gizleme kriterlerini fonksiyonel programlama kullanarak izleyemememizin ve ikinci uygulamada olduğu gibi benzer faydaları olan bir KWIC endeksinin uygulanması ile sonuçlanmamasının bir nedeni olmadığını görüyorum.

Kabul ettiklerini varsayarak, FP'lerin veri gizleme uygulamasının ne olduğunu bilmek istiyorum. Bunu OOP'da görmek çok açık. Sınıf dışında kimsenin erişemediği özel bir alana sahip olabilirsiniz. FP'de bunun bana açık bir benzetmesi yok.

Veriler söz konusu olduğunda, FP kullanarak veri soyutlamaları ve veri tipi soyutlamaları detaylandırabilirsiniz. Bunlardan herhangi biri somut yapıları gizler ve bu somut yapıların soyutlamalar olarak işlevler kullanarak manipüle edilmesini sağlar.

DÜZENLE

Burada, FP bağlamında "verileri gizlemenin" çok yararlı olmadığını (veya OOP-ish (?)) Belirten çok sayıda iddia vardır. Öyleyse, buraya SICP'den çok basit ve açık bir örnek vereyim:

Sisteminizin rasyonel sayılarla çalışması gerektiğini varsayalım. Onları temsil etmek isteyebileceğiniz bir yol, iki tamsayının bir çifti veya listesi olarak: pay ve payda. Böylece:

(define my-rat (cons 1 2)) ; here is my 1/2 

Veri soyutlama görmezden gelirsek, büyük olasılıkla kullandığınız pay ve payda alacak carve cdr:

(... (car my-rat)) ; do something with the numerator

Bu yaklaşımı takiben, rasyonel sayıları manipüle eden sistemin tüm parçaları rasyonel sayının bir olduğunu bilecektir cons- consrasyonel oluşturmak için sayıları toplayacak ve liste operatörlerini kullanarak bunları çıkaracaktır .

Karşılaşabileceğiniz sorunlardan biri, rasyonel sayılarınızın azaltılmış bir şekline sahip olmanız gerektiğidir - tüm sistemde değişiklikler gerekecektir. Ayrıca, oluşturma sırasında azaltmaya karar verirseniz, daha sonra rasyonel terimlerden birine erişirken azaltmanın daha iyi olduğunu ve başka bir tam ölçek değişikliği sağladığını görebilirsiniz.

Diğer bir sorun, varsayımsal olarak, onlar için alternatif bir temsilin tercih edilmesi ve consgösterimi bırakmaya karar vermenizdir - yine tam ölçek değişikliği.

Bu durumlarla başa çıkmak için her türlü mantıklı çaba muhtemelen rasyonellerin arayüzlerin ardındaki temsilini gizlemeye başlayacaktır. Sonunda, böyle bir şeyle bitebilir:

• (make-rat <n> <d>)Payı tamsayı <n>ve paydası tamsayı olan rasyonel sayıyı döndürür <d>.

• (numer <x>)rasyonel sayının payını döndürür <x>.

• (denom <x>)rasyonel sayının paydasını döndürür <x>.

ve sistem artık gerekçelerin ne yapıldığını bilmeyecek (ve artık gerekmeyecek). Bunun nedeni ise cons, carve cdrrationals içkin değildir, ancak make-rat, numerve denom vardır . Tabii ki, bu kolayca bir FP sistemi olabilir. Bu nedenle, "veri gizleme" (bu durumda, veri soyutlama veya daha iyi temsiller ve somut yapıları içine alma çabası olarak bilinir), OO bağlamında, işlevsel programlama veya her neyse.

Ve mesele şu ki ... kişi ne tür "gizlenme" ya da enkapsülasyon yaptıkları arasında ayrım yapmayı deneyebilse de (prosedürel soyutlamalar söz konusu olduğunda, bir tasarım kararını mı saklıyorlar mı yoksa veri yapıları veya algoritmaları), hepsinde aynı tema var: Parnas’ın açıkça belirttiği bir veya daha fazla puanla motive oluyorlar. Yani:

• Değiştirilebilirlik: İstenilen değişikliklerin yerel olarak yapılıp yapılamayacağı veya sistem üzerinden yayılması
• Bağımsız Gelişme: Sistemin ne kadarına paralel olarak iki bölüm geliştirilebilir.
• Anlaşılabilirlik: Sistemden ne kadarının parçalarından birini bildiği bilinmelidir.

Yukarıdaki örnek SICP kitabından alınmıştır, bu yüzden bu kavramların kitapta tartışılması ve sunulması için, bölüm 2'ye bakmanızı şiddetle tavsiye ederim . Ayrıca, ÇB bağlamında Özet Veri Tiplerine aşina olmanızı tavsiye ediyorum, bu da diğer konuları masaya getiriyor.

İşlevsel programlamanın veri gizlemekten yoksun olduğuna dair inancınız yanlıştır. Sadece verileri gizlemek için farklı bir yaklaşım gerektirir. İşlevsel programlamada verileri gizlemenin en yaygın yollarından biri, argüman olarak işlev gören polimorfik işlevlerin kullanılmasıdır. Örneğin, bu işlev

map :: (a -> b) -> [a] -> [b]
map _ [] = []
map f (x:xs) = f x : map f xs

Verilerin yalnızca en dıştaki yapısını görebilir (yani bir listedir), listedeki veriler hakkında hiçbir şey göremez ve yalnızca kendisine iletilen tek bir işlevle veriler üzerinde çalışabilir.

Bir argüman olarak iletilen işlev, listenin içerdiği veri türündeki bir genel yönteme benzerdir. Veriler üzerinde sınırlı bir çalışma şekli sağlar, ancak veri tipinin dahili çalışmalarını göstermez.

Burada bir uzuvya vuracağım ve kavramın FP'de OO'da olduğu gibi alakalı olmadığını söyleyeceğim.

tl; dr; Veri gizlemenin amacı, sorumlulukların gerektiği yerde tutulmasını sağlamaktır ve bilgi sahibi olmadıkları verilerle uğraşan dış aktörleriniz yoktur. FP verilerinde ifadeler tarafından oluşturulur ve bu şekilde verilerle karışamazsınız çünkü bu, oyunun kurallarını tamamen değiştiren birleşik hesaplamalar kadar değişken özellikler değildir.

FP ile olan tecrübelerime göre; kuşkusuz önemsiz olan, iyi / ortak veri modellemeyi belirten bir OO ile keskin bir karşıtlık bulma eğilimindedir.

Bu karşıtlık, OO'da genel olarak verilerinizi temsil edecek şeyleri modellemenizdir. Zorunlu araç benzetmesi:

OO

• AC uygulaması gibi araba hakkındaki ayrıntıları doğru bir şekilde gizleyen bir arabanız var (kayış tahrikli mi yoksa hava basıncı tahrikli mi? Tüketicilerin bilmesi gerekmiyor, bu yüzden saklayın).
• Bu araba nesnesinin, araçla ilgili tüm gerçekleri ve bir araba ile çalışabileceğiniz yolları tanımlayan birçok özelliği ve yöntemi vardır.
• Bu araba nesnesi, genel olarak Arabadan kendi özel uygulamalarını daha da gizleyen bir otomobilin bileşenleri olan ve otomobilin bileşenlerinin birbirleriyle değiştirilebilir olmasına izin veren veri gerçeklerine sahiptir.

Burada dikkat edilmesi gereken şey, bir OO biçimindeki şeyleri modellerken, tamamen Veriyi temsil etmekle ilgilidir. Özelliklere sahip nesneleriniz var, bu özelliklerin çoğu daha fazla özelliğe sahip nesneler. Burada ve burada bu nesnelere bağlı birkaç yönteminiz var, ancak gerçekte tek yaptıkları, nesnelerin özelliklerini bu şekilde karıştırmak ve yine çok veri merkezli modelleme; yani, verilerinizi, verilerinizin bu şekilde değiştirilebilmesi için verilerinizi tüm noktalarına uyacak şekilde yapılandırmaya odaklanarak etkileşime girecek şekilde verilerinizi modelliyorsunuzdur.

FP

• Davranışlarınızı tanımlamanıza izin veren çok sayıda hesaplama var
• Bu davranış ifadeleri, araba davranışlarının birbiriyle ilişkili olduğu, örneğin hızlanan / yavaşlayan bir araba gibi, birbirleriyle ilişkili olma yoluna çevrilebilecek şekilde ilişkilidir.

Sürekli olarak beni etkileyen OO ve FP arasındaki büyük fark, verileri modelleme şeklinizin üzerinde söylediğim gibi. Yukarıda da belirtildiği gibi OO'da verileri veri olarak modelliyorsunuz, FP'de verileri hesaplamalar, ifadeler, algoritmalar olarak modelliyorsunuz, verilerinizin faaliyetlerini gerçeklerinden daha fazla modelleniyor. Temel matematik modellemesini matematiğe düşünün, her zaman verilerinizi üretebilecek bir denklem elde etmek, verinizi neden olan aktivite olarak modelleyen bir denklem elde etmekle ilgilidir, çünkü OO'nun aksine modelleme, sahip olduğunuz verileri temsil etmenin bir yoludur. Yani çok FP ve OO arasındaki ayrımın.

Unutmayın, çok uzun zamandır, çok az miktarda ilkel veri türüyle yaşadığı temel FP dillerinden biri olan LISP. Bu işe yarar, çünkü yaklaşım, verilerinizin karmaşık temsillerini, sisteminizin davranışlarını üreten ve ifade eden hesaplamalar kadar modellemekle ilgili değildir.

FP’de bazı kodlar yazmaya başladığımda, bir şey yapan kod yazmaya başlıyorum, OO’da kod yazmaya başladığımda, bir şeyi tanımlayan modeller yazmaya başlıyorum. Bir şeyler yapmak, ifade olarak FP'de gizlenir, bir şeyler yapmak, OO'da verilerle tarif edilerek maruz kalır, bu verileri gizlemek, söz konusu maruziyeti sınırlar.

Eldeki soruya dönersek, FP veri gizleme hakkında ne diyor, takdir ediyor veya buna katılmıyor mu, etmiyor mu?

Önemli değil, OO'da verileriniz programınızla karıştırılmaktan gizlenmesi gereken cesaret ve önemli parçalardır. FP'de sisteminizin bağırsakları ve bilgilerinin tümü, sistemi ifade eden algoritma ve hesaplamalarda gizlenir. Bunlar tanımı gereği az ya da çok değişkendir, hesaplama ifadelerini değiştirmenin tek yolu makrolar gibi şeylerdir, ama o zaman bile mutasyon tanımları daha fazla karışamayan ifadelerdir.

Burada biraz paradoks var. İşlevsel programlama, işlevlere odaklanır ve sık sık doğrudan ilkel veri türleri üzerinde çalışan işlevlere sahip olsa da, nesne yönelimli programlamaya göre daha fazla veri gizlemeye sahip olma eğilimindedir .

Bu nasıl? Altta yatan verileri gizleyen hoş bir OO arayüzü düşünün - belki de koleksiyonlar (Neredeyse her yerde her şeyi bulmaya çalışıyorum). Koleksiyondaki nesnelerin temelini veya koleksiyonu uygulayan nesnenin türünü bilmeniz gerekmeyebilir, koleksiyonun uyguladığı, yani IEnumerable. Yani veri gizlemeniz var.

İşlevsel programlamada, bir IEnumerable arabirimiyle etkin olarak çalışan, ancak ilkel bir veri türünde (veya herhangi bir veri türünde) çalışan bir işlev yazabilirsiniz. Fakat tür IE sayısız yöntemini hiç uygulamazsa ne olur? İşte anahtar, her zaman "arayüz" için gerekli parçaları oluşturan "yöntemlere" sahip olacaksınız. Ya da verileri verilerle bir araya getirebilir ve işleri OO benzeri bir şekilde yapabilirsiniz.

Her iki şekilde de, OO’da olduğundan daha az veri gizlemeye sahip olmadığınızı fark edin. Herhangi bir tür üzerinde çalışan genel işlevim açıkça bu türdeki verilere erişmiyor - bu, genel işleve parametre olarak iletilen işlevler içinde gerçekleşiyor, ancak genel işlev hiçbir zaman bu işlevlerin içinde verileri görmeyi beklemiyor.

Yani, konu 1'inize gelince, FP ve makalenin gerçekten aynı fikirde olmadığını düşünüyorum. FP'nin karakterizasyonunun veri gizlememesinin doğru olduğunu sanmıyorum. Biri kesinlikle yazarın FP'de tercih ettiği tasarımı uygulayabilirdi.

Madde 4 (2 ve 3, madde 1 için söylediklerime göre cevap vermek mantıklı değildir) farklılık gösterir. Aynı zamanda OO dillerinde de çeşitlilik gösterir ve birçok özel alanda dilin uygulayacağı yerine konvansiyonel olarak özeldir.

Birincisi, bu harika makalenin bağlantısı için teşekkürler, şu ana kadar bunu bilmiyordum ve bana son yıllarda topluluktan diğer bazı yazılım tasarımcıları ile tartıştığım bazı şeyler hakkında harika bilgiler verdi. İşte bu konuda benim fikrim:

Öncelikle değerlendirmemin doğru olup olmadığını bilmek istiyorum. FP paradigması ve bu makale felsefi olarak aynı fikirde mi?

FP tasarımı, veri akışına çok fazla odaklanır (IMHO, makalenin ima edebileceği kadar kötü değildir). Bu tam bir "anlaşmazlık" ise tartışılabilir.

Katılmadıklarını varsayarak, FP veri gizlememe eksikliğini "nasıl telafi ediyor"? Belki veri gizlemeyi feda ediyorlar, ancak X, Y ve Z'yi kazanıyorlar. X, Y ve Z'nin neden veri gizlemeden daha faydalı olduğu düşüncesini bilmek istiyorum.

IMHO telafi etmez. Aşağıya bakınız.

Veya, aynı fikirde olmadıklarını varsayarak, belki de FP veri saklamanın kötü olduğunu düşünüyor. Öyleyse, neden veri gizlemenin kötü olduğunu düşünüyor?

FP kullanıcılarının veya tasarımcılarının çoğunun bu şekilde hissettiğini veya düşündüğünü sanmıyorum, aşağıya bakınız.

Kabul ettiklerini varsayarak, FP'lerin veri gizleme uygulamasının ne olduğunu bilmek istiyorum. Bunu OOP'da görmek çok açık. Sınıf dışında kimsenin erişemediği özel bir alana sahip olabilirsiniz. FP'de bunun bana açık bir benzetmesi yok.

Mesele şu ki - muhtemelen OOP'un işlevsel olmadığını düşündüğünüz, işlevsel olmayan bir şekilde uygulanan birçok OOP sistemini gördünüz. Ve bu bir haksızlık, IMHO OOP ve FP çoğunlukla ortogonal kavramlardır ve mükemmel bir işlevsel OO sistemi oluşturabilirsiniz. FP'deki klasik “nesne” uygulaması, kapaklar kullanılarak yapılır ve nesnelerin işlevsel bir sistemde kullanılmasını istiyorsanız, kilit nokta onları değişmez olarak tasarlamaktır.

Böylece daha büyük sistemler oluşturmak için IMHO, "FP yolunu" terk etmeden makalede "Modülerleştirme 2" altında açıklanan şekilde OO kavramlarını kullanarak modüller, sınıflar ve nesneler oluşturabilirsiniz. En sevdiğiniz FP dilinin modül konseptini kullanacak, tüm nesnelerinizi değiştirilemez hale getirecek ve "her iki dünyanın en iyisini" kullanacaksınız.

TL; DR : Hayır

FP paradigması ve bu makale felsefi olarak aynı fikirde mi?

Hayır değil. İşlevsel Programlama "bilgisayar programlarının yapısını ve elemanlarını kurma tarzıdır, bir hesaplamanın mantığını kontrol akışını açıklamadan ifade eden bir stildir". Akış şemasını takip etmek hakkında daha az şey var ve daha çok akışın kendi başına ortaya çıkmasını sağlayan kuralları oluşturmak gibi.

Prosedürel programlama, bir akış şemasının kodlanmasına Fonksiyonel programlamaya göre çok daha yakındır. Bu, gerçekleşen dönüşümleri ve bu dönüşümlerin kodlarını, tıpkı bir akış şemasındaki akıştaki gibi, sırayla yürütülen prosedürlere dönüştürür.

İşlemsel diller, programın, paylaşılan durumu dolaylı olarak değiştirebilecek bir zorunlu komutlar dizisi olarak yürütülmesini modellerken, işlevsel programlama dilleri, yalnızca argümanlar ve dönüş değerleri açısından birbirine bağlı karmaşık ifadelerin değerlendirilmesi olarak yürütmeyi modellemektedir. Bu nedenle, işlevsel programlar daha serbest bir kod yürütme sırasına sahip olabilir ve diller programın çeşitli bölümlerinin yürütüldüğü düzen üzerinde çok az kontrol sağlayabilir. (Örneğin, Şema'daki bir prosedür çağrısı için argümanlar keyfi bir sırada yürütülür.)

Veri Gizleme

• İşlevsel Programlamanın kendi veri gizleme yöntemleri vardır; örneğin, kapanışları düşünün . Bu, bir kapama içinde kapsülleme yoluyla saklanan veridir. Sadece kapatmanın verilere referans verdiğinden ve kapatılmanın dışına atıfta bulunamayacağınız için, alanların kapatılmış olan başka bir özel veri olması zordur.
• Veri gizlemenin sebeplerinden biri, mutasyon verilerini gizleyerek programlama arayüzünü stabilize etmektir. İşlevsel programlama mutasyona uğramış veriye sahip değildir, bu nedenle çok fazla veri gizlemeye ihtiyaç duymaz.