“Karma” dillerde tasarım: nesne yönelimli tasarım mı, yoksa işlevsel programlama mı?

Son birkaç yıldır, kullanmak istediğim diller giderek daha "işlevsel" hale geliyor. Şimdi bir çeşit "melez" olan dilleri kullanıyorum: C #, F #, Scala. Uygulamamı etki alanı nesnelerine karşılık gelen sınıfları kullanarak tasarlamayı ve bunun kodlamayı daha kolay, daha çakışık ve daha güvenli hale getirdiği işlevsel özellikleri kullanmayı seviyorum (özellikle koleksiyonlarda veya işlevleri geçerken).

Ancak iki dünya tasarım desenlerine gelirken “çatışıyor”. Son zamanlarda karşılaştığım özel örnek, Gözlemci modelidir. Bir üreticinin, bir öğe oluşturulduğunda veya değiştirildiğinde başka bir kodu ("tüketiciler / gözlemciler", bir DB depolama alanı, bir kaydedici vb.) Bilgilendirmesini istiyorum.

Başlangıçta böyle "fonksiyonel" yaptı:

producer.foo(item => { updateItemInDb(item); insertLog(item) })
// calls the function passed as argument as an item is processed

Ama şimdi daha "OO" yaklaşımını kullanmam gerekip gerekmediğini merak ediyorum:

interface IItemObserver {
  onNotify(Item)
}
class DBObserver : IItemObserver ...
class LogObserver: IItemObserver ...

producer.addObserver(new DBObserver)
producer.addObserver(new LogObserver)
producer.foo() //calls observer in a loop

İki yaklaşımın yanlısı ve olumlu yanları nelerdir? Bir zamanlar bir FP guru'nun tasarım desenlerinin sadece dilin sınırlamaları nedeniyle olduğunu söylediğini duydum ve bu yüzden fonksiyonel dillerde çok az var. Belki bu bir örnek olabilir?

EDIT: Benim özel senaryoda ihtiyacım yok, ama .. fonksiyonel şekilde "gözlemci" kaldırma ve ekleme nasıl? (Yani kalıptaki tüm işlevsellikleri nasıl uygularsınız?) Mesela yeni bir fonksiyon mu geçiyorsunuz?

Bu, çağıran nesne için endişe sınırı dışında bir görevi yerine getirme kavramını taşıyan iki farklı yaklaşımın iyi bir örneğidir.

Bu örnekte fonksiyonel yaklaşıma gitmeniz gerektiği açık olmakla birlikte, genel olarak, çağrılan nesnenin sergilemesi gereken davranışın ne kadar karmaşık olduğuna bağlı olacaktır. Kendinizi sık sık benzer mantığı yeniden uyguladığınızı bulacağınız ve işlev üreteçleri açıkça ifade etmek için kullanılamadığı karmaşık bir davranış meselesiyse, muhtemelen sınıf kompozisyonuna veya mirasa gitmek isteyeceksiniz. mevcut davranışı geçici olarak yeniden kullanma ve genişletme konusunda biraz daha özgür olmalısınız.

Ancak gözlemlediğim bir model, genellikle geliştiricilerin başlangıçta fonksiyonel yaklaşıma gittikleri ve ancak daha ayrıntılı davranış talebi ortaya çıktığında, sınıf temelli bir yaklaşıma gitmeye karar verdikleridir. Mesela, Django'nun faydalar ve gereksinimler belirginleştikten sonra fonksiyon tabanlı görünümlerden, şablon yükleyicilerinden ve test koşucularından sınıf tabanlı olanlara gittiğini biliyorum, ancak bundan önce değil.

İşlevsel versiyon çok daha kısa, bakımı daha kolay, okunması daha kolay ve genellikle akla gelebilecek her açıdan büyük ölçüde üstündür.

Her ne kadar çoğu , her şeyden çok OOP'ta Gözlemciler gibi özelliklerin eksikliğini telafi etmek içindir. Bunlar fonksiyonel olarak çok daha iyi modellenmiştir.

"FP gurunuz" kısmen haklıdır; Birçok OO paterni fonksiyonel şeyler yapmak için hack'tir. (Az sayıda FP dilinin bunun en iyi ihtimalle şüpheli göründüğünün nedeni olduğunu iddia ediyor.) Gözlemci ve Strateji kalıpları birinci sınıf işlevleri taklit etmeye çalışıyor. Ziyaretçi Deseni, desen eşleşmesini simüle etmek için bir hack'tir. Senin IItemObserversadece kılık değiştirmiş bir işlev. Bir öğeyi alan diğer herhangi bir işlevden farklı olduğunu iddia etmek size hiçbir şey satın almaz.

Nesneler sadece bir tür veri soyutlamasıdır. Bu makale bu konuya ışık tutmaya yardımcı olacaktır. Nesneler faydalı olabilir, ancak her şeye uygun olmadıklarını bilmek önemlidir. Bir ikilik yok; sadece doğru iş için doğru aracı seçme meselesidir ve hiçbir şekilde işlevsel programlama nesnelerden vazgeçmenizi gerektirmez. Bu bir yana, fonksiyonel programlama sadece fonksiyonları kullanmaktan daha fazlasıdır. Aynı zamanda yan etkileri ve mutasyonu en aza indirmekle de ilgilidir.

Soruyu gerçekten cevaplayamıyorum çünkü fonksiyonel dillerde iyi değilim; ama bence işe yarayan şey olduğu sürece yaklaşım konusunda daha az kaygılanmalısın. Anladığım kadarıyla, gelecekte daha fazla dinleyici eklemediğiniz veya yürütme sırasında dinleyicileri değiştirmediğiniz sürece, Gözlemci modelini burada çok iyi atlayabilirsiniz.

Tasarım modellerinin OO dillerinde "sınırlamaları" oluşturduğuna katılmıyorum. OOP özelliklerini iyi kullanmak için oradalar. Çok biçimlilik ve kalıtım sınırlama değil özelliklerdir. Tasarım desenleri, esnek tasarımı desteklemek için bu özelliklerden yararlanır. Bir OO'da kesinlikle OO olmayan bir program yapabilirsiniz. Çok dikkatli bir şekilde, durumu olmayan ve FP'yi taklit eden nesneler içeren bir programın tamamını yazabilirsiniz.