Yapı kayaları. Programları yapılandırmayı, olasılıkları, hataları, çözümleri vb. keşfetmeyi öğreniyoruz. - sayfa 10

 

State programlamaya ilk elden aşinayım ve birkaç yıldır kendim kullanıyorum. Ancak bu yöntemi bir süre kullandıktan sonra vazgeçip ona dayalı daha şeffaf, daha basit ve daha uygun bir ticaret modeli geliştirmeye karar verdim.

Bu makaleyi dikkatlice okuduk: Otomatik ticaret sistemleri oluşturmanın yeni bir yolu olarak otomatik programlama

Sonra bu yorumları ona dikkatlice okuyun.

Sonra, çok, çok nüfuzlu bir şekilde, makaleden betimlenmemiş bir tableti düşünüyoruz ve bunun ne anlama gelebileceğini düşünüyoruz:

Tüm bu okuduklarınızdan sonra hala "Vay canına! Devlet programlaması çok havalı!" gibi bir şey kaldıysa. - peki, öyle düşün.

Kendi adıma, State programlamanın temel sorununun birçok işe yaramaz mod üreten durumlar olduğunu ekleyeceğim (N State sütununa bakın). Durum programlamasında, her mod kendi kurallarını ayrı ayrı tanımlamalıdır. Bir örnekle anlatayım, Buy modundayız diyelim. Ve robot başka bir pozisyon açmaya karar verene kadar her şey yolunda. Ve gerçekten, neden olmasın? Eski pozisyondan çıkmak için koşullar karşılanmadı ve onu kapatmak için çok erken ve yeni bir sinyal kaçırılamaz. Ve problemlerin başladığı yer burasıdır, çünkü yeni bir sinyal geldiği anda robot Satın alma modundadır ve yeni bir pozisyon açma kuralları Durum modundadır (bekleme ve yeni giriş sinyallerini arama). Şimdi Satın Al modunda, Durum modunda olduğu gibi bir pozisyon açmak için aynı kuralları yeniden tanımlamamız gerekiyor. Ve eğer yeni konum zıt yöndeyse (çit)? Böyle bir pozisyon açılır ve bundan sonra ne yapmalı? Ne de olsa bakım mantığı Satış modunda açıklanır ve robot Satın Alma modundadır. Sadece Satış moduna geçebilirsiniz, ancak kalan Alış pozisyonu ile ne yapmalı? Genel olarak bu durumda BuyAndSell gibi başka bir işe yaramaz mod yazmanız gerekiyor. Modların fazlalığı başka bir durum yaratır: aynı eylem, kodun farklı bölümleri tarafından gerçekleştirilir. Genel olarak, üstel hemoroid sevenler için durum programlaması en fazladır.

 
C-4 :
(fcplm)
 
C-4 :

"İşte Mikhalych gibi" (c) ... Ve ben de bunu açıkça ima ediyorum.

TheXpert :
(fcplm)

Evet hiçbirşey.

 
C-4 :
Burada, MQL5 çoklu kalıtımı destekliyorsa ve sınıf da soyut yöntemler bildirebilirse, bunun arayüzleri kullanmanın yolunu açacağını düşündüm, bu da büyük projeler için çok güzel olurdu.

Soyut yöntemler açıkça yasaklanmamıştır (sıklıkla alternatif gösterim kullanırım),

Ve çoklu kalıtım büyük bir artı olurdu.

 
A100 :
Soyut yöntemler doğrudan yasaklanmamıştır ve çoklu kalıtım büyük bir artı olacaktır.

Rosh'tan alıntı yapmak gerekirse: Bu, odun kesmenize nasıl yardımcı olur?

Kazanılan SSS dörde oturur ve wus'a üflemez ve herhangi bir soyut metoda ve çoklu kalıtımlara dayanmaz.

En azından soyut yöntemler olsa da yine de proje yapılandırma görevini ortadan kaldırmayacaktır.

Bu arada, aynı görevi uygulamak için ne kadar fazla seçenek varsa, hangi seçeneğin uygulanacağını seçmek o kadar zor olur.

Programcının genellikle kod güzelliği görevine düştüğü ortaya çıktı. Bu sanat için sanattır.

PS ve genel olarak (kendi adıma konuşuyorum) fark ettim ki projeyi inşa etmek (planlamak) için ne kadar çok pul olursa o kadar kolay oluyor.

O zaman değiştirebilir, yeniden değiştirebilir, yeniden değiştirebilir, yeniden değiştirebilirsiniz,

ancak ilk çerçeve (çok sıcak olmasa da) tüm yapının tonunu belirliyor.

 
Urain :

Rosh'tan alıntı yapmak gerekirse: Bu, odun kesmenize nasıl yardımcı olur?

O zaman değiştirebilir, yeniden değiştirebilir, yeniden değiştirebilir, yeniden değiştirebilirsiniz,

ancak ilk çerçeve (çok sıcak olmasa da) tüm yapının tonunu belirliyor.

Yakacak odun kesme hızı artacaktır.

Zaten nasıl ve neye benzemesi gerektiği konusunda net bir fikriniz varsa, muhtemelen MQL4'te aklınıza göre her şeyi yapabilirsiniz.

Ve eğer böyle bir temsil yoksa, o zaman çok fazla değişiklik ve ekleme olacaktır. Ve özellikle çoklu kalıtım, minimum ek yük ile değişiklik yapmanızı sağlar.

Soyut yöntemlere katılıyorum - sadece güzel bir yazı biçimi.

 
A100 :

Yakacak odun kesme hızı artacaktır.

Zaten nasıl ve neye benzemesi gerektiği konusunda net bir fikriniz varsa, muhtemelen MQL4'te aklınıza göre her şeyi yapabilirsiniz.

Ve eğer böyle bir temsil yoksa, o zaman çok fazla değişiklik ve ekleme olacaktır. Ve özellikle çoklu kalıtım, minimum ek yük ile değişiklik yapmanızı sağlar.

Şimdi kapsayıcılık lehine mirası terk etmeye çalışıyorlar. Çoklu mirasa karşı tutumun nasıl olması gerektiğini hayal edebiliyor musunuz?
 
Vladix :
Şimdi kapsayıcılık lehine mirası terk etmeye çalışıyorlar. Çoklu mirasa karşı tutumun nasıl olması gerektiğini hayal edebiliyor musunuz?
Çoklu kalıtım olmadan, arayüz düzeyinde yatay bağlantıları düzenlemek mümkün değildir. Paradigma basittir: herhangi bir nesne, herhangi bir sayıda arabirimi destekleyebilir. Kendi içinde, çoklu kalıtım kesinlikle kötüdür. C#'da sebepsiz yere yasaktır, aksine arayüzlerin kullanımı teşvik edilir.
 
Urain : Kazanılan SSS dörde oturur ve ıslık çalmaz, hiçbir soyut yönteme ve çoklu kalıtıma dayanmaz.


karalanmış: https://www.mql5.com/en/forum/13114
 

FAQ :

Evet hiçbirşey.

Hala incir gibi. Switch...case kullanmak ve durum makinesi desenini kullanmak iki farklı şeydir. Yukarıdaki yazıda olduğu gibi desenin orada kokmadığı metinden görülebilir.

"Benzersiz bir kazanma sistemi icat ettim ..." gibi bir şey okuyor ve ardından Martin'in çarpık sunumu.