Benim yaklaşımım. Çekirdek - Motor. - sayfa 138
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
"FKÖ destekçilerinin yaratıcı potansiyelinin genişletilmesi", Vereshchagin, Tuval üzerine yağlıboya
Bilgilendirici yazılar için herkese teşekkürler.
Bugün EA ve motor arasındaki bağlantıyı kaynaklar aracılığıyla test edeceğiz. Yeni tamamlandı. Test cihazında da çalışmalı.
CCanvas sınıfıyla çalışıyorsunuz. Gelişiminizde yalnızdır.
Sınıf sistemin bir parçasıdır. O BİR ise, sistem yoktur.
O zaman neden sınıf nesneleri yaratıp işlevlerine OOP kurallarına göre erişelim?
ONE sınıfla çalışmak için PRATIK OOP'a ihtiyacınız yoktur.
Ancak, ONE sınıfıyla çalışırken OOP kullanıyorsunuz. Yine de bu SÖZLÜK.
Peter, OOP'ta, birbirine bağlı olmayacak birçok nesneyle çalışabilmek için sınıf nesneleri oluşturulur. CCanvas ile çalıştığınızda ve bir grafiğiniz olduğunda, her şey yolundadır, burada OOP gerçekten gerekli değildir. Ancak farklı alanlarda birkaç grafik görüntülemeniz gerektiğinde, OOP olmadan ve birkaç CCanvas örneği oluşturmadan bunu yapmak zaten zordur.
Veya başka bir örnek. Geçenlerde, aynı anda birden fazla enstrümanla işlem yapabilmesi için prosedürel bir EA'yı değiştirmem istendi (aynı grafikte başlatıldı). Prosedürel bir tarzda, aynı anda farklı semboller üzerinde bağımsız olarak ticaret yapmasını sağlamak çok uzun ve zor bir numara alacaktır. Tüm prosedür kodunu bir sınıfa yerleştirdim ve bunun üç örneğini oluşturdum. Her birine, çalışan bir sembol vb. dahil olmak üzere ayrı bir ayar seti verildi. Kod, ilk seferde olması gerektiği gibi çalıştı. Kullanıcı mutluydu.
Özünde sen bile OOP kullanın. Bunu dolaylı olarak yapmanıza rağmen:
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.
Çekirdeklerinizin her biri, OOP terimleriyle bir sınıfın örneğidir. Ve buna ne derseniz deyin, ancak OOP'nin bir unsurudur. Ancak ne yazık ki, bu ev yapımı öğe, kavramsal güç açısından, binlerce sonuncu olmayan zihin tarafından halihazırda icat edilmiş ve cilalanmış olandan daha düşüktür.
Ne millet, Peter'ı OOP'nin faydalarına ikna etmeye mi çalışıyorsunuz?
Onu ikna etme! Üstelik, onun gibi bir hafızanız olsaydı - kendiniz şaşırırdınız - neden her şey çok daha kolay yapılabiliyorsa, neden fazladan OOP jestleri? Tüm değişkenleri küresel hale getiriyoruz, her yerden doğrudan erişim, hiçbir yasak ve kısıtlama yok - güzellik!
Bu, aptallıkları nedeniyle on yıl önce yazdıklarını unutabilenler içindir - derleyicinin ve dilin onu mümkün olan her şekilde sınırlaması gerekir. Ve kodunuzdaki şu veya bu yapıyı neden ve neden yazdığınızı tam olarak hatırladığınızda, ki bu zaten çok eskidir - OOP, arabadaki yalnızca beşinci tekerlektir.
Peter'ın sorunu "OOP veya prosedürel yaklaşım" seçiminde hiç değil, Peter'ın sorunu hedef kitlede. Bir yandan programlama konusunda bilgili, diğer yandan elleriyle ticaret yapmayı tercih eden insanların yokluğunda. Bunları görmüyorum.
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 bir eklenen parametreler için diziler ve değerlerini tablo hücreleri arasında kaydırma.
2. Evet. Yapıcı, sağladığınız koda göre 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.
Her seferinde yeni bir GUI için motorda değişiklik yapmanız gerektiği ortaya çıktı (uygun GUI çekirdeğini sağlayın). Bunun temelde yanlış bir karar olduğunu düşünüyorum. Motorunuzun yüzlerce kullanıcısı olduğunu hayal edin. Ancak Market'te veya başka bir yerde barındırılan yalnızca bir motor var. Bu durumda nasıl davranacaksınız? Her kullanıcının altına, kendisi için indirmesi gereken belirli bir motor yerleştirmek için mi? Ve gui-kernel'i motor için nasıl hazırlayacaksınız? Her kullanıcıya ayrı bir çekirdek sağlayacak mısınız? - Hızla kabusa dönüşecek. Çözümünüzün ölçeklendirilmediği ortaya çıktı.
Peter, OOP'ta, birbirine bağlı olmayacak birçok nesneyle çalışabilmek için sınıf nesneleri oluşturulur. CCanvas ile çalıştığınızda ve bir grafiğiniz olduğunda, her şey yolundadır, burada OOP gerçekten gerekli değildir. Ancak farklı alanlarda birkaç grafik görüntülemeniz gerektiğinde, OOP olmadan ve birkaç CCanvas örneği oluşturmadan bunu yapmak zaten zordur.
Veya başka bir örnek. Geçenlerde, aynı anda birden fazla enstrümanla işlem yapabilmesi için prosedürel bir EA'yı değiştirmem istendi (aynı grafikte başlatıldı). Prosedürel bir tarzda, aynı anda farklı semboller üzerinde bağımsız olarak ticaret yapmasını sağlamak çok uzun ve zor bir numara alacaktır. Tüm prosedür kodunu bir sınıfa yerleştirdim ve bunun üç örneğini oluşturdum. Her birine, çalışan bir sembol vb. dahil olmak üzere ayrı bir ayar seti verildi. Kod, ilk seferde olması gerektiği gibi çalıştı. Kullanıcı mutluydu.
Özünde sen bile OOP kullanın. Bunu dolaylı olarak yapmanıza rağmen:
Çekirdeklerinizin her biri, OOP terimleriyle bir sınıfın örneğidir. Ve buna ne derseniz deyin, ancak OOP'nin bir unsurudur. Ancak ne yazık ki, bu ev yapımı öğe, kavramsal güç açısından, binlerce sonuncu olmayan zihin tarafından halihazırda icat edilmiş ve cilalanmış olandan daha düşüktür.
Vasily, çizim işlevlerinin neden bir sınıfta çerçevelendiğini anlıyorum. Çünkü bunların yanında başka işlevler de vardır.
Ama soru biraz farklıydı. Neden özellikle Nikolai, diğer sınıfları kullanmıyorsa, sınıf aracılığıyla çizim işlevlerine çağrıyı kullanın. O sadece çizer.
Sorunun özü buydu.
Bu eylemin mantık açısından anlamsızlığını ve ayrıca kendisinin bunu fark etmediğini vurguladım.
OOP kullanımının, çözülmekte olan görevlerin ölçeği tarafından genellikle haksız olduğunu vurguladım. Sonuçta, OOP'nin yayılan bir sınıflandırmaya ihtiyacı var ve eğer yoksa, onu özel olarak oluşturmaya değer mi?
Buradaki nokta, geliştiriciye araçların değil, mekanizmaların gereksinimlerinin rehberlik etmesidir.
Peter, OOP'ta, birbirine bağlı olmayacak birçok nesneyle çalışabilmek için sınıf nesneleri oluşturulur. CCanvas ile çalıştığınızda ve bir grafiğiniz olduğunda, her şey yolundadır, burada OOP gerçekten gerekli değildir. Ancak farklı alanlarda birkaç grafik görüntülemeniz gerektiğinde, OOP olmadan ve birkaç CCanvas örneği oluşturmadan bunu yapmak zaten zordur.
Veya başka bir örnek. Geçenlerde, aynı anda birden fazla enstrümanla işlem yapabilmesi için prosedürel bir EA'yı değiştirmem istendi (aynı grafikte başlatıldı). Prosedürel bir tarzda, aynı anda farklı semboller üzerinde bağımsız olarak ticaret yapmasını sağlamak çok uzun ve zor bir numara alacaktır. Tüm prosedür kodunu bir sınıfa yerleştirdim ve bunun üç örneğini oluşturdum. Her birine, çalışan bir sembol vb. dahil olmak üzere ayrı bir ayar seti verildi. Kod, ilk seferde olması gerektiği gibi çalıştı. Kullanıcı mutluydu.
Özünde sen bile OOP kullanın. Bunu dolaylı olarak yapmanıza rağmen:
Çekirdeklerinizin her biri, OOP terimleriyle bir sınıfın örneğidir. Ve buna ne derseniz deyin, ancak OOP'nin bir unsurudur. Ancak ne yazık ki, bu ev yapımı öğe, kavramsal güç açısından, binlerce sonuncu olmayan zihin tarafından halihazırda icat edilmiş ve cilalanmış olandan daha düşüktür.
Burada boş yere boncuk atıyorsun. İlk olarak, Perth danışmanıyla olan örneğiniz bir fil lapasına benziyor - uzmanların nasıl yazılacağını bilmiyor, orada ne olduğunu ve nedenini anlamıyor ve çok açıklayıcı örneğinizi anlayamıyor - göreceksiniz, o, vuruş yapıyor gözleri, Nicholas ile aynı şeyi size söylemeye başlayacak. İkinci olarak, kendisinin, kovasında, kendi başına ve binlerce önceki aklın yardımı olmadan kendisinin olağanüstü bir çözümle daha iyi bir süper benzersiz bir kod oluşturduğunu söyleyerek burnunu daha da yukarı kaldırması için bir neden veriyorsunuz. önceki herhangi bir çözümden daha fazla. Göreceksiniz - valfli benzersiz kovasını tam olarak bu şekilde konumlandıracak ...
not. Belki sert bir şekilde konuştum, ama gerçekten anlaşılmaz bir aptallığa dayanamıyorum.
Çekirdeklerinizin her biri, OOP terimleriyle bir sınıfın örneğidir. Ve buna ne derseniz deyin, ancak OOP'nin bir unsurudur. Ancak ne yazık ki, bu ev yapımı öğe, kavramsal güç açısından, binlerce sonuncu olmayan zihin tarafından halihazırda icat edilmiş ve cilalanmış olandan daha düşüktür.
Ve orada. Ancak, yine de, önemli bir fark var. Anladığım kadarıyla Peter ile - bu sınıf örneğinde - neredeyse her şey mevcut. Ve bu - OOP'nin kapsülleme paradigmasına uymuyor. Evet artı ayrıca global değişkenler .
Yani burada - sadece "OOP unsurları".
Ama ve tam tersi - korkarım insanlar bundan çok hoşlanmayacak - eminim Vasily, OOP projemi indirdiğimde, tam tersine, insanlar “hiçbir şey yapamazsın” diye ciyaklayacaklar. bu arayüzle, doğrudan amaçlananlar dışında." :)
Her seferinde yeni bir GUI için motorda değişiklik yapmanız gerektiği ortaya çıktı (uygun GUI çekirdeğini sağlayın). Bunun temelde yanlış bir karar olduğunu düşünüyorum. Motorunuzun yüzlerce kullanıcısı olduğunu hayal edin. Ancak Market'te veya başka bir yerde barındırılan yalnızca bir motor var. Bu durumda nasıl davranacaksınız? Her kullanıcının altına, kendisi için indirmesi gereken belirli bir motor yerleştirmek için? Ve gui-kernel'i motor için nasıl hazırlayacaksınız? Her kullanıcıya ayrı bir çekirdek sağlayacak mısınız? - Hızla kabusa dönüşecek. Çözümünüzün ölçeklendirilmediği ortaya çıktı.
Hayır, Vasily, her şeyi dramatize etme eğilimindesin.))
Yapıcı, tıklandığında tüm dosyaları yazdıran bir düğmeye sahiptir.
Ve motor, bir metin dosyasından çekirdekleri yükleyecektir. Bunu yapmak zor değil.
Peter, OOP kullanımıyla ilgili bir şeyi gerçekten yanlış anladın.
Bu özel bir bilinç şeklidir, evrimine müdahale etmeyin.