Ana içeriğe atla

System.Reflection

Güncel kod geliştirme ortamları ve bu ortamlara ait framework özellikleri artık çok gelişti. Kod veya tasarım artık çok gizli ya da kapalı değil. İçeride (assembly) kullanılan bir sınıf, yöntem ya da tip tanımlaması dışarıdan kolayca izlenebiliyor (tabi ki kod şifrelemeye ihtiyaç duymuyoruz, delikanlı tasarımcı kodunu gizlemez!) ancak bu tür sistemleri (örnek : .Net framework) geliştiren tasarımcıların bir sonraki hedeflerini kestirmek gerçekten zor olabilir.

Bu zorluğa bende birkaç önerim ile katkıda bulunmak istiyorum.

Evet, kodu tasarladık, compile ettik, testlerimizi gözden geçirdik ve herşey uygun. Tasarımı (dll, exe şeklinde) müşterilere (iç ya da dış ) gönderdik. Eğer gönderilen yerde reflection araçları varsa herşey ortada. Tasarımcının gizli dünyasına, yazılım yaparken beyninde kurguladığı ve sonrasında sıfır-bir şekline dönüşecek bir ortama aktarması, bu aktarım sırasında yaşanan sıkıntıları, masada oturmaktan kaynaklanan yorgunluk şikayetleri, sınıfları, yöntemleri, hepsini desteklemediği özellikler, hayalleri, gelecek sürümlere ait bırakılan açık kapılar, duygular, derlemiş olduğu ürünün sahiplenmesine yönelik ruhsal fırtınalar vb. vb.

Evet, bence ilerideki hayal reflection aracı tüm bu saydıklarımı ve sayamadıklarımı da gösterebilmelidir. O zaman sadece tasarımcının neyi, nasıl ve neden yaptığını daha kolay anlayabiliriz. İçinde duygu ve düşünce yok, başka birisinin tasarımı karşımızda! Ne kadar anlaşabiliriz ya da ne kadar sevebiliriz, kestiremiyorum!.

Ben .Net framework Y.X sürümünde bu tür bir yazılımcı-tasarımcı-meta-framework özelliğinin olmasından yanayım. O zaman C:\Windows\System32 dizinine baktığımızda her DLL ya da EXE dosyasında yazanların neler çektiğini, nerelerde zorlandığını, neden en son bu tür bir tasarıma karar verdiğini, duygularını, sınıflarını, değişkenlerini ve kod satırlarını

"NewOfNewReflect.EXE C:\windows\system32\BestCore.DLL -WithFullEmotionSupport"

şeklinde izleyebiliriz.

Buraya kadar okuyup bu özellik neye yarar diye soranlar varsa (ki olabilir), önerim en kısa sürede kod yazmanız olacaktır.

Bu blogdaki popüler yayınlar

Zeki sistemler

Zeki sistemler: Yapay zeka tekniklerini kullanan sistemlerdir. Sistem: Ortak bir amaca hizmet etmek için bir araya gelmiş bir ya da birden fazla elemanın uyum içinde çalışmasıdır. Melez Zeki Sistemler: Bir ya da birden fazla zeki sistemin bir araya gelmesi ve uyum için çalışmasıdır. Neden melez sisteme ihtiyaç var? Birçok iyi sistem bir araya getirilerek daha iyi sistemler oluşturulabilir. Uzman sistemlerdeki kararlılık, Genetik algoritmaların rastgeleliği ve True/False olarak ifade edilemeyen ancak yine de çözüm beklenen durumlarda bulanık sistemlerin kullanılarak "Melez Sistemlerin" tasarlanması birçok soruna çözüm sağlayabilir. Üst Zeki Sistemler: İnsan zekasına biraz daha yaklaşmayı hedefleyen ve şuan üzerinde düşündüğüm, çok daha fazla kaynak okumamı gerektiren sistemlerdir. Bu sistemlerle insan zekasına biraz daha yaklaşılması hedeflenebilir. Üst ( Meta ) Zeki Sistem (ÜZS) ile aynı anda birden fazla yapay zeka tekniği ya da alt sistemler kullanılabilir. Görüntü tanıma t...

Netle Yazılım | e-Defter Şematron Raporu | Sürüm 2.0.1.8.3

Netle Yazılım San. Tic. Ve A.Ş. e-Defter Şematron Raporu Ver 2.0.1.8.3 Açıklama Yasal e-defter dosyaları hazırlandıktan ve imzalandıktan sonra mutlaka XML şema ve Şematron denetimleri ile kontrol edilmelidir. Bu kontrol süreci sonrasında ortaya en az bir hata çıkması durumunda GİB tarafından e-defter dosyaları geçersiz sayılabilir.  Bu kontrollerin çok geniş ve uzun sürebilmesi nedeniyle kontrol süreçlerinde e-defter uyumlu yazılımlar kullanılmaktadır. Netle Yazılım tarafından geliştirilen "Netle-Defter" uygulaması bu kontrolleri fiş girişinde, döneme ilişkin parçalı ya da bütün defter oluşturmada ve GİB'e gönderim öncesinden yapmaktadır. Olası bir sorunda kullanıcı iş akış sistemi ile bilgilendirilerek hatanın giderilmesi beklenmektedir. Şematron denetimleri XML içine bütünleşik şekilde yazılmış ve bunların tam bir liste şeklinde dokümanı yoktu. Bu faydalı bilgileri liste haline getirdik ve 2018 / 3 dönemini esas olarak aşağıdaki açıkl...

Üst (Meta) modeli olan kavramları seviyorum; DocHuman ve RDL (Report Definition Language)

Dochuman süreç yönetim motoru bir veri kaynağını çok farklı biçimlere dönüştürebilir durumda. Bu özellik ile Dochuman veri modeli, RDL gösterim modeline dönüşebiliyor. Modeller arası dönüşümde, geliştirdiğimiz alt sistemler, veriyi bire-bir oranda dönüştürebilme yeteneğinde. Bir rapor var ve bu rapora ilişkin veri girişi yapılacaksa, rapor verileri expression olarak da ifade edilmiyosa geri dönüşüm kısa sürede mümkün olabilir. RDL içinde parametre, sabit değer, veri kaynaklı değer ve görsellerin özelleştirilmesi yeteneği DocHuman form tasarım sistemiyle birebir örtüşmektedir. Bir RDL barkod değeri ile DocHuman barkod değeri binlerce farklı satırlar sonucunda ortaya çıksa da; birbilerini anlayabilen iki sistemin uzlaşması noktasında işler daha kolaylaşacaktır. Bu tür gelişmiş özelliklere rağmen yazılıma her şeyi yapabilir misin diye sorulsa, "derlenmiş ve işlenmeye hazır halimde çok sıfır" var diyebilir.