OOP vs prosedürel programlama - sayfa 24
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
1. Bir kriter var. Ana kriter işin hızıdır.
Kodun görselleştirilmesi yanlış kriterdir.
Acilen montaj diline geçiyoruz ..... ama çabucak .... gerçek şu ki hızlı var - bu, tüm projenin doğru organizasyonu veya bireysel işlevlerin hızıdır
Acilen bir sammer'e geçiyoruz ..... ama çabucak .... gerçek şu ki hızlı var - bu, tüm projenin doğru organizasyonu veya bireysel işlevlerin hızıdır
Acilen montaj diline geçiyoruz ..... ama çabucak .... gerçek şu ki hızlı var - bu, tüm projenin doğru organizasyonu veya bireysel işlevlerin hızıdır
Hayır, kodlamaya devam et ***
Ben katılmıyorum.
Görsel kod çok önemli bir şeydir çünkü görsel kodun bakımı ve değiştirilmesi çok daha kolaydır.
Her şey doğru söyleniyor - düzgün bir işlev yazdım ve sonra aslında onu "karıştırdım", onu sevgilim ve anlaşılmaz hale getirdim. Zorunlu bir karardı. Bu durumda, tüm sınıfın görünürlüğü benim için daha önemliydi. Bir, oldukça önemsiz işlevin görünürlüğü - feda ettim. Elbette bu fonksiyonun gövdesini bir .mq5 dosyasına taşımak mümkün olabilir ama bence arayüzler iki dosyaya bölünmemeli, .mqh başlık dosyasında tam olarak açıklanmalıdır.
Hız da akılda tutulması gereken bir şey ama "ne pahasına olursa olsun hız"ın hedeflenmesi gerektiğini düşünmüyorum. Makul yeterlilik olmalıdır.
Muhtemelen senin için de aynı nokta 3 .
Uzun zamandır programlama yapıyorum. MT3'ün piyasaya sürülmesiyle bile.
O zamandan beri, mql4'te prosedürel bir tarzda yazmak benim için daha uygun. 1001 satır için EA'm yok. Sadece bazı işlevlerin yanı sıra kütüphanelerde saklıyorum.
MQL5'te standart kitaplığı kullanıyorum. Uygun şey.
Kodu okunabilirlik için optimize ederken, bu daha çok programcılar için bir problemdir. ve burada yine ağır fonksiyonlara neden olmamak için yüksek hız performansında optimizasyon yapmak gerekiyor. Geçenlerde bir Expert Advisor'ı Mql4'ten MQL5'e dönüştürdüm. Burada yayınlanan kütüphaneyi kullandı. yarım günden beri pokvyryal, tüm fonksiyonları çözdü ve işe yaradı, ancak optimizasyon çok yavaştı. Göstergeyi 2 çubuğa indirdim - ve her şey daha yeni uçmaya başladı.
Sonuç basit. Herkes her tarzda yazabilir. MQL tam olarak prosedürel yazı kullanarak birkaç milisaniye kazanmak için kod optimizasyonu gerektiren türden bir dil değildir. Daha fazla dikkat, aynı mantıksal problemler tarafından işgal edilir. Ve pratik olarak nasıl uygulandıkları hızı etkilemez.
...
Sonuç basit. Herkes her tarzda yazabilir. MQL, prosedürel yazma yoluyla birkaç milisaniye kazanmak için kod optimizasyonu gerektiren türden bir dil değildir . Daha fazla dikkat, aynı mantıksal görevler tarafından işgal edilir. Ve pratik olarak nasıl uygulandıkları hızı etkilemez.
O kadar yumuşak ve anlaşılmaz bir şekilde özetlendi ki, yüksek performans sağlayan prosedürel programlamadır. Üç gündür gereksiz frenler olmadan sadece OOP'nin çözebileceği bir problem gösteriyorum.
OOP, değişken kümelerini kodun geri kalanından korumanıza izin verir; bu, sınıf içinde hesaplamalar yaparken, parametreleri yönteme geçirmekten uzaklaşmanıza izin verir ve bu, performans için önemli bir faktördür. Bunu prosedürel bir tarzda yapsanız bile, çok sayıda global değişken üretmeniz gerekecek, bunun sonucunda kodun okunabilirliği imkansızlığa indirgeniyor.
O kadar yumuşak ve anlaşılmaz bir şekilde özetlendi ki, yüksek performans sağlayan prosedürel programlamadır. Üç gündür gereksiz frenler olmadan yalnızca OOP'nin çözebileceği bir sorunu gösteriyorum.
OOP, değişken kümelerini kodun geri kalanından korumanıza izin verir; bu, sınıf içinde hesaplamalar yaparken, parametreleri yönteme geçirmekten uzaklaşmanıza izin verir ve bu, performans için önemli bir faktördür. Bunu prosedürel bir tarzda yapsanız bile, çok sayıda global değişken üretmeniz gerekecek, bunun sonucunda kodun okunabilirliği imkansızlığa indirgeniyor.
Prosedürel stilin kazancı ihmal edilebilir çünkü kod, EA'lara her bir onay işaretinin gelmesiyle birlikte çalıştırılır. Ve keneler arasında yüzlerce hatta onlarca milisaniye olabilir. Göstergelerle asla uğraşma. Göstergelerden kendim için gerçek bir fayda bulamadım.
Büyük projeler muhtemelen OOP'de yazmak için daha uygundur. Bir şeyi kurtarmam gerekirse, yapıları kullanmayı tercih ederim.
Böylece veri erişimi daha görsel hale gelir ve açılır menünün kullanımı çok uygundur. Yapılar dizilerle değiştirilirse, genellikle karışıklık ortaya çıkar. ve dizilerin sayısı artar.
Bir önceki mesajda ağır fonksiyonları çağırmaya odaklanmıştım. Örneğin, her onayda yapılması gerekmeyen döngülerdeki bazı yinelemeler. Ve bunu her yeni barda yapmak da gerekli değildir.
Gerçek performans kazanımlarının en üst düzeye çıkarılabileceği yer burasıdır.
Evet. Komik tartışma: Ekskavatöre karşı kürek.
Muhtemelen, bir ağaç dikmeniz gerekiyorsa, bir kürek daha iyidir. Ve bir çukur kazarsanız, belki de bir ekskavatör daha iyi olacaktır.
Evet. Komik tartışma: Ekskavatöre karşı kürek.
Muhtemelen, bir ağaç dikmeniz gerekiyorsa, bir kürek daha iyidir. Ve bir çukur kazarsanız, belki de bir ekskavatör daha iyi olacaktır.
Evet. Komik tartışma: Ekskavatöre karşı kürek.
Muhtemelen, bir ağaç dikmeniz gerekiyorsa, bir kürek daha iyidir. Ve bir çukur kazarsanız, belki de bir ekskavatör daha iyi olacaktır.