Altcointurk  

Geri Git   Altcointurk > > >

AELF ($ELF) Blockchain (ANA KONU)
AELF ($ELF) Blockchain (ANA KONU)
Cevapla
 
Seçenekler Stil
17.Eylül.2019, 10:53   #191
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 204
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

🔊 Aelf COO'su ve Kurucu Ortağı Zhuling Chen, Şanghay'da düzenlenen Staking Sonbahar Forum'una katıldı. Farklı paydaşların staking ekonomideki rolleri ve Pos'taki tipik zorluklar hakkında konuşuldu.

Click the image to open in full size.
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
18.Eylül.2019, 10:54   #192
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 204
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Click the image to open in full size.
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
19.Eylül.2019, 16:46   #193
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 204
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 1

Yiqi Zhao tarafından yazılmıştır

Click the image to open in full size.

Bağımlılık enjeksiyonu (dependency injection) nedir?

Geliştirici topluluğu içerisinde, “bağımlılık” olarak adlandırılan bir konsepte sahibiz. Bir programın bir üçüncü parti kütüphanesini kullanması gerektiğinde, bu kütüphaneyi bağımlılık olarak adlandırılabilir. Fakat “enjeksiyon” nereden geliyor?

Bir insana değer bulmak için karşıtına bakmanız gerektiği söylenir. Bağımlılık enjeksiyonunun karşıtı bağımlılık aramasıdır (dependency lookup). Bağımlılık enjeksiyonu ve bağımlılık araması, Kontrolün İnversiyonu (Inversion of Control - IoC) uygulamasının iki yoludur.

IoC ve Bağımlılık Enjeksiyonunun temel amacı bir uygulamanın bağımlılıklarını ortadan kaldırmaktır. Bu, sistemi daha ayrışmış ve bakımlanabilir kılar.

IoC

İlk önce IoC'yi anlamaya çalışalım. Eski bilgisayar programlama günlerine geri dönerseniz program akışı, kendi kontrolünde çalıştırırdı. Örneğin, aşağıdaki akış şemasında gösterildiği gibi basit bir sohbet uygulaması akışını düşünelim.

1- Kullanıcı sohbet mesajı gönderir.

2- Uygulama, diğer taraftan gelen mesajı bekler.

3- Hiçbir mesaj bulunamazsa, 2. adıma gider ya da 4. adıma geçer.

4- Mesajı görüntüler.

5- Kullanıcı çalışmalarına devam eder.

Click the image to open in full size.

Şimdi program akışını yakından analiz ederseniz, bu sıralıdır. Program kendi kendini kontrol ediyor. IoC, programın kontrol akışını yönetecek başka birine devrettiği anlamına gelir. Örneğin, sohbet uygulaması olayını temel alarak yaparsak programın akışı aşağıdaki gibi olacaktır:

1- Kullanıcı sohbet mesajı gönderir.

2- Kullanıcı çalışmalarına devam ediyor.

3- Uygulama olayları dinler. Bir mesaj gelirse, olay etkinleşir ve mesaj alınır ve görüntülenir.

Click the image to open in full size.

Programın akışını görürseniz, sıralı değildir, olayı temel alır. Yani şimdi kontrol tersine çevrildi. Akışı kontrol eden dahili program yerine, olaylar program akışını yönlendirir. Olay akışı yaklaşımı, daha fazla esnekliğe yol açan dolaysız bir başvuru olmadığından daha esnektir.

IOC'nin sadece olaylar tarafından uygulandığı sonucuna varmayın. Kontrol akışını geri arama delegeleri, gözlemci modeli, olaylar, DI (Bağımlılık enjeksiyonu) ve başka birçok yolla delege edebilirsiniz.

DI (Bağımlılık enjeksiyonu) IOC'nin bir alt kümesi iken IOC genel bir ana terimdir. IOC, uygulama akışının ters çevrildiği bir konseptir.

Daha önce bahsedilen iki yöntem, bağımlılık enjeksiyonu ve bağımlılık araması, her yerde kullanabileceğiniz yöntemlerdir.

Servis konumlandırıcısını (service locator) Spring Framework’de duymuş olabilirsiniz. Şimdi Servis konumlandırıcısının bir model karşıtı olduğunu düşünen birçok öncüller vardır. Aslında Servis konumlandırıcısı, bağımlılık aramanın somut bir uygulamasıdır. Servis konumlandırıcısı ve bağımlılık enjeksiyonu fikri esasen zıt olmasına rağmen, MS.DI bağımlılık enjeksiyon yapısını uygularken Servis konumlandırıcısını kullanır.

Eğer Spring’i kullanmadıysanız, sorun değildir.

İkisi arasındaki ilişkiyi açıklamaya çalışalım. Açıkçası, Bağımlılık Enjeksiyonu temel olarak enjekte etme ile ilgilidir. Yığın Taşması (stack overflow) üzerine Bağımlılık Enjeksiyonu konusunda çok ilginç bir cevap vardır. Soru, beş yaşındaki bir çocuğa bağımlılık enjeksiyonunun nasıl açıklanacağıdır:

Bir çocuk kendi başına buzdolabından bir şeyler çıkardığında, sorun çıkartabilir. Kapıyı açık bırakabilirler veya anne ya da babanın sahip olmasını istemediği bir şey alabilirler. Hatta sahip olmadıkları veya süresi dolmuş bir şeyi bile arıyor olabilirler.

Yapmaları gereken şey “öğle yemeği ile içmek için bir şeye ihtiyacım var” gibi ihtiyacı belirtmek ve sonra ebeveyn, yemek için otururken bir şeylerinin olduğundan emin olacaktır.

Bu yüzden doğru yaklaşım, çocuklara neye ihtiyaçları olduğunu sormaktır; o zaman buzdolabından bir şey bulur ve onlara veririz.

Bir benzetme yapacak olursak buzdolabından bir şeyler alan çocuklar bağımlılık aramaya benzer; çocuklara yetişkinler olarak bir şeyler sunduğumuzda, bu bağımlılık enjeksiyonudur.

Bağımlılık enjeksiyonunu ayrıntılı olarak tartışmadan önce, tasarım modellerinin beş prensibini gözden geçirmemiz gerekir (bazı yerler altı hatta yediden bahseder, ancak bunlar temel olarak beştir). Bu serideki 2. bölümde bu ilkelerin ilk çifti incelenecektir.

KAYNAK: https://medium.com/aelfblockchain/ae...1-a95714f41042
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬

Konu KursatAelf tarafından (20.Eylül.2019 Saat 10:45 ) değiştirilmiştir.
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
20.Eylül.2019, 12:29   #194
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 204
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Aelf, Huawei Cloud'a Teknoloji Partneri Olarak Katıldı ve Dijital Dönüşüme Yardımcı Olmak için 2019 Huawei Connected Konferansına Davet Edildi!

Telekom endüstrisinde bir Blockchain sağlayıcısı olarak Aelf iş birlikleri konusunda Huawei ile görüşmelerde

Click the image to open in full size.

18 Eylül 2019'da üç günlük Huawei Connect 2019 Konferansı (HC2019), Şangay Dünya Fuar Kongre ve Gösteri Merkezi'nde ve Şangay Dünya Fuar Gösteri Salonu'nda başladı. Bu konferansın konusu “Gelişmiş Akıl, Aklın Yeni İrtifalarını Sağlar” idi. Açılış konuşmaları, yuvarlak masa toplantıları ve alt forum tartışmaları; Huawei Cloud, Akıllı Bilişim, Bağlantı, Ağ Güvenliği, Akıllı Şehirler, Akıllı Ulaşım, Akıllı Finans, Geliştirici ve Kurumsal Hizmetler ve Devlet İşleri ve Eğitim konusundaki konuşmalar için bir platform sağladı. Bir Huawei Cloud teknoloji ortağı olarak Aelf, Huawei Connect 2019 Konferansı’na ve Akşam Yemeği'ne katılmak üzere davet edildi.

Liang Chen (Huawei Cloud Global Partner İş Birimi Başkanı), Lim Chee Siong (Huawei Cloud Güney Pasifik bölgesinin Baş Pazarlama Yöneticisi), Kevin Teoh (Huawei Cloud Asya Pasifik İş Geliştirme Direktörü) ve Justin Ching Lee (Huawei Cloud Global Partner İş Birimi Menajeri) yemeğe katıldı. Nancy Yan (Huawei Cloud Asya Pasifik Partner İş Birimi Başkan Yardımcısı), Aelf’i bizzat memnuniyetle karşıladı ve katıldıkları için Aelf ekibine teşekkür etti. Aelf Kurucu Ortağı & COO’su Zhuling Chen, akşam yemeğinde Huawei Cloud Teknoloji Partnerlerinin bir temsilcisi olarak kısa bir konuşma yaptı.

“Aelf'in HC2019 endüstri festivaline Huawei Cloud teknoloji ortağı olarak katılması için davet edildiğinden dolayı çok mutluyum. Akıllı dünyanın hızlanmasıyla birlikte, gittikçe daha fazla işletme ve devlet kurumu aklın değerini ve önemini fark etmektedir. Endüstrinin önde gelen merkezi olmayan bulut bilişim platformu olarak Blockchain bulut hizmetlerinin iş birliğini keşfetmek ve optimize etmek, güvenilir bir dijital ekonominin temel taşını oluşturmak ve işletmeler için daha güvenli hizmetler sunmak için Huawei Cloud ile çalışmayı umuyoruz. Güvenilir, verimli ve yüksek kaliteli Blockchain bulut hizmetleri; işletmelerin katlanarak büyümesini mümkün kılıyor.”

Zhuling, Blockchain’in Telekomünikasyon Operatörlerine hizmet etme potansiyeli hakkında Liang Chen (Huawei Cloud Global Partner İş Birimi Başkanı) ile uzun bir görüşme yaptı. Aelf, dünya çapında birkaç önde gelen Telekomünikasyon Operatörü ile görüşmelerde bulundu ve Huawei, global olarak Telekomünikasyon Operatörleri için en büyük global yazılım ve donanım sağlayıcısıdır. Bu partnerlik, iki tarafın da uzmanlıklarını geliştirmeleri için karşılıklı olarak yararlı olacaktır.

Huawei Cloud’un çapraz zincir projesine dahil edilen aelf Enterprise 0.7.0 Beta; tam bir Blockchain sistemi, geliştirme kitleri için destek, web araçları ve programları için destek gibi özelliklere sahiptir. Geliştiriciler; sağlanan geliştirme kitleri ve araçlarına dayalı olarak uygulamaları hızlıca dağıtabilir. Ek olarak Aelf, kullanıcıların işletmelere ve geliştiricilere kolayca güçlü uygulamalar geliştirmelerine yardımcı olmak için iş mantığını ve uygulama geliştirmeye odaklanmalarını sağlayan bir rehber öğretici sunar.

Click the image to open in full size.

Aelf, iş dünyasının kendi kendini geliştirmesi ve refahını ilerletmek için teknoloji ve ileriye dönük bir endüstri perspektifinden yararlanır. Huawei ve Aelf, kurumsal müşterilerine hizmet etmede iş birliği için daha fazla fırsat keşfetmeye devam edecektir. Sektördeki konumumuzu derinleştirip teknolojik avantajları sağlayarak Aelf, Huawei Cloud ile olan geniş kapsamlı iş birliğimizi daha da güçlendirecektir.

Aelf Enterprise Huawei Cloud Adresi --> https://marketplace-intl.huaweicloud...01-129125-0--0

KAYNAK: https://medium.com/aelfblockchain/ae...d-ac97b095886b
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
22.Eylül.2019, 00:13   #195
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 204
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Click the image to open in full size.
Click the image to open in full size.
Click the image to open in full size.
Click the image to open in full size.
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
24.Eylül.2019, 16:57   #196
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 204
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Aelf Çin'de Blockchain’e ve DLT Ulusal Standardı'na Rehberlik Etmeye Yardımcı Oluyor

Aelf, “Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi (Distributed Ledger Technology – DLT) Referans Mimarisi” Ulusal Standartlar Derleme Toplantısına katıldı.

Click the image to open in full size.

20 Eylül 2019'da Sanayi ve Bilgi Teknolojileri Bakanlığı CESI (Çin Elektronik Teknolojisi Standardizasyon Araştırma Enstitüsü) tarafından düzenlenen “Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi Referans Mimarisi” Ulusal Standartlar Derleme Toplantısı Şanghay’da yapıldı. Toplantıya katılmak için Aelf Teknik Ekosistem Direktörü Zongzhe Huang; Çin Halk Bankası’ndan, Çin Menkul Kıymetler Düzenleme Komisyonu’ndan, Nankin ve Fudan Üniversiteleri’nden ve diğer kurum ve kuruluşlardan kıdemli uzmanlarla birlikte toplantıya davet edildi.

Ulusal Standartlar Derleme Toplantısı; Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi Referans Mimarisinin ulusal standardına odaklandı. Toplantıda, aşağıdaki hususlara ilişkin tartışmalar yer aldı:

• Blockchain referans mimarisinin kullanıcı ve fonksiyonel görünümü

• Kullanıcı görünümü roller, alt roller ve etkinlikleri ve roller arasındaki ilişkileri içerir

• Fonksiyonel görünüm, fonksiyonel bileşenleri ve bunların belirli fonksiyonlarını içerir

• Fonksiyonel bileşenler arasındaki ilişkiler

Uzmanlar ve bilim adamları, “Bilgi Teknolojileri Blok Zinciri ve Dağıtılmış Defter Teknolojisi Referans Mimarisi” konulu titiz bir analiz ve derinlemesine gösteri yönettiler. Huang, nihai karar için oy kullanmadan önce tartışmaya aktif olarak katıldı. Uzmanlar ve bilim adamları; kendi görüşlerini paylaştı, farklı endüstri perspektiflerinden revizyon görüşlerini sağladı ve fikir alışverişi yaptı ve bir sonraki adım için hazırlık planını açıkladılar.

Click the image to open in full size.

Gelişen bir teknoloji olarak Blockchain; finansal hizmetler, tedarik zinciri yönetimi, eğlence, akıllı üretim, sosyal refah ve eğitim istihdamı alanlarında geniş bir uygulama alanına sahiptir. Blockchain standardizasyonu; Blockchain anlayışını birleştirmeye, çeşitli endüstrilerdeki Blockchain uygulamalarını yönlendirmeye ve Blockchain'in temel teknik konularını desteklemeye yardımcı olur.

Aelf, Blockchain endüstrisinin standardizasyonuna katkıda bulunmak için hem teknik hem de pratik açıdan endüstri standartları tartışmalarına aktif olarak katılmaya ve endüstri standartlarının iyileştirilmesine katkıda bulunmaya devam edecektir.

KAYNAK: https://medium.com/aelfblockchain/ae...a-4805b538e16a
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
27.Eylül.2019, 10:12   #197
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 204
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 2

SOLID Tasarım İlkeleri

Click the image to open in full size.

Bu serinin 1. bölümünde Bağımlılık Enjeksiyonu ve IoC tartışıldı. Bağımlılık Enjeksiyonu derinlemesine girmeden önce, nesne yönelimli tasarım modelinin beş SOLID ilkesini anlamak önemlidir. Bu bölümde ilk üç ilke incelenecektir.

1) Tek Sorumluluk İlkesi (SRP, Single Responsibility Principle)

> Bir sınıfın değişmesi için hiçbir zaman birden fazla sebep olmamalıdır.

Bir şaka duymuş olabilirsin:

- Hata olmadan kod yazdın mı?

- Evet, daha önce yaptım: Merhaba Dünya.

Bu paragraf bize doğruyu söyler: kod ne kadar basitse, bir hata olması o kadar az olasıdır.

Peki kodu nasıl basitleştiririz? Her kod satırını yazarak tek bir şey yapmak için. Uygulamada, bir sınıfın sadece bir şey yapmasına izin verdik. Ve eğer bu sınıfa basit ve sezgisel bir isim verebilirsek, kodun kendisinin bildirilmesi çok iyi olacaktır. Alibaba’nun Java spesifikasyonunun, bir sınıfın bir tasarım deseni kullanıyormuş gibi adlandırma için gereksinimleri olduğunu hatırlıyorum. Tasarım deseninin adını ismin içinde yerleştirmek gerekir. Şu anda, yorumlar gereksizdir ve kod insanların okuması ve bakımı için kolaydır.

Tek sorumluluk ilkesinin tanımına geri dönelim. Martin, bir sorumluluğu değişimin nedeni olarak tanımlar ve bir sınıf veya modülün değiştirilmek üzere bir ve yalnızca bir nedeni olması gerektiği sonucuna varır (yani yeniden yazılması). Örnek olarak, bir rapor derleyen ve yazdıran bir modül düşünün. Böyle bir modülün iki nedenden dolayı değiştirilebileceğini hayal edin. İlk olarak, raporun içeriği değişebilir. İkincisi, raporun formatı değişebilir. Bu iki şey çok farklı nedenlerle değişir. Tek sorumluluk ilkesi, sorunun bu iki yönünün gerçekten iki ayrı sorumluluk olduğunu ve bu nedenle ayrı sınıf veya modüllerde olması gerektiğini söylüyor. Farklı zamanlarda farklı nedenlerle değişen iki şeyi birleştirmek/eşleştirmek, kötü bir tasarım olacaktır.

Bir sınıfı tek bir endişeye odaklamanın önemli olmasının nedeni, sınıfı daha sağlam ve güçlü kılmasıdır. Yukarıdaki örnekten devam edersek rapor derleme işleminde bir değişiklik olursa, aynı sınıfın bir parçasıysa yazdırma kodunun kırılması daha büyük bir tehlikedir.

Ayrıca bir sınıfın tek sorumluluk ilkesine uygun olup olmadığına karar vermek için bir standart vardır. Bu, sınıftaki öğelerin uygunluğuna bağlıdır. Bir yineleyici uygulayan bir sınıfta yazma fonksiyonuna sahip olamazsınız. Bunun hakkında düşünmeyin. En önemseyeceği panonun boyutunu kontrol etmesidir. Başka bir deyişle, panonun kendisi yineleyicilerin sınıfına dahil edilmemeli, yalnızca bir hizmet olarak var olmalı ve Depo modunu kullanmayı düşünebilirsiniz.

Yüksek korelasyon, yüksek uyum ve işlevde daha küçük bir granülite anlamına gelir.

Burada belirtilen sınıf, bir varlığa veya bir servise başvurabilir. Domain-driven Design kitabında Eric, uygulamadaki nesneleri üç türe ayırır: değerler, varlıklar ve hizmetler. Bir varlık, değerlerin bir kombinasyonu olarak düşünülebilir ve bir hizmet, iş mantığını içeren koddur.

2) Açık Kapalı Prensibi (Open Closed Principle - OCP)

> Sınıflar, modüller ve fonksiyonlar gibi yazılım varlıkları; uzantı için açık olmalı ancak varlığın kaynak kodunu değiştirmeden davranışının genişletilmesine izin verebilecek şekilde değişikliklere kapalı olmalıdır.

Açık Kapalı Prensipten bahsedersek bu, dekoratör modeli aracılığıyla anlaşılması özellikle kolay olan bir tasarım desenidir. Bir senaryo hayal edebiliriz. Bir süpermarkette yazarkasa sistemi veya bir e-ticaret web sitesi yapıyoruz. Her halükârda emtia varlığı vardır. Emtia varlığı, bir GetPrice (FiyatAl) yöntemine sahiptir ve şimdi ürüne bir indirim işlevi eklemelisiniz. Malın sınıf kategorisinin tek sorumluluk prensibine uygun olduğunu varsayarsak, şu anda üç seçenek vardır:

1. Şimdi ihtiyacınız olan işlevselliği sağlamak için arayüze bir yöntem ekleyin.
2. Sınıfın uygulamasını modifiye edin ve yeni özellikler imzalamak ve sağlamak için önceki yöntemi kullanın.
3. Bir sınıfı tekrar oluşturun, önceki uygulama sınıfını kalıt alın (inherit), önceki yönteme bir katman yerleştirin ve yeni bir uygulama sağlayın.

Açık Kapalı Prensibi, üçüncü çözümü seçmemizi önerir. Bunun nedeni arayüzü modifiye ederek, bu arayüzü uygulamak isteyen diğer sınıfların uygulamayı eklemesi gerekir. Bu yeni uygulamanın gereksiz olması muhtemeldir, çünkü tüm ürünler için aynı gün içerisinde indirim yapılması muhtemel değildir. İkinci çözüm, sadece tehlikeli bir operasyondur. Kesinlikle birim testini etkileyecektir (eğer varsa) ve hataların ortaya çıkması gibi büyük bir olasılık vardır. Üçüncü seçenek en güvenli olanıdır. Önceki uygulama için bir dekoratör sağlayabiliriz ve ardından yeni işlevsellik sağlamak için dekoratör çağırabiliriz. Önceki örnekte önceki uygulama, ürünün orijinal fiyatını dekoratörün “indirim dekoratörü” olarak adlandırdığı şeyi döndürmektir ve daha sonra indirimli fiyatı döndürmek için aynı yöntemi çağırır. Önceki uygulama, yapıcı parametreleri vasıtasıyla dekoratöre enjekte edilir. Gerçek kullanım o kadar basit olmayabilir ancak bu, prensibin basit bir açıklamasıdır.

Daha sonra enjeksiyonun birleşik kökü hakkında konuştuğunuzda, tekrar Açık Kapalı Prensipten bahsedeceksiniz.

3) Liskov'un Yerine Geçme Prensibi (Liskov Substitution Principle - LSP)

> Temel sınıflara işaretçiler veya referanslar kullanan fonksiyonlar, türetilmiş sınıfların nesnelerini bilmeden kullanabilmelidir.

Bu en gözden kaçan prensiplerden biri gibi görünüyor.

Sorunlara neden olan “is a” tekniğinin klasik örneği daire-elips problemidir (ya da dikdörtgen kare problemdir). Ancak, ben penguen kullanacağım.

İlk önce, gökyüzünde uçan kuşları gösteren bir uygulama düşünün. Birden fazla kuş türü olacaktır ve bu nedenle geliştirici, yeni kuş türlerinin eklenmesiyle ilgili kodu “kapatmak” için Açık Kapalı Prensibini kullanmaya karar verir. Bunu yapmak için, aşağıdaki soyut Kuş temel sınıfı oluşturulur:

Click the image to open in full size.

BirdsFlyingAroundApp sürümünün büyük bir başarıdır. İkinci versiyon, kolaylıkla başka 12 farklı kuş türünü ekler ve ayrıca bir başarıdır. Yaşasın Açık Kapalı Prensibi! Ancak, uygulamanın üçüncü sürümü penguenleri desteklemek için gereklidir. Geliştirici, Kuş sınıfından kalıt alan yeni bir Penguen sınıfı yapar, ancak bir sorun vardır:

Click the image to open in full size.

Bir geçersiz kılma yöntemi hiçbir şey yapmazsa veya yalnızca bir istisna atarsa, muhtemelen LSP'yi ihlal ediyorsunuzdur.

Uygulama çalıştırıldığında tüm uçan modeller yanlış görünür, çünkü Penguen nesneleri setAltitude yöntemini önemsemez. Penguenler sadece yerde dolaşıyorlar. Geliştirici OCP'yi izlemeye çalışsa da başarısız oldu. Penguen sınıfına uyması için mevcut kodun modifiye edilmesi gerekir.

Bir penguen teknik olarak “kuş” iken, Kuş sınıfı tüm kuşların uçabileceğini varsaymaktadır. Penguen alt sınıfı uçuş varsayımını ihlal ettiğinden, Kuş sınıfı için Liskov'un Yerine Geçme Prensibi’ni karşılamıyor.

LSP'yi İhlal Etmek Neden Kötüdür?

Soyut bir temel sınıf kullanmanın amacı; gelecekte yeni bir alt sınıf yazıp mevcut, çalışan ve test edilmiş bir koda ekleyebilmenizdir. Açık Kapalı Prensibinin özü budur. Ancak, alt sınıflar soyut temel sınıfın arayüzüne uygun bir şekilde bağlanmadığında, mevcut alt kodu gözden geçirmeniz ve hatalı alt sınıfları içeren özel durumları hesaba katmanız gerekir. Bu, Açık Kapalı Prensibinin açıkça ihlalidir.

Örneğin, bu kod parçasına bir bakınız:

Click the image to open in full size.

LSP, kodun Kuş nesnesinin gerçek sınıfını bilmeden çalışması gerektiğini söylüyor. Ya devekuşu gibi bir başka uçamayan kuş türü eklemek isterseniz? O zaman mevcut tüm kodunuzu gözden geçirmeli ve Kuş işaretçilerinin gerçekten Devekuşu işaretçisi olup olmadığını kontrol etmelisiniz.

İki Olası Çözüm

Mevcut kodu modifiye etmeden Penguen sınıfını ekleyebilmek isteyebiliriz. Bu, kötü kalıtım hiyerarşisini LSP'yi karşılayacak şekilde düzelterek sağlanabilir.

Sorunu çözmenin çok iyi olmayan bir yolu, isFlightless adlı Kuş sınıfına bir yöntem eklemektir. Bu şekilde, en azından OCP'yi ihlal etmeden uçamayan kuş sınıfları eklenebilir. Bu, şöyle bir kodla sonuçlanacaktır:

Click the image to open in full size.

Bu gerçekten geçici bir çözümdür. Temel sorunu çözmedi. Sadece sorunun belirli bir nesne için var olup olmadığını kontrol etmenin bir yolunu sağlar.

Uçamayan kuş sınıflarının uçan sınıfları üst sınıflarından kalıt almadığından emin olmak daha iyi bir çözüm olacaktır. Bu böyle yapılabilir:

Click the image to open in full size.

Kuş temel sınıfı, herhangi bir uçan işlevsellik içermez ve FlightfulBird alt sınıfı, bu işlevselliği ekler. Bu, bazı işlevlerin hem Kuş hem de UçanKuş nesnelerine uygulanmasına izin verir. Ancak, uçamayan olabilecek Kuş nesneleri, FlightfulBird nesnelerini alan işlevlere dönüştürülemez.

Bu serideki bir sonraki bölümde, Bağımlılık Enjeksiyonunun son bölümü daha ayrıntılı olarak tartışmadan önce kalan 2 prensip incelenecektir.

KAYNAK: https://medium.com/aelfblockchain/ae...2-c2525376e8e8
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
27.Eylül.2019, 10:47   #198
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 204
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Aelf, BTCManager ile partnerlik kurdu. Yeni partnerlik ile birlikte artık Aelf ile ilgili tüm haberleri https://btcmanager.com/ adresinde bulabilirsiniz.

Click the image to open in full size.
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
30.Eylül.2019, 13:41   #199
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 204
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

aelf Enterprise (Kurumsal) 0.8.0 Beta Resmi Olarak Yayınlandı

Click the image to open in full size.

aelf Enterprise 0.8.0 beta; bütün bir blockchain sistemi, geliştirme kitleri, geliştirme belgeleri ve destekleyici altyapı ve altyapı hizmetlerini içeren eksiksiz ve tam bir blockchain ticarileştirme çözümü setidir.

aelf Enterprise 0.8.0 beta sürümü sistem entegrasyonu

1. aelf Enterprise

• aelf Enterprise v0.8.0 beta
• DevKit v0.8.0 beta

2. aelf Harici Uygulamalar
• aelf blockchain tarayıcı v0.1.6
• aelf tarayıcı MySQL plugin v0.8.0 beta
• aelf kaşifi v0.8.0 beta
• aelf cüzdan v0.8.0 beta
• aelf JS SDK v3.2.17
• aelf JS SDK Çapraz Zincir v1.0.1
• Nodejs v0.1.15’te aelf CLI

3. aelf Tarayıcı Uzantısı V0.8.0 beta

Aelf Enterprise 0.8.0 beta sürümünün Aelf Enterprise 0.8.0 alfa sürümüne kıyasla önemli özellikleri şunlardır:
• Geliştirilmiş stabilite
• Daha eksiksiz ekonomik sistem
• Çapraz zincir kabiliyetinin tam seti
• Daha eksiksiz çapraz zincir destek araçları

Bu güncelleme ve önemli özellikleri

aelf Enterprise v0.8.0 beta:


AEDPOS Konsensüs Mekanizması:
• Rastgele blok sırası
• Üretim bloğu mantığı
• Konsensüs doğrulama ve hile cezası

Ekonomik sistem:
• Teklif ve çoklu imzalama mekanizması
• Üç oylama modeli (parlamento oyu / birlik oyu / referandum)
• Bancor tabanlı TOKEN (çoklu varlık) ticareti
• Düğüm seçimi oylama / değiştirme
• Temettü / ödeme mekanizması

Ana zincir:
• P2P ağı ve düğüm yönetimi
• Ticaret havuzu
• Zincir yönetimi
• Blok / işlem doğrulama ve yönetimi
• Veri depolama
• WebAPI arayüzü
• Komut satırı arayüzü
• SDK geliştirme (Javascript)

Çapraz zinciri:
• Alt zincir ve ebeveyn zincir indeksleme mekanizması
• Çapraz zincir doğrulama ve çapraz zincir transfer

Sözleşme sistemi:
• Çalışma süresi (Runtime)
• Sözleşme Geliştirme SDK
• Sözleşme güvenlik kontrolü
• Sözleşme geliştirme standardı (acs)

Paralel yürütme:
• Kaynak algılama ve gruplama
• Gruplar arasında paralel yürütme
• Çatışma yönetimi

DevKit:
Geliştirici Belgeleri

• Yeni düğüm yapısı
• Yeni çapraz sözleşme çağrıları
• CLI kullanım belgeleri güncellendi
• WebAPI kullanım belgeleri güncellendi, RPC ile ilgili belgeler kaldırıldı


aelf Harici Uygulamalar güncellemesi:

aelf Cüzdanı:

• Çoklu token durumunda işlem kaydı sorgusunun hatası düzeltildi

aelf Kaşif:
• Arayüz yeniden yapılandırma, yüzlerce milisaniyede arayüz yanıtı
• Mantığın kısmı websocket kullanılarak optimize edilmiştir
• İşlem kaydı sorgu optimizasyonu

aelf JS SDK Çapraz Zincir:
• Çapraz zincir JS SDK eklendi

Nodejs’de aelf CLI
• Yeni teklifle ilgili yöntemler eklendi

Entegrasyon özelliklerine giriş:

1. aelf Enterprise
• aelf Enterprise v0.8.0 beta
https://github.com/AElfProject/AElf
— Yüksek Performanslı Akıllı Sözleşme Çalışma Zamanı
— Konsensüs Sistemi
— Çoklu Token Sistemi
— Oylama sistemi
— Çapraz Zincir Sistemi
— Web API

• DevKit
— Boilerplate https://github.com/AElfProject/aelf-boilerplate
— TestKit
— BenchmarkKit
— IDE entegrasyonu
— Belgeler https://docs.aelf.io/
— Öğreticiler https://docs.aelf.io/main/main

1.1 aelf Enterprise v0.8.0 beta

Minimize edilmiş blok zinciri kerneli, DPoS konsensüs mekanizması, akıllı sözleşme sistemi, oylama sistemi, token sistemi ve temel çapraz zincir sistemi dahil olmak üzere tam bir blok zincir sistemidir.

Yüksek Performanslı Akıllı Sözleşme Çalışma Zamanı
• Sözleşme yürütme seviyesi: Protobuf’a dayanarak grpc gibi bir akıllı sözleşme yürütme ortamı uygulandı. Tüm nesnelerin girdi ve çıktıları ve depolanması Protobuf yüksek performanslı serileştirme işlemine dayanır. Durum depolaması, redis gibi yüksek performanslı bir dağıtılmış veri tabanı kullanır.
• Genel sözleşme yapısı: grpc eklentisi ile oluşturulan kodlar, bir grpc sunucusuna eşdeğer performansları gösterir.
• Sözleşme Kontrolü: Bloklar içinde paralel yürütme, AKKA kümeleri üzerinden gerçekleştirilebilir.

Konsensüs Sistemi
• Güvenlik: Gizli Paylaşım algoritması, seçilen tüm düğümlerde dağıtılmış rasgele sayıların üretilmesini sağlayabilir. Her turdaki blok üretim sırası; üretilen rasgele sayılarla belirlenir, böylece düğüm gizli anlaşması ve kötü niyetli davranış olasılığını azaltır.
• Verimli: Düğümlerin ⅔'ü bir bloğu doğruladıktan sonra blok, geri ters çevrilemez blok olur ve veriler çatal tarafından ters çevrilmeden zincire kalıcı olarak sabitlenir.

Çoklu Token Sistemi
Sözleşme sistemine dayanarak Blockchain çapraz zincir sağlayabilen dâhili bir Token Sistemi uygulanır. Tüm varlıklar; zincirler arasında ihraç edilebilir, transfer edilebilir ve kilitlenebilir.

Oylama sistemi
Sözleşme sistemine dayanarak bir evrensel oylama sistemi, işlevseldir ve çevrimiçi yönetişimi ve ikincil gelişmeyi kolaylaştırır.

Çapraz Zincir Sistemi
Zincirdeki herhangi bir verinin zincir boyunca iletecek bir mekanizma sağlar. Sistem, Merkle Ağaç Kökü endeksine dayanarak uygulanır ve tüm sistem çok seviyeli ana yan zincir endeksini gerçekleştirebilir, böylece ölçeklendirme ve dağıtıklaştırma gerçekleştirilebilir.

Web API
ASP.Net Çekirdek sunucusu, yüksek performanslı etkileşimli bir yapı gerçekleştirmek için uygulanmaktadır.

1.2 DevKit
https://github.com/AElfProject/aelf-boilerplate
Geliştirme Şablonları ve Öğreticileri, Geliştirici Kılavuzu, TestKit, BenchmarkKit ve IDE Entegrasyonunu içerir
• Geliştirici Kılavuzları: Aelf sisteminin ve API dokümantasyonunun ayrıntılı bir tanıtımını sağlar
• TestKit: Geliştiricilerin sözleşmeleri hakkında kısa bir test yapmasına izin verir
• BenchmarkKit: Dahili performans testi durumları sağlar
• IDE Entegrasyonu: Geliştiricilerin, geliştirme sırasında akıllı sözleşmelerin hatalarını ayıklamalarına izin verir ve birim test kodu kapsamı istemi sağlar

Geliştiriciler, hızlı bir şekilde Aelf temelli Blockchain sistemleri kurabilir ve Aelf tarafından sağlanan geliştirme kitlerine ve araçlarına dayalı olarak Dapp‘ler oluşturabilirler. ve Aelf’i geliştirici dokümantasyonu aracılığıyla hızlıca tanımaya başlayabilirler.

2. Aelf Harici Uygulamalar
Aelf Blockchain tarayıcı
https://github.com/AElfProject/aelf-block-scan
• Zincir tarama programı, geliştiricilerin zincirdeki verileri zincir dışında kolayca depolamasını ve böylece geliştirici geliştirme maliyetlerini düşürmesini sağlar.
• Uygulamayı ilgili veri tabanı ile eklemek gerekir, topluluk varsayılan MySQL ekleme sürümü olarak aelf-scan-MySQL sağlar.

Aelf Tarayıcı MySQL eklentisi https://github.com/AElfProject/aelf-scan-mysql
• Geliştiriciler, MySQL veri tabanına veri eklemek için zincir tarama programını kolayca kullanabilir
• İşlem, blok, TPS, kaynak veri depolaması varsayılan olarak desteklenir

Aelf Kâşifi https://github.com/AElfProject/aelf-block-explorer
• Blok ve işlem sorguları uygulandı

Aelf Cüzdan https://github.com/AElfProject/aelf-web-wallet
• Yerel olarak depolanan özel anahtar
• Temel token transferi ve işlem kayıtlarını görüntüleme uygulandı
• Aelf sözleşme tokenlerini arayabilir ve ekleyebilir

Aelf JS SDK https://github.com/AElfProject/aelf-sdk.js
• Aelf'in çapraz link/bağlantı transfer arayüzü, geliştiricilerin hızlı bir şekilde başlamasını kolaylaştırmak için kısa ve öz biçimde açıklanmıştır.

Nodejs’de Aelf CLI https://github.com/AElfProject/aelf-command
• Çok fazla sayıda komut istemi sağlanır.
• Hesap oluşturma, blok bilgisi alma, işlem (trading) bilgisi alma ve sözleşmeleri yayınlama gibi işlevler sağlar.

3. Aelf Tarayıcı Uzantısı
https://github.com/AElfProject/aelf-web-extension
• Özel anahtarları yerel olarak depolar ve bir anahtar yönetim kullanıcı arayüzü sağlar
• Eklenti ve uygulama arasında şifreli iletişim sağlar
• AElf ekosistemindeki DAPP işlem imzalarını destekler
• Kullanıcıların uygulama izinlerini görsel olarak yönetmesini destekler

KAYNAK: https://medium.com/aelfblockchain/ae...d-38b41622893e
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
05.Ekim.2019, 11:48   #200
KursatAelf
Soft Fork
 
KursatAelf - ait Kullanıcı Resmi (Avatar)
 
Mesajlar: 204
Konular: 2
Üyelik: 18.Ocak.2019
Twitter: KursatAelf
Tecrübe Puanı: 0
KursatAelf is an unknown quantity at this point
Standart

Aelf Teknik Konuşmalar: Bağımlılık Enjeksiyonu Bölüm 3

Click the image to open in full size.

## Arayüz Ayrıştırma Prensibi (Interface Segregation Principle - ISP)

> İstemciler, kullanmadıkları arabirimlere bağımlı olmaya zorlanmamalıdır.

Bir sınıfın diğerine bağımlılığı asgari düzeyde olmalıdır.

Bu prensibi izleyerek, birden fazla sorumluluk için yöntemleri tanımlayan şişirilmiş arayüzleri önlersiniz. Tek Sorumluluk Prensibinde açıklandığı gibi, sık sık değiştikleri ve yazılımınızın bakımını zorlaştırdığı için çoklu sorumluluk içeren sınıflardan ve arayüzlerden kaçınmalısınız.

Bir çapraz sözleşme çağrısı için Aelf ekibi, AElf Sözleşme Standardı (ACS) adlı bir sözleşme standardı sağladı ve her bir ACS bazı Arayüz tanımlar. Çapraz sözleşme çağrısı yaparken, belirli bir ACS'de hangi arabirimin tanımlandığı konusunda endişelenmenize gerek yoktur. Yalnızca istenen ACS'yi uygulayan bir sözleşme sağlamanız gerekir. Öte yandan her bir sözleşme, birden fazla ACS uygulayabilir. Diğer sözleşmeler tarafından çağrıldığında, yalnızca uyguladığı ACS'lerden biriyle ilgilenebilir. Böylece yalnızca bu ACS'ye dayanırsınız ve bu sözleşmeyi almazsınız. Diğer yöntemler, çapraz sözleşme çağrılarına maruz kalmaktadır. Bu sadece arayüz izolasyonu prensibinin bir açıklamasıdır.

Bağımlılık İnversiyon Prensibi (Dependency Inversion Principle - DIP)

> Yüksek seviyeli modüller düşük seviyeli modüllere bağlı olmamalıdır. Her ikisi de soyutlamalara bağlı olmalıdır. Soyutlamalar, detaylara bağlı olmamalıdır. Detaylar, soyutlamaya bağlı olmalıdır.

Bu tanımın önemli bir detayı, yüksek seviye ve düşük seviye modüllerinin soyutlamaya bağlı olmasıdır. Tasarım ilkesi, adını ilk defa okurken beklediğiniz gibi sadece bağımlılığın yönünü değiştirmez. Aralarında bir soyutlama tanıtarak yüksek ve düşük seviye modülleri arasındaki bağımlılığı böler. Sonuçta iki bağımlılık elde edersiniz:

1.Yüksek seviye modülü, soyutlamaya bağlıdır
2.Düşük seviye, aynı soyutlamaya bağlıdır

Bu, olduğundan daha karmaşık gelebilir. Sonuç olarak Açık/Kapalı Prensibini ve Liskov'un Yerine Geçme Prensibini kodunuza uygularsanız, Bağımlılık İnversiyon Prensibi'ni de takip eder.

Bir kelimeyle: arayüz odaklı programlama. Arayüzü daha düşük-seviye modülüne koyabilir ve daha sonra bu arayüzün üst-seviye modülde uygulanmasını sağlayabiliriz. Farklı üst seviye modüller arasındaki iletişim, temel modüllerdeki arayüzlerle de yapılır. Örneğin, Log’u yüksek seviye bir modül olarak ele alıyoruz. Temel modülde farklı log seviyelerinin yazdırılması için bazı yöntemler sağlayan tek bir ILogger arayüzü vardır. Özel yazdırma uygulaması log modülüne yerleştirilir. Diğer modüller kayıt yapmak için log modülüne dayanabilir, NLog kullanabilirsiniz, ayrıca log4net kullanabilirsiniz, log modülü bir bağımlılık haline gelir ve hangisini kullanacağımız bu bağımlılığı manuel olarak nasıl enjekte ettiğimize bağlıdır. Peki nasıl enjekte ediyorsunuz? Daha sonra Bileşim Kökünü (Composition Root) tartışacağız.

Örnek projede gördüğünüz gibi, yalnızca Açık/Kapalı ve Liskov'un Yerine Geçme Prensiplerini kod tabanınıza uygulamanız gerekir. Bunu yaptıktan sonra sınıflarınız, Bağımlılık İnversiyon Prensibi'ne de uyar. Herhangi bir arayüz soyutlamasını değiştirmediğiniz sürece bu, diğer sınıfları etkilemeden daha yüksek ve daha düşük bileşenleri değiştirmenizi sağlar.

# DI, IoC ve DIP arasındaki fark

Buradaki DI, DI kapsayıcı değil DI teknolojisidir. Autofac, Ninject, vb. geliştirilmesinde kullandığımız bağımlılık enjeksiyon yapısı, DI kapsayıcına aittir.

Bileşim Kökü, bir tasarım desenidir. Bu tasarım desenini kullanmanın anahtarı, Bileşim Kökünün bulunduğu yeri bulmak zorunda olduğumuzdur. Neyse ki, öncekiler bize bir çözüm verdi: uygulama giriş noktasına mümkün olduğu kadar yakın… Peki Bileşim Kökü ne içindir? Kısacası, yapılandırma, bu yanıltıcı olabilir, ancak birleşik kök bir DI kapsayıcısıdır- başka bir deyişle, bağımlı bir ilişki kurar. Yani, bu uygulamada hangi soyut tipin hangi özel tipe tekabül ettiği, bileşim kökünde bir şekilde ayarlanması gerektiğidir. Burada belirtilen soyut tip, C#'da bir arayüz veya soyut bir sınıf olabilir. Aslında, DI uygulama pratiğinde bu şekilde soyutlama yapmak önemli değildir. Soyut türünü yalnızca belirli Tür bağımlılıklarına karşılık gelecek şekilde birleşik kökte ayarlamamız gerekir. Bu ayar doğrudan DI kapsayıcısındaki Register veya AddSingleton gibi yöntemleri çağırabilir. Ancak DI teknolojisinin uygulanması, mutlaka bir DI kapsayıcısının kullanılmasını gerektirmez.

Kombinasyon kökleri kavramını "sondan başlayarak" bakış açısıyla yeniden düşünüyoruz: Üretim için kullanılabilecek eksiksiz bir uygulamanın çok sayıda hizmet içermesi gerektiği düşünülebilir ve bu uygulamanın uygulanmasının gevşek bir şekilde birleştirilmesini istiyorsak, arayüz izolasyon prensibi kullanılacaktır. Bir servisteki diğer servisleri kullanmamız gerektiğinde, kodu yazarken hangi servislerin uygulanacağını bilemeyiz, bu nedenle kodda doğrudan bir soyutlama çağırırız. Uygulama çalıştıktan sonra, soyuta yapılan asıl çağrıdan önce bir montaj süreci olmalıdır. Sözde derleme, koddaki soyut türe dayanır ve çalışma zamanında somut bir uygulama sağlar; bu da soyut türler ve belirli türler arasında manuel olarak bir haritalama ilişkisi kurmamızı gerektirir. Birleştirilen kök, ilişkinin manuel olarak sağlandığı yerdir. En kolay konsol uygulaması, çalıştırmak için her bir bileşen arasında iş birliği gerektirecektir. Temel bileşenlere dayanan birçok türde üst düzey bileşen vardır. Şu anda en yaygın kullanılan, yapıcı enjeksiyonudur. Uygulanabilir yapıcı enjeksiyonuna bir arayüz atamazsınız, manuel olarak yeni bir uygulama oluşturmanız gerekir. Bu işlem, soyut türü ve belirli bağımlılık türlerini ayarlamaktır.

Açık Kapalı Prensibe tekrar bakıyoruz, belirli bir fonksiyonun modifiye edilmesi gerektiğinde, orijinal uygulamayı değiştiremeyiz, ancak dekorasyon modu ile bir realizasyon sağlayabiliriz ve daha sonra kombinasyon kökünde yeni bir uygulamaya ilgili bağımlılığı ayarlayabiliriz. Sadece kodu eklemeniz ve kombinasyon kökünü değiştirmeniz yeterlidir. Yeni uygulamanın sorunları varsa, eski uygulamanın gerekli olmadığını öğrenene kadar istediğiniz zaman geri çekebilirsiniz. Bu gereksiz ilişkiyi ortadan kaldırmak için bir yeniden düzenleme adımı uygulanmaktadır. İnsanlar, özellikle çalışmalarını başkalarıyla uzlaştırdıklarında, güvenilmez olabilirler. Bu nedenle, yeniden yapılanmadan önce yeterli birim testi eklememiz ve hatta uygulama öncesi birim testleri yazmamız gerekiyor. Test Odaklı Tasarım, birim testinin önce yazılmasını gerektirir, ünite testi başarısız olursa, test başarılı olana kadar uygulama güncellenir. Ancak yazılım geliştirme burada sona eriyorsa, Test Odaklı değil, yalnızca İlk Test Tasarımı olarak adlandırılabilir. Tasarımın özü yeniden yapılanmadır ve tatmin edici bir düzeye dek ayrıklaştırmadır ve test durumu, yeniden yapılanmanın fonksiyonu bozmayacağının önemli bir garantisidir.

Bu serinin başında da belirtildiği gibi DI, aslında bir IoC uygulamasıdır, ancak IoC kavramı önerdiği bakış açısına göre daha da yönlendirilmiştir. Birçoğu Hollywood ilkesini duydu: beni arama, ben seni çağıracağım. Bu bir bağımlılık modülü olarak somut bir türdür. Ne zaman ve nasıl çağrılacaklarını önemsemelerine gerek yoktur sadece kendilerinin çağrılması için beklemeleri gerekecektir.

Son olarak SOLID'deki DIP, üst seviye modüllerin temel modüllere dayanmaması, hepsinin soyutlamaya dayanması gerektiğini gösterir. Bu açıdan DIP, soyutlamanın derecesine fazla dikkat eder. Yani, özel uygulama ve kodun şekli budur.

Ancak aşağı yukarı bu üç kavramın bir fikri ifade ettiğini, rafine edilmesi gereken bir şey varsa arayüz odaklı programlama olduğunu düşünebiliriz. Arayüzü en alta koymak için uygulama en üste yerleştirilir.

KAYNAK: https://medium.com/aelfblockchain/ae...3-2c89a6159056
__________________
▬▬ ▮ ▮ ▮ ▬▬ Aelf Resmi Türkiye Grubu ---> https://t.me/aelf_turkish ▬▬ ▮ ▮ ▮ ▬▬
KursatAelf isimli Üye şimdilik offline konumundadır   Alıntı ile Cevapla
Cevapla

Etiketler
aelf, bir, için, olarak, yan

User Tag List

Seçenekler
Stil

Yetkileriniz
Konu Acma Yetkiniz Yok
Cevap Yazma Yetkiniz Yok
Eklenti Yükleme Yetkiniz Yok
Mesajınızı Değiştirme Yetkiniz Yok

BB kodu Açık
Smileler Açık
[IMG] Kodları Açık
HTML-Kodu Kapalı

Forum Jump


Tüm Zamanlar GMT +3 Olarak Ayarlanmış. Şuanki Zaman: 09:26.


Powered by vBulletin® Version 3.8.9
Copyright © 2019 vBulletin Solutions, Inc. All rights reserved.