JS ILE FONKSIYONEL PROGRAMLAMA
Object-Oriented Programlamanın Unutulmuş Tarihi — 7
Object-Oriented Programlama acaba ilk başta bu programlama paradigmasını kuran kişilerin kafasında ki yapımı, yoksa şu anda bambaşka bir şekilde anlaşılmış farklı bir şekilde OOP uygulanıyor. Acaba Java, C++ veya .NET Object-Oriented Programlamayı farklı mı yorumladılar ?
Bu yazıyı daha önceden yazmış olduğum Object-Oriented Programlamanın Unutulmuş Tarihi-1 , Tarihi-2, Tarihi3, Tarihi4, Tarihi5 ve Tarihi6 yazılarının devamıdır.
Not: Eric Elliott, kitabından okuduğum The Forgotten History of OOP blog yazısı Object Oriented nasıl bir düşünce yapısı ile ortaya çıktığı nasıl başka konulara ve önceliklere evrildiği açısından beni etkiledi. Bu yüzden bu blog yazısını çevirerek anlatmaya çalışacağım, tabi araya kendi notlarımı da ekliyorum 😃.
Bir önceki yazıda OOP Unutulmuş Tarihi6 , Alan Kay’ın asıl aklındaki yaklaşıma çağrışım için OOP(Object Oriented Programming) yerine → MOP(Monitoring Oriented Programming) kullanmak daha iyi bir çağrışım yapabilir şeklinde yazmıştık.
İyi Bir MOP(Monitoring-Oriented Programming) Nasıl Olmalı?
Çoğu modern yazılımda,
- UI ‘dan sorumlu, Kullanıcı etkileşiminden sorumlu kısım
- Uygulama State Yönetmekten sorumlu kısım
- Sistem ve Network I/O yönetmekten sorumlu kısım
Bahsedilen kısımlar(sistemler), event listener ile ağ durumu, UI bileşen state durumları, Uygulama durumları vb kısımları dinlemek ve gerekli aksiyonları almak için uzun-süre yaşayan processlerdir.
İyi bir Monitoring-Oriented Programlama gerçekleştirebilmek için sistemdeki bileşenlerin birbirlerine direk ulaşıp manipüle etmek yerine birbirine mesaj gönderimi yöntemi ile ulaşması şeklinde olmalıdır.
Kullanıcı bir kaydetme düğmesine tıkladığında, bir uygulama durumu bileşeninin yorumlayabileceği ve bir durum güncelleme işleyicisine (pure reducer) aktarabileceği bir “KAYDET” mesajı gönderilebilir.
Durum güncelledikten sonra, durum bileşeni bir UI bileşenine “STATE_UPDATED” mesajı gönderebilir, bu da durumu yorumlayacak, UI’nin hangi bölümlerinin güncellenmesi gerektiğini birleştirerek ve güncellenmiş durumu alt bileşenlere iletecektir.
Bu konu da daha detaylı bilgi almak için. Flux Mimari Örüntüsü yazımı okuyabilirsiniz.
Ağ bağlantısı bileşeni, kullanıcının ağdaki diğer bilgisaylar ile ilgili iletişimini ve uzak makinede bu UI state iletilip, kaydedilmesi veya çekilmesi ve UI gösterilmesi işleminden sorumlu olur.
Asıl mantık bileşen(sistemlerin) birbirlerin işlevlerinden ve ayrıntılarından haberdar olmaması önemlidir. Her modül bireysel kaygılar ile vereceği hizmeti mesaj yoluyla alarak işletmekten sorumlu olmalıdır.
Birlikte çalışabilmeleri için standartlaştırılmış arayüzler üzerinde çalışmalıyız. Arayüz tatmin edici olduğu sürece, aynı şeyi farklı şekillerde yapabilen güncellemeleri veya tamamen farklı gerçekleştirimleri aynı mesajlarla yapabilirsiniz. Bunu çalışma zamanında bile yapabilirsiniz ve her şey düzgün çalışmaya devam eder. (Not: Bu kısımda örneğin Backend API ile iletişimde GraphQL → Query/Mutation üzerinden Schema Mesaj ile bir çok işi dinamik ve runtime değiştirilebilir yapılabilir.)
Aynı yazılıma ait bileşenlerin aynı makinede yer almasına bile gerek yoktur. Sistem decentralized bir biçimde çalıştırılabilir. ( Not: Bu konuşulan bana biraz React Server Component gelen kabiliyetleri hatırlatıyor) . Bunun yanında veri depolama kısmı bile decentralized bir biçimde ağ üzerinde dağıtık bir şekilde tutulabilir. (Örneğin IPFS)
OOP(Object-Oriented Programlama) Arpanet esinlenerek geliştirilmiştir. Arpanet önemli bir hedefide decentralized ağ üzerinde oluşacak ataklara karşı dayanıklı bir sistem geliştirmektir. (Stephen J. Lukasik Why the Arpanet Was Built”)
İyi bir MOP (Monitoring-Oriented Programming) sisteminde internetin sağlam bir şekilde işletilebilmesi için uygulamalar çalışırken bileşenlerin değiştirebilir olmalıdır. Örneğin uygulama çalışmasına telefonundan devam ederken offline olsa bile uygulamanın çalışmaya devam etmesi (Not: Service Worker- PWA — Progressive Web App) . Örneğin veri merkezi bir anda çöksede fonksiyonların işlerine devam etmesidir.
Günümüz teknolojisi ve gereksinimleri (Dağıtık ve Serverless Çalışma İhtiyacı) artık yazılım dünyasının başarısız sınıf kalıtım (Class Inheritance) deneyini bırakıp, başlangıçtaki OOP ruhunu tanımlayan matematik ve bilim ilkelerini dönmenin zamanı.
Not: JavaScript ile Modern UI Framework, Görselleştirme Kütüphaneleri veya Yapay Zeka konuları biz geliştiricileri bu yönde ilerlemeye zorlayacaktır.
Uyum içinde çalışan MOP ve işlevsel programlama ile daha esnek, daha dayanıklı, daha iyi oluşturulmuş yazılımlar oluşturmaya başlamanın zamanı geldi.
Referanslar
Okumaya Devam Et 😃
Bu yazının devamı veya yazı grubundaki diğer yazılara erişmek için bu linke tıklayabilirsiniz.
