Olay güdümlü programlama: Ne zaman buna değer?

Tamam, bu sorunun başlığının neredeyse aynı olduğunu biliyorum. Olay tabanlı programlamayı ne zaman kullanmalıyım? ancak bu sorunun cevabı, karşılaştığım olaydaki olayları kullanmam gerekip gerekmediğime karar vermeme yardımcı olmadı.

Küçük bir uygulama geliştiriyorum. Bu basit bir uygulama ve çoğunlukla işlevselliği temel CRUD.

Belirli olaylardan sonra (belirli verileri değiştirirken) uygulama, söz konusu verilerin yerel bir kopyasını bir dosyaya yazmalıdır. Bunu uygulamanın en iyi yolu hakkında emin değilim. Yapabilirim:

• Veriler değiştirildiğinde olayları tetikler ve bu olaylara bir yanıt verir (dosyayı oluşturur). Alternatif olarak gözlemci modelini uygulayın. Bu gereksiz bir karmaşıklık gibi görünüyor.
• Dosya üreten kodu doğrudan verileri değiştiren koddan çağırın. Çok daha basit, ancak bağımlılığın bu şekilde olması yanlış görünüyor, yani uygulamanın temel işlevselliğinin (verileri değiştiren kod) bu ekstra beceriye (yedek dosya oluşturan kod) bağlanması yanlış görünüyor. Ancak, bu uygulama bu kaplin bir sorun teşkil ettiği bir noktaya gelişmeyeceğini biliyorum.

Bu durumda en iyi yaklaşım nedir?

KISS prensibini takip edin: Basit, Aptal veya YAGNI prensibini koruyun: İhtiyacınız Yok.

Kodu şöyle yazabilirsiniz:

void updateSpecialData() {
    // do the update.
    backupData();
}

Veya aşağıdaki gibi bir kod yazabilirsiniz:

void updateSpecialData() {
     // do the update.
     emit SpecialDataUpdated();
}

void SpecialDataUpdatedHandler() {
     backupData();
}

void configureEventHandlers() {
     connect(SpecialDataUpdate, SpecialDataUpdatedHandler);
}

Aksi yapmak için zorlayıcı bir nedenin yokluğunda, daha basit rotayı izleyin. Olay işleme gibi teknikler güçlüdür, ancak kodunuzun karmaşıklığını artırır. Çalışmak için daha fazla kod gerektirir ve kodunuzda olanları takip etmeyi zorlaştırır.

Olaylar doğru durumda çok kritiktir (olay olmadan UI programlama yapmaya çalıştığınızı hayal edin!) Ancak bunun yerine KISS veya YAGNI yapabileceğiniz zaman bunları kullanmayın.

Değişikliğin bir etkiyi tetiklediği basit bir veriyi tanımladığınız örnek, gözlemci tasarım deseni ile mükemmel bir şekilde uygulanabilir :

• bu, uygulanması ve sürdürülmesi tam olay güdümlü koddan daha kolaydır.
• özne ve gözlemci arasındaki bağlantı soyut olabilir, bu da endişelerin ayrılmasını kolaylaştırır.
• bir ila birçok ilişki için idealdir (öznelerin bir veya daha fazla gözlemcisi vardır).

Olay güdümlü yaklaşım, daha karmaşık senaryolar için, birçok farklı etkileşimin olabileceği, çoktan çoğa bağlamda veya zincirleme reaksiyonların öngörülmesi durumunda yatırımına değer (örneğin, bir özne, bazı durumlarda konu veya diğer konular)

Dediğiniz gibi, olaylar sınıflar arasındaki bağlantıyı azaltmak için harika bir araçtır; bu nedenle, etkinlikler için yerleşik destek olmadan bazı dillerde ek kod yazmayı gerektirse de, büyük resmin karmaşıklığını azaltır.

Olaylar muhtemelen OO'daki en önemli araçlardan biridir (Alan Kay'a göre - Nesneler mesaj gönderip alarak iletişim kurar ). Etkinlikler için yerleşik desteğe sahip bir dil kullanıyorsanız veya işlevleri birinci sınıf vatandaş olarak görürseniz, bunları kullanmak beyinsizdir.

Yerleşik desteği olmayan dillerde bile, Observer modeli gibi bir şey için kazan plakası oldukça azdır. Ortak uygulama alanını en aza indirmek için tüm uygulamalarınızda kullanabileceğiniz iyi bir genel etkinlik kütüphanesi bulabilirsiniz. (Genel bir olay toplayıcı veya olay aracısı neredeyse her türlü uygulamada kullanışlıdır).

Küçük bir uygulamada değerli mi? Kesinlikle evet diyebilirim .

• Sınıfları birbirinden ayırmak sınıf bağımlılığı grafiğinizi temiz tutar.
• Herhangi bir somut bağımlılığı olmayan sınıflar, testlerdeki diğer sınıflar dikkate alınmadan ayrı ayrı test edilebilir.
• Somut bağımlılığı olmayan sınıflar, tam kapsam için daha az birim testi gerektirir.

Sen düşünme Eğer "Ah ancak yalnızca çok küçük bir uygulama, bu gerçekten önemli değil cidden bu kadar" , göz önünde bulundurun:

• Küçük uygulamalar bazen daha sonra büyük uygulamalarla birleştirilebilir.
• Küçük uygulamaların, daha sonra başka uygulamalarda yeniden kullanılması gerekebilecek en azından bazı mantık veya bileşenleri içermesi muhtemeldir.
• Küçük uygulamalar için gereksinimler değişebilir, bu da mevcut kodun şifresi çözüldüğünde daha kolay olan yeniden düzenleme ihtiyacına neden olabilir.
• Ek özellikler daha sonra eklenebilir ve mevcut kodun genişletilmesi gerekliliğini sorar;
• Gevşek bağlanmış kodun yazılması genellikle sıkı bağlanmış koddan çok daha uzun sürmez; ancak sıkı bir şekilde bağlanmış kodun, yeniden bağlanmış ve test edilmesi gevşek bağlanmış koddan çok daha uzun sürer.

Genel olarak, bir başvurunun büyüklüğü, sınıfların gevşek bir şekilde bir arada tutulup tutulmayacağı konusunda belirleyici bir faktör olmamalıdır; SOLID ilkeleri sadece büyük uygulamalar için değil, her ölçekte yazılım ve kod tabanları için de geçerlidir.

Aslında, gevşek bağlanmış sınıflarınızı ayrı ayrı test etmek için harcanan zaman, bu sınıfları ayırmak için harcanan ek zamanı dengelemelidir.

Gözlemci modeli, Wikipedia makalesinden çok daha küçük bir şekilde uygulanabilir programlama dillerinizin "geri aramalar" veya "delegeler" gibi bir şeyi desteklediği varsayılarak (veya GOF kitabının) açıkladığından . CRUD kodunuza (genel bir "dosyaya yazma" yöntemi veya boş bir yöntem olan gözlemci yöntemi) bir geri arama yöntemi iletmeniz yeterlidir. "Olay tetikleme" yerine bu geri aramayı yapın.

Ortaya çıkan kod, doğrudan dosya üreten kodu çağırmaktan çok daha az karmaşık olacaktır, ancak ilgisiz bileşenlerin sıkıca birleştirilmesinin dezavantajları yoktur.

Bu, "YAGNI" için ayırmadan ödün vermeden "her iki dünyanın en iyisini" getirecektir.