Benim yaklaşımım. Çekirdek - Motor. - sayfa 135
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Başka bir sorun var. Sınırlı çekirdek elemanlar ve parametreler. Çözümün ne olması gerektiğini biliyorum. Henüz yapmadım.
Bu yüzden soruyorum. Çekirdeğe dikilmiş 21 satırınız varsa, bu çok iyi değil ve bu şekilde düzeltemezsiniz.
Numara. Bu, yapıcı için yazılan harici koddur. Masayı yeniden üretir. Sonra butona tıklıyorum ve tüm bağlantı dosyaları ve motor için önyükleme çekirdeği yazdırılıyor. Sonra her şey çalışır.
Anladığım kadarıyla bu, otomatik bağlantı kodu artı çekirdek kodunun bir kısmını üreten bir otomatik oluşturucu. İlginç bir karar.
Henüz kontrol etmedim.
Benim için çalışıyor. Ancak, bir durdurma tetiklendiğinde satırı kapatmakla ilgili bir sorun var gibi görünüyor. Bazen bir satır kalır. Bu yazdığım kodda kapanan siparişleri tespit etme sorunudur. Tablo burada işe yaramaz.
1. Bu yüzden soruyorum. Çekirdeğe dikilmiş 21 satırınız varsa, bu çok iyi değil ve bu şekilde düzeltemezsiniz.
2. Anladığım kadarıyla bu, otomatik bağlantı kodu artı çekirdek kodunun bir kısmını üreten bir otomatik oluşturucu. İlginç bir karar.
1. Kesinlikle. Bir kurucu sınırlı sayıda elemana sahip olabilir. Bu nedenle, dinamik bir tablo sınırlı sayıda satırdan oluşmalı, ancak aynı zamanda sınırsız olmalıdır. Tek çözüm, özel eklenen parametreler için diziler ve değerlerinin tablo hücreleri arasında kaydırılması.
2. Evet. Yapıcı, sağladığınız koda dayalı olarak motor için bir çekirdek oluşturur. + bağlantı dosyalarını yazdırır. Ardından Kernel'i motora (DRIVE) yerleştiriyorum. Bundan sonra, motor istenen GUI'yi oynatabilir. Eşleştirme dosyaları Expert Advisor'a bağlanır ve onunla etkileşime girmeye başlar.
Son olarak asılsız olmamak için o "Çekirdek"ten bir örnek vereceğim. Daha doğrusu, bir önyükleme dosyasıdır. Birkaç çekirdek var.
KIB koduna göre otomatik olarak yazdırıldığını hatırlatmama izin verin. Daha sonra motora yerleştirilir. Ardından, motor onunla çalışır.
Nikolai, objektif konuşalım. Örneğin, daha önce ele aldığım CCanvas sınıfını ele alalım. Bu yüzden tüm fonksiyonları oradan aldım ve çıkardım. Onları sınıf sarmalayıcıdan bağımsız hale getirdi. Ne kötüleşti? Onlarla çalışmak daha kolay hale geldi. Bu fonksiyonları kullanarak animasyon yaptım. Ondan önce, bu sınıfla neredeyse hiç animasyon görmemiştim.
Peki neden bu zarf?
Ayrıca tuval üzerine çiziyorsunuz. Sadece belirli bir işlevi çağırabilir ve çizebilirsiniz. Ama hayır. Döndün, döndün ve döndün. Öyleyse açıkla - neden?
Evet, çünkü mega uygun. Ancak kendiniz kullanmaya başlayana kadar anlamanız çok zor.
Beni rahat ettirecek şekilde nasıl düşüneceğimi bilmiyorum. Bu nedenle, benim için uygun değil. Sarın, nesne yönelimini gösterin. Gerektiğinde ve gerekmediğinde sınıflandırın...
Kişi, OOP'nin hizmet etmesi gereken mekanizmanın önünde durduğu izlenimini edinir. Yani, mekanizma bütünlük için ve dolayısıyla bloklarının en az sayısı için çaba göstermelidir. Ve OOP, bu blokları herhangi bir nedenle üretmeye zorlar. Bu nedenle mekanizmaların yapısı yırtılır ve iyi çalışmazlar. Ve daha da kötü gelişirler.
Nikolai, mega mekanizmalar yaratmaya başlayın ( Canvas sınıfından 10 kat daha büyük) ve OOP'nin nerede ve nasıl uygunsuz olduğunu anlayacaksınız.
Beni rahat ettirecek şekilde nasıl düşüneceğimi bilmiyorum. Bu nedenle, benim için uygun değil. Sarın, nesne yönelimini gösterin. Gerektiğinde ve gerekmediğinde sınıflandırın...
Kişi, OOP'nin hizmet etmesi gereken mekanizmanın önünde durduğu izlenimini edinir. Yani, mekanizma bütünlük için ve dolayısıyla bloklarının en az sayısı için çaba göstermelidir. Ve OOP, bu blokları herhangi bir nedenle üretmeye zorlar. Bu nedenle mekanizmaların yapısı yırtılır ve iyi çalışmazlar. Ve daha da kötü gelişirler.
Nikolai, mega mekanizmalar yaratmaya başlayın ( Canvas sınıfından 10 kat daha büyük) ve OOP'nin nerede ve nasıl uygunsuz olduğunu anlayacaksınız.
Sözleriniz tek bir şey söylüyor:
...
Nikolai, OOP'ye olan aşkının soyut sebepler dışında neredeyse hiçbir şeyle haklı çıkmadığı hiç aklına geldi mi?
Diyelim ki, bu OOP'yi kullanarak dev mekanizmalar yarattıysanız, neden bu kadar çok ihtiyacınız olduğu açık olurdu. OOP'ye neden ihtiyacınız olduğunu özellikle doğrularsınız. Ancak, nispeten küçük mekanizmalar yaratıyorsunuz. Bir veya başka bir yaklaşımın dezavantajları ve avantajları hakkında sonuç çıkarmak için yeterli kod yoktur. Ama hala OOP hakkında konuşmaya devam ediyorsun. OOP'nin sadece bir araç olduğu ve kendi başına bir anlam ifade etmediği göz önüne alındığında. Yani yapılacak bir mekanizma yoksa OOP'a gerek yoktur. Ve eğer bir mekanizma varsa, o zaman yeterince ciddi olmalı, böylece onu yaratırken OOP gerekli.
Çoğu FKÖ savunucusu ciddi bir şey yapmıyor. Sadece küçük eşyalar. Ancak, FKÖ'ye olan inançları sarsılmaz. Çok daha ciddi mekanizmalar yaratan diğerleri, OOP'nin büyüklüğü hakkında çok daha az bağırıyorlar. Hatta bazıları eleştiriyle konuşuyor (birkaç kez oldu).
Yani, argümanınız sadece teoriyle değil, pratikle de desteklenmelidir. Örneğin, çözümleri ve pratikteki nüanslarını karşılaştırabildiğimiz için OOP'nin GUI geliştirmedeki avantajları hakkında Anatoly ile tartışabilirim. Ama seninleyken, tartışmayı geri çeviremem çünkü onu anlamayacaksın. Duyacaksınız ama anlamayacaksınız (alınma). Ve Anatoly, tam tersine, çok iyi anlayabilir. Küresel mekanizmalar yaratma deneyimindeki farklılık, yanlış anlaşılmanın ana nedenidir.
not. Bir uygulayıcı olarak size şunu söyleyeceğim: Yaklaşım, belirli bir programcının beyin potansiyelini en üst düzeye çıkaracak şekilde olmalıdır. Kendim için böyle bir yaklaşım buldum.