Yapı kayaları. Programları yapılandırmayı, olasılıkları, hataları, çözümleri vb. keşfetmeyi öğreniyoruz. - sayfa 7
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Ana tasarım modellerini düzenlemeyi öneriyorum:
1. İşlevsel
2. Amaç
3. Etkinlik
...
Ekle
4. Bileşen
--
Genel olarak, herhangi bir program (planlanan dahil) farklı açılardan görüntülenebilir. // Bu temiz.
Projenin ilk analizi sırasında, hatasız olarak en az 4 yönü dikkate almaya çalışıyorum:
1. Yapısal: Program kodunun ve program bileşenlerinin fiziksel ve mantıksal organizasyonu.
2. İşlevsel (geliştirmedeki işlevsel yaklaşımla karıştırılmamalıdır): Program hangi görevleri çözer (hangi ürünü üretir), kullanımı nedir, ne çıktı vermelidir vb.
3. İletişimsel: Programın ne tür bir kullanıcı arayüzü olmalı, hangi programlarla ve nasıl veri alışverişi, değişim protokolleri vb.
4. Yönetimsel: Programın nasıl yönetildiği, hangi ayarların gerekli olduğu, serbestlik dereceleri vb.
Tüm yönler ayrılmaz bir şekilde birbiriyle ilişkilidir, ancak bu farklı açılara bakmak (+ biraz daha) önemli incelikleri kaçırmamanızı ve ilk aşamalarda geniş kapsamlı sonuçları olan önemli bir şeyi kaçırmamanızı sağlar...)
... Genel olarak, herhangi bir program (planlanan dahil) farklı açılardan görüntülenebilir. // Bu temiz...
Kesinlikle katılıyorum. Bu genel bir felsefi ilkedir - bir fenomenin farklı bakış açılarından incelenmesi ...
Ve geliştirmenin başında "Program ne yapmalı, ne yapmamalı?" sorusuna cevap vermeye çalışıyorum. Sorunun ilk kısmı sistemin çerçevesine giriyor (burada MTS), ikincisi - düşmüyor, dışarıda.
IMHO, tasarım modelinden bağımsız olarak bir model öğeleri hiyerarşisine sahip olmak çok önemlidir. Ardından, modeli ana ve kurucu bloklara bölerek, tümdengelim yöntemi iyi çalışır - "genelden özele".
Düşünce alışverişi / karşılıklı öğrenme için, az çok pratik bir sorun gibi görünen (parmaktan emmeyi) almayı ve tüm kollektif çiftlikle yapılandırmayı öneriyorum.
Örneğin, böyle bir görev için en azından temel yapıyı (daha doğrusu bu tür yapıların varyantlarını) ana hatlarıyla belirtin:
Her halükarda yazılı bir danışman var (örneğin, bir ticaret fikrini test etmek için). Test cihazındaki (müşteride) fikrin umut verici sonuçlar verdiğini varsayalım. Şimdi, geliştirmeye uygun bir forma getirmek için danışmanı yeniden yazmanız gerekiyor. Ve özellikle grafiksel bir kullanıcı kontrol paneli sağlamak .
Panelin devre dışı bırakılması (test cihazında optimizasyon için) veya Expert Advisor'ın "grafik olmayan" uygulamasının tamamının, daha sonra grafik arayüze bağlanabilecek olan dahil edilmiş bir dosyaya (.mqh) taşınması arzu edilir. "test" ve "grafik" sürümlerinin çalışmasında değişiklik (hariç tutmak için) farklılıklar olmadan .
Böyle bir projenin yapılandırılmasıyla ilgili düşünceleri duymak ve okumak isterim. Özellikle etkinlik yönetimi modelinin böyle bir projede uygulanması konusunda. Çift uygulamanın (test + panel) müşterinin katı bir gereksinimi olduğunu varsayalım (yani, bunu herhangi bir şekilde yapmanız gerekir, yalnızca uygulama yöntemini seçebilirsiniz).
Bulmacayı patlatalım mı?
Bence uzmanın kontrol paneli ve uzmanın kendisi aynı programın tamamen farklı iki modülüdür. Bu nedenle, bu parçaların her biri diğerinden bağımsız olacak şekilde onları ayırmak gerekir. Bu, Expert Advisor'ın bir bölümünü değiştirirken (örneğin, sipariş verme mantığını değiştirdiler), panelin mantığını değiştirmek zorunda olmadıkları ve tam tersi (panelin arayüzünü değiştirdiler - var) anlamına gelir. Expert Advisor'ın mantığını değiştirmeye gerek yok). Akla gelen ilk şey, panel ve uzmanın veri alışverişinde bulunabileceği birleşik bir arayüzün oluşturulmasıdır. Ancak ne yazık ki, MQL5'in yaratıcıları yatay bağlantılar oluşturma olasılığını sağlamadı, bu da aralarındaki arayüzü MQL5 araçlarını kullanarak tanımlamanın imkansız olduğu anlamına geliyor. Sonra dikey entegrasyon yolu var. Expert Advisor, panelle etkileşim için yeterli yöntemleri ve verileri içeren temel sınıftan devralınmalıdır. Bu, temelden devralınan herhangi bir Uzman Danışmanın, aynı zamanda panel ile görüntülenme ve etkileşim kurma yeteneğini de edindiği anlamına gelir. Aynı zamanda, panel ile etkileşimden sorumlu yöntemlerin uygulanması, alt sınıflara devredilmemeli, temel sınıfın perde arkasında gerçekleştirilmelidir, yani. "Descendant! Panel ile çalışmak istiyorsanız, falan yöntemlerimi falan parametrelerle çağırın" mesajı hiç çalışmıyor. İdeal olarak, temel sınıftan devralınan herhangi bir türetilmiş Expert Advisor, uygun bir şekilde ticaret yapmalıdır ve eylemleri bu panelde otomatik olarak görüntülenecektir.
Evrensel bir temel ticaret sınıfının nasıl organize edileceği ayrı bir ilginç konudur. Bu konuda birkaç yıllık uygulama sonunda beni kişisel olarak evrensel planıma yönlendirdi. Şeffaf ve evrensel olduğu ortaya çıktı. İlgileniyorsanız, ona temel bir akış şeması verebilirim (haha, akış şemaları çizmek hala faydalı bir alıştırmadır). Ancak her durumda, herkesin kendi yolu vardır ve biri için iyi bir çözüm, diğeri için iyi bir çözüm olmayacaktır.
İlgileniyorsanız, ona basit bir akış şeması verebilirim (haha, sonuçta, akış şemaları çizmek faydalı bir alıştırmadır).
1. Akla gelen ilk şey, panel ve uzmanın veri alışverişinde bulunabileceği birleşik bir arayüzün oluşturulmasıdır.
2. Ne yazık ki, MQL5'in yaratıcıları, yatay bağlantılar oluşturma olasılığını sağlamadılar, bu da, MQL5 araçlarını kullanarak aralarındaki arayüzü tanımlamanın imkansız olduğu anlamına geliyor.
1. Kesinlikle.
2. Peki, neden olmasın? Peki ya özel etkinlikler? Oldukça yatay ve evrensel.
3. Sonra dikey entegrasyon yolu var. Expert Advisor, panelle etkileşim için yeterli yöntemleri ve verileri içeren temel sınıftan devralınmalıdır. Bu, temelden devralınan herhangi bir Uzman Danışmanın, aynı zamanda panel ile görüntülenme ve etkileşim kurma yeteneğini de edindiği anlamına gelir. Aynı zamanda, panel ile etkileşimden sorumlu yöntemlerin uygulanması, alt sınıflara devredilmemeli, temel sınıfın perde arkasında gerçekleştirilmelidir, yani. "Descendant! Panel ile çalışmak istiyorsanız, falan yöntemlerimi falan parametrelerle çağırın" mesajı hiç çalışmıyor. İdeal olarak, temel sınıftan devralınan herhangi bir türetilmiş Expert Advisor, uygun bir şekilde ticaret yapmalıdır ve eylemleri bu panelde otomatik olarak görüntülenecektir.
3. 2. paragrafa katılmadığım için bu seçeneği henüz kazmıyorum.
--
Çok güzel bulduğum bir seçenek var. ("Değiştirilebilir" panelli seçenek). Panelin bir gösterge gibi görünmesini sağlayın. Uzman test cihazındaysa, paneli yüklemez. Ek bir avantaj, panelin farklı bir iş parçacığında çalışması ve uzman için daha fazla kaynak bırakmasıdır.
Panelin çok yönlülüğüne gelince. Panelin ini-file kullanılarak tamamen yapılandırılmasının önünde herhangi bir temel engel görmüyorum. Onlar. orada, sınırlı bir sabit görsel bileşen kümesinden herhangi bir panel oluşturmak için gerekli tüm verileri + kullanıcı ile etkileşime girerken oluşturmaları gereken olay kodlarını kesinlikle yazabilirsiniz.
Evrensel bir temel ticaret sınıfının nasıl organize edileceği ayrı bir ilginç konudur. Bu konuda birkaç yıllık uygulama sonunda beni kişisel olarak evrensel planıma yönlendirdi. Şeffaf ve evrensel olduğu ortaya çıktı. İlgilenirse, ona şematik bir blok diyagram verebilirim. ....
1. Kesinlikle.
Nahr Neden? Aşırı genelleme, erken optimizasyon kadar kötüdür.
Ve aynı modülün bloklarını olaylar aracılığıyla birbirine bağlamak ... yavaş ve elverişsizdir.
Haydi Yapalım şunu. Hatta çok ilgileniyorum. Evet, pratik olarak faydalı olabilir.
Mavi çerçeve - temel sınıf varlıklar. Türetilmiş sınıf varlığının kırmızı kenarlığı. Temel sınıfın, mantığının tanımını çocuğa dört yöntemle dayattığı görülebilir. Herhangi bir stratejinin tanımını yalnızca dört durumun açıklamasına indirgeyen bu yöntemdir:
1. Uzun bir pozisyon açmak için tüm kurallar karşılanırsa, InitBuy() yönteminde bir uzun pozisyon açılır
2. Uzun bir pozisyonu kapatmak için tüm kurallar karşılanırsa, uzun pozisyon SupportBuy() yönteminde kapatılır.
3. Kısa pozisyon açmanın tüm kuralları karşılanırsa, InitSell() yönteminde bir kısa pozisyon açılır
4. Bir kısa pozisyonu kapatmak için tüm kurallar karşılanırsa, kısa pozisyon SupportSell() yönteminde kapatılır.
Bu mantığa göre, stratejinin tersine çevrilmesi tek bir yöntemde (örneğin, bir uzunu kapat, bir kısayı aç) değil, birbirinden bağımsız iki yöntemde açıklanır. Bu yaklaşımın çok uygun olduğu ortaya çıktı, çünkü. örneğin, temel sınıfta tanımlanabilecek herhangi bir genel koşula ulaşıldığında satışları yasaklamak veya pozisyonları zorla kapatmak için tek bir tıklamaya izin verir.
Bazı durumlarda strateji, hem satışlar hem de satın almalar için yeni bir çubuğun gelmesi gibi bir olay meydana geldiğinde yeniden hesaplanması gereken genel verileri içerir. Bu gibi durumlarda, stratejinin işleme yöntemlerini olaylara abone etmesi mümkündür. Bunlarda pozisyon açamazsınız ancak çeşitli hesaplamalar yapabilirsiniz.
İlginç bir nokta da açık pozisyonlarla çalışma şeklidir. Temel sınıf, uzun ve kısa pozisyonların ayrı listelerini tutar. Yeni bir olay meydana geldiğinde (örneğin, OnTick), sınıf tüm açık pozisyonların listelerini yinelemeye başlar ve sırasıyla SupportBuy SupportSell yöntemlerini kullanarak bu pozisyonların her birini işlemek için teklifler sunar. Bu yöntemler yalnızca temel sınıfın onlara sunduğu konumu kapatabilir. Diğer tüm pozisyonlar salt okunurdur. Bu nedenle, temel sınıf, torunlarına, şu anda yalnızca tek bir konuma odaklanmanın gerekli olduğu fikrini empoze eder. Bu fikri test ettiğimde, en karmaşık Uzman Danışmanın bile mantığının çok daha basit hale geldiği ortaya çıktı. Ek olarak, bir çit konsepti için otomatik destek sağlar, EA, uzun ve kısa pozisyonları hakkında bilgi tutar.Yürütmeyi limit emirleri için stratejilere tam olarak dönüştürmeye başladığınızda, hemen aşağıdakiler gibi bir sürü soru ortaya çıkacaktır:
Ve sonra "yürütücü" ve "analizör" arasında geri bildirim sağlamanız ve dahası, bir şekilde bu ideal olmayan yürütmenin parametrelerini analizörün matematiksel modeline gömmeniz gerekecek.
MetaDriver : ... Test cihazında genel olarak stratejik fikirleri test etmek için bir şarkı - ticarette sorun yok ...
Limit emirleri için uygulamayı kapsamlı bir şekilde stratejilere dönüştürmeye nasıl başlayacaksınız?