Büyük bir kod tabanının uzak kısımları arasına veri akışı eklemeyi kolaylaştırabilir miyiz?

Büyük sistemlerde değişiklik yaparken, genellikle bir işlevsellik parçasının başka bir parçadan bazı veriler alması gerektiği problemiyle karşı karşıyayım, ancak muhtemelen olay dinleyicileri, ertelenmiş çağrılar, Bu şekilde basit bir değişiklik hızlı bir şekilde balonlanabilir.

Yossi Kreinin'in http://www.yosefk.com/blog/i-want-a-struct-linker.html adresindeki blog yayınından bir alıntı :

Çok geçtiğiniz bir tür veri yapınız var. Yakında, yapı ile ilgili en değerli şey, tuttuğu veriler değil, kıllı bir kontrol akışı boyunca tamamen kullanılabilir olması.

Global değişkenler, kodun uzaktaki koda "bağırmasını" sağlamanın klasik bir yoludur, ancak sorunlu oldukları bilinmektedir. Dinamik olarak kapsamlandırılmış değişkenler daha kısıtlı bir yöntemdir, ancak bunlar da sorunludur.

Bu sorunu çözmeye yönelik herhangi bir programlama dili araştırması var mı? Statik kontrol, kolay birim testi ve diğer güzellikler sunarken, büyük bir kod tabanına beklenmedik veri akışları eklemeyi kolaylaştırabilir miyiz?

CDI (Bağımlı Bağımlılık Enjeksiyonu) AKA IoC'den (Kontrolün Tersine Çevirilmesi) bahsediyorsunuz. Java JSF ve Spring Framework bazı örneklerdir. ASP.NET MVC, Unity gibi eklentilere sahiptir. Javascript, birçok modern JS çerçevesinde görülen enjeksiyon davranışına sahip RequireJS gibi kütüphaneleri kullanan yapıları düzenlemeye başlıyor. Bu, yerel ve uzak uygulamaları bağlamak içindir.

Ağlar arasında gevşek bağlantı için şirketler, Web Hizmetlerini SOAP, REST, AJAX veya RPC ile düzenli uzaktan arama yöntemiyle kullanmayı sever. Java'da dağıtılmış hizmetler oluşturmak için JAX-WS veya .NET WCF kullanabilirsiniz. Daha sonra bunları bir servis veriyolunda veya herhangi bir dilden veya platformdan "veri akışı" olarak istemci olarak sıralayabilirsiniz. Ruby, Python, Scala, Java, C #, ... bir şey.

Gevşek bağlantı sorunları bölmenize ve fethetmenize olanak tanır ve hizmetler genellikle veri çekmek için bir veritabanına giriş noktasıdır. Merdivene çıkarken Message Queue adlı canavara sahibiz. Bu yol işletme ve altyapı tipi çerçevelere yol açar.

Projeniz hiçbir ağda ısrar etmiyorsa, tek bir uygulamada yüksek veri akışı için tasarlanmış Scala, Akka, NodeJS vb. Diller vardır. Ayrıca karmaşık projeler için daha önce bahsedilen teknolojilerin bir kısmı veya tamamı ile birlikte çalışırlar. Örneğin, Scala bir veri kaynağından bir çeşit "global veri" çekmek için JAX-RS REST servisleriyle kullanılabilir ve IoC dahili kablolaması için Spring'e sahip olabilir. JBoss, .NET ve MuleESB gibi GUI araçlarında birçok iş yürütme veya iş akışı çerçevesi de vardır. Geliştirme sırasında, Eclipse ve Netbeans hizmetleri görsel bir akış şeması ekranında sürükleyip bırakmanıza izin verir.

Son olarak, Java'nın hala Singleton çekirdekleri var. Çalışma zamanında yöntemlerinizi ayarlamak için proxy veya yansıma çerçeveleri kullanın. Ama dürüst olmak gerekirse, bu 1999.

Bir kullanıcıya saat dilimine göre bir mesaj göndermek için bu kadar çok çağrı yapıyorsanız, bence, muhtemelen kullanıcının gördüğü aynı etkiyi elde etmenin 2 adımlı bir yolu vardır. Ama evet, CDI çerçeveleri varolan diller tarafından, bahsettiğiniz tüm esnek güçleri veren bir ceket gibi giyilir. Programımın bilinçaltı olarak adlandırmayı, kirli işlere sorunsuzca bakmayı seviyorum.

Bunu büyük ölçekte yapmanın en basit yolu aslında bir çeşit veri kapsülleme API'sı kullanmaktır. Bu bir NoSQL deposu olabilir veya kapsüllenmiş bir RDBMS olabilir (veya aslında aynı uygulamada farklı zamanlarda ve yerlerde olabilir - uzun vadeli bir RDBMS işlememenin bir nedeni yoktur. depolama ve kısa süreli durum kontrolünü yöneten bir NoSQL db). Hatta bir dizi singleton nesnesi bile olabilir.

Veri yapılarınız bir şekilde tarafsız bir şekilde, yönetilen bir şekilde kullanılabilir hale getirilebilir. LedgerSMB ile aldığımız yaklaşım budur (ancak esasen saklanan tektonlar için birkaç yarı küresel değişkenle, ancak yine bunlar yönetilir, doğrudan nesneyi saklamayı seçtik çünkü değişkenlerin yönetimini biraz daha kolay hale getirdi ancak sonra bunların hepsi 4).

Tabii ki herhangi bir yaklaşımın ödünleşimi vardır ve bu ödünleşimleri kaldıramazsınız. Anahtar, deneklerin ne olduğuna bakmak (yönetim - performans vs kod temizliği vs potansiyel kodlama tuzakları) ve uygulamanız için en iyi olana dayalı bir karar vermektir.

Kelimeleri kullanırsanız (veya alıntı yaparsanız)

hairy flow of control

sonra kod gerçekten bir karışıklık olduğunu varsayalım. Hemen bırakmalısın. Endişeleri modülerleştirme / ayırma kullanırsanız, "tüylü kontrol akışı" diye bir şey yoktur. Kodunuz basitlikten yoksundur, bu da global değişkenlere başvurduğunuz gerçeği ile kısır değildir :-).