OOP için genel gider - sayfa 4
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
Uygulamam gösteriyor ki, sonuçta buna ihtiyaç var.
Bu yolu beş yıl önce, o zamanlar MT4'te izledim. (OOP hakkında bilgi sahibi olmadığım için değil, arayüzler ve kalıtımla uğraşamayacak kadar tembeldim, özellikle o zamanlar MT4 ve MT5 MQL uygulaması açısından önemli ölçüde farklılık gösterdiğinden). Bu, onun yanıldığını anlamamı sağladı. Bu "karmaşıklıklar" değil, oldukça makul bir kısıtlama, bir tür "aptallara karşı koruma". Yüzlerce değişkenin her birinin neden sorumlu olduğunu her zaman hatırlıyorsanız, kapsüllemeye ihtiyacınız yoktur. Bunu hatırlamıyorum ve programın her bloğunda mümkün olduğunca az varlığa erişim olmasını tercih ediyorum.
MT4'te OOP ortaya çıkar çıkmaz, tüm geliştirmelerimi hemen arayüzlere dayalı tek bir forma çevirmeye başladım.
MQL4 sipariş sisteminden daha uygun bir şey asla bulamadım. Örnek varsa gösterin.
Gördüğüm tüm ticaret API'leri, MQL4'e kıyasla korkunç görünüyor. Ayrıca, onlar da sakarlar.
MQL4 sipariş sisteminden daha uygun bir şey asla bulamadım. Örnek varsa gösterin.
Gördüğüm tüm ticaret API'leri, MQL4'e kıyasla korkunç görünüyor. Ayrıca, onlar da sakarlar.
İyi olan, her parametrenin ayrı bir fonksiyon tarafından çekilmesi gerekiyor. İstek üzerine tüm parametrelere sahip bir yapı almak, kenelerde olduğu gibi mantıklı olacaktır.
MQL4 sipariş sisteminden daha uygun bir şey asla bulamadım. Örnek varsa gösterin.
Gördüğüm tüm ticaret API'leri, MQL4'e kıyasla korkunç görünüyor. Ayrıca, onlar da sakarlar.
Ne ?
İşlemlerin-siparişlerin özü? Evet, katılıyorum, çok uygun.
Ancak, sadece OOP'nin bu sisteme uygulanması - bence en büyük "kazancı" veriyor. Diyelim ki aynı arayüze sahibim - çalışma koşullarının hedge veya netleme olmasına bakılmaksızın hem emirlerden oluşan bir MT4 pozisyonu hem de MT5 pozisyonlarından oluşan bir MT5 pozisyonu veriyor.
Bence Select() fonksiyonu ile elde edilen order nesnelerinin (veya MT5 konumlarının) bir listesine sahip olduğumuzda ve " ortam durumu " ( tarafından elde edilen) değil, siparişlerin özelliklerine eriştiğimizde çok daha mantıklı ve anlaşılır. işlevler aracılığıyla eriştiğimiz aynı işlev).
En ilginç şey, aynı anda birkaç siparişi izlememiz gerekirse - burada prosedürel yaklaşım kaçınılmaz olarak bir "sözde nesne" siparişine yol açacaktır - siparişler hakkında, girerken güncelleyeceğimiz bir dizi bilgi oluşturmamız gerekecek. OnTick() ve dizideki dizinlere göre sipariş verileriyle çalışın, tıpkı bunun nesneleri sipariş etmek için OOP işaretçileriyle olduğu gibi.
Ek olarak, OOP yaklaşımı, tarihsel ve aktif siparişlerle aynı anda çalışırken bir kazanç sağlayacaktır - çünkü tarihsel düzenin arayüzü mevcut düzenin halefidir. Özelliklerin çoğu ortaktır. Ve prosedürel bir yaklaşımla, tarihsel ve aktif siparişlere erişim, çok daha az uygun olan farklı işlevler tarafından gerçekleştirilir.
İyi olan, her parametrenin ayrı bir fonksiyon tarafından çekilmesi gerekiyor. İstek üzerine tüm parametrelere sahip bir yapı almak, kenelerde olduğu gibi mantıklı olacaktır.
Order.TakeProfit ve OrderTakeProfit() girdileri aynıdır. Birincisi yalnızca nesneyi saklama yeteneğine ve ikincisi - alaka düzeyine sahiptir. Araçta değil çok ender olarak depolama ihtiyacını karşıladım. Ve yaratılacak yapı var - sorun yok.
Geliştiricilerin neden siparişin dönüşünü bir yapı yapmadıklarını, ancak her alanı bir işlev aracılığıyla ayrı ayrı bıraktığını merak ettim (tarih için her seferinde bir bilet de gereklidir).
Genel olarak, MQL4-API'de gerçekten kötü bir şey görmüyorum (sadece MT4/5'te çalışmıyor).
Ne ?
İşlemlerin-siparişlerin özü? Evet, katılıyorum, çok uygun.
Ancak, sadece OOP'nin bu sisteme uygulanması - bence en büyük "kazancı" veriyor. Diyelim ki aynı arayüze sahibim - çalışma koşullarının hedge veya netleme olmasına bakılmaksızın hem emirlerden oluşan bir MT4 pozisyonu hem de MT5 pozisyonlarından oluşan bir MT5 pozisyonu veriyor.
Senin sargın sende, diğerinde onunki var. Soru farklıydı, MQL4'ten daha uygun bir sarmalayıcı oluşturmak mümkün müdür?
Bence Select() fonksiyonu ile elde edilen order nesnelerinin (veya MT5 konumlarının) bir listesine sahip olduğumuzda ve " ortam durumu " ( tarafından elde edilen) değil, siparişlerin özelliklerine eriştiğimizde çok daha mantıklı ve anlaşılır. işlevler aracılığıyla eriştiğimiz aynı işlev).
En ilginç şey, aynı anda birkaç siparişi izlememiz gerekirse - burada prosedürel yaklaşım kaçınılmaz olarak bir "sözde nesne" siparişine yol açacaktır - siparişler hakkında, girerken güncelleyeceğimiz bir dizi bilgi oluşturmamız gerekecek. OnTick() ve dizideki dizinlere göre sipariş verileriyle çalışın, tıpkı bunun nesneleri sipariş etmek için OOP işaretçileriyle olduğu gibi.
Bu konuda daha önce. bir yazı yazdı.
Ek olarak, OOP yaklaşımı, tarihsel ve aktif siparişlerle aynı anda çalışırken bir kazanç sağlayacaktır - çünkü tarihsel düzenin arayüzü mevcut düzenin halefidir. Özelliklerin çoğu ortaktır. Ve prosedürel bir yaklaşımla, tarihsel ve aktif siparişlere erişim, çok daha az uygun olan farklı işlevler tarafından gerçekleştirilir.
MQL4'te geçmiş aynı işlevler aracılığıyla işlenir (OrdersHistoryTotal sayılmaz).
Kendi ticaret API'nizin MQL4-API'den açıkça daha iyi olduğu bir kod örneğine sahip olmak güzel olurdu. Neredeyse her yerde OOP kullanıyorum. Ve bazı özel sorunları çözmek için bazı ticari ambalajlar yapıyorum. Ancak, belirli bir görev için kullanmak çok uygun olmasına rağmen, evrensel değildirler. Ancak yine de evrensel ticaret API'lerini karşılaştırmak istiyorum.
Geliştiricilerin neden siparişin dönüşünü bir yapı yapmadıklarını, ancak her alanı bir işlev aracılığıyla ayrı ayrı bıraktığını merak ettim (tarih için her seferinde bir bilet de gereklidir).
Alexey Volchanskiy :
Дело в том, что в МТ4 до 600-го билда не было структур )) А новый MQL4 появился где-то в начале 2013 г.
MT5'in yapıları vardı, ancak yine de işlevler aracılığıyla geri dönüyor.
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
OOP için genel gider
fxsaber , 2017.07.07 08:08
Soru farklıydı, MQL4'ten daha uygun bir sarmalayıcı oluşturmak mümkün müdür?
MT5'in yapıları vardı, ancak yine de işlevler aracılığıyla geri dönüyor.
muhtemelen boşuna olmasına rağmen gelenekleri bozmamaya karar verdi
Ayrıca DC sunucusundan gelen veriler indirilseydi, ancak bunlar yerelse, anında alınırsa, yapıyı hemen doldurmak mümkün olacağını da anlıyorum.
muhtemelen boşuna olmasına rağmen gelenekleri bozmamaya karar verdi
Ayrıca DC sunucusundan gelen veriler indirilseydi, ancak bunlar yerelse, anında alınırsa, yapıyı hemen doldurmak mümkün olacağını da anlıyorum.
Evet, içeride SELECT ile, tam olarak alanlarına yalnızca const (salt okunur) işlevleriyle ulaşılabilen gizli bir yapının bir örneğinin doldurulmasıdır.
Bu muhtemelen ticaret API çekirdeğinin tek tartışmalı kararıdır. Bunun dışında neye şikayet edeceğimi bile bilmiyorum.
Evet, içeride SELECT ile, tam olarak alanlarına yalnızca const (salt okunur) işlevleriyle ulaşılabilen gizli bir yapının bir örneğinin doldurulmasıdır.