OOP, mql5'te şablonlar ve makrolar, incelikler ve kullanım teknikleri - sayfa 6

Yeni yorum
 
Alexey Viktorov :

İşte geliyoruz

Tüm kodlarınızın koltuk değnekleriyle yapıldığı ortaya çıktı? Kişisel bir şey değil.
Evet böyle bir şey. Çünkü MQL'de tam teşekküllü OOP yoktur. Ayrıca düzenli olarak bildirdiğim, ancak boşuna olmayan bir sürü hata. Ve böceklere karşı koltuk değnekleriyle kendinizi savunmanız gerekiyor, ne yapabilirsiniz?
 

İşte bunu nasıl yapacağız.

Statik bir değişken bir sabite başlatılırsa, bu başlatma daha önce olduğu gibi global başlatma adımında gerçekleşir.
Aksi takdirde (bir çağrı veya değişken ile başlatma), ilk çağrıda statik bir değişken başlatılacaktır (C++'daki gibi olacaktır), böyle bir çağrının kendisi örtük bir global değişken / flag ile bir koşula sarılacaktır, örneğin

MQL kodu için:

 class CFoo { };

void func( bool f)
  {
   if (f)
     {
       static CFoo foo;
      foo.MakeMeHappy();
     }
  }

Aşağıdaki sözde kod üretilecek 

CFoo static_func_foo={}; // zeromem only
bool static_func_foo_init= false ;

void func( bool f)
  {
   if (f)
     {
       if (!static_func_foo_init)
        {
         static_func_foo.CFoo();   // constructor call
         static_func_foo_init= true ;
        }

      static_func_foo.MakeMeHappy();
     }
  }
 
Alexey Navoykov :

Yine de onları bir şekilde fonksiyonda ayırmanız gerekiyor.

Mutlaka ve her zaman değil. Şubeyi çöpe atmamak için örnek vermeyeceğim.

 
Ilyas :

İşte bunu nasıl yapacağız.

Harika haber! Tanrılar dualarımızı duydu
 
Alexey Navoykov :
Evet böyle bir şey. Çünkü MQL'de tam teşekküllü OOP yoktur . Ayrıca düzenli olarak bildirdiğim, ancak boşuna olmayan bir sürü hata. Ve böceklere karşı koltuk değnekleriyle kendinizi savunmanız gerekiyor, ne yapabilirsiniz?

Kafamı tamamen karıştırdın. Eğer ... sözlerinizi okuyun

Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum

Mql5 dilinin özellikleri, incelikleri ve çalışma yöntemleri

Alexey Navoykov , 2019.01.25 11:44

Parametreler farklı türlerdeyse, karşılık gelen türlerle birkaç aşırı yüklenmiş yöntem yapmak mantıklıdır. Yine de onları bir şekilde fonksiyonda ayırmanız gerekiyor. Bu nedenle, yüzü olmayan bir tip, yani. yanlışlıkla herhangi bir şeyi iletebilir ve kütüphanenin içinde vızıldamayan bir derleme hatası alabilirsiniz. Ya da belki bile alamam, ki bu iki kat iyi değil)

Kısacası, tam teşekküllü OOP'de şablon işlevleri bir koltuk değneğidir (nadir istisnalar dışında)

ve MQL'de tam teşekküllü bir OOP yok ... Koltuk değnekleri bile gitti mi? Hiçbir şey anlamıyorum.
 
MQL'de, OOP ile her şey yolundadır, eğer çoklu kalıtım eklenirse (en azından arayüzler için, aksi takdirde mevcut formlarında tamamen işe yaramazlar), o zaman genellikle ideal olacaktır.
 
Ilya Malev :
MQL'de, OOP ile her şey yolundadır, eğer çoklu kalıtım eklenirse ( en azından arayüzler için, aksi takdirde mevcut formlarında tamamen işe yaramazlar ), o zaman genellikle ideal olacaktır.

Yani arayüzler normal OOP'nin temelidir. Ve aynı zamanda MQL'de her şeyin yolunda olduğunu söylüyorsunuz.

 
Alexey Navoykov :

Yani arayüzler normal OOP'nin temelidir. Ve aynı zamanda MQL'de her şeyin yolunda olduğunu söylüyorsunuz.

Normal OOP'nin temeli, arayüzler değil, polimorfizmdir. Arayüzler, tanımlanmış bir sınıf yapısının temelidir. Genel olarak bu konular hakkında konuşmayı çok isterdim ama korkarım bu konu bunun için değil.

 
Ilya Malev :

Normal OOP'nin temeli, arayüzler değil, polimorfizmdir. Arayüzler, tanımlanmış bir sınıf yapısının temelidir. Genel olarak bu konular hakkında konuşmayı çok isterdim ama korkarım bu konu bunun için değil.

Neden, şube oldukça uygun. MQL dilinin özelliklerini tartışıyoruz ve çoklu kalıtımın olmaması oldukça önemli bir özellik )

Tamam, elbette temel polimorfizmdir, ancak ayrı arayüzler olmadan - kullanımı uygun değildir. Bu genellikle nesnelerin arayüzler olarak değil, şablon argümanları olarak iletilmesi gerektiği gerçeğine yol açar.

Burada birden çok arayüzü simüle etme versiyonumu tanımladım. Buna göre, sınıfım şöyle bildirilebilir:

 class A : public Interface1<Interface2<Interface3<CBase>>>
{
 ...
};
 
Alexey Navoykov :

Neden, şube oldukça uygun. MQL dilinin özelliklerini tartışıyoruz ve çoklu kalıtımın olmaması oldukça önemli bir özellik )

Tamam, elbette temel polimorfizmdir, ancak ayrı arayüzler olmadan - kullanımı uygun değildir. Bu genellikle nesnelerin arayüzler olarak değil, şablon argümanları olarak iletilmesi gerektiği gerçeğine yol açar.

Burada birden çok arayüzü simüle etme versiyonumu tanımladım. Buna göre, sınıfım şöyle bildirilebilir:

Bana göre, her şey o kadar da kötü değil. Bence aynı C# içinde çok fazla temel ana arabirim yok (C# uzmanı değilim), bu nedenle yöntemleri tek bir temel üst sınıfa indirgenemez ve ardından herhangi biri tarafından miras alınamaz.

not Birden fazla IMHO uygulamak için <<<<>>>> gibi yapılar aracılığıyla bu bir şekilde tek bir yerden olur. İşlevleri operatörler aracılığıyla yapmak daha iyidir, örneğin, a==b a.compareto( b ) öğesini çağırır, a[comparer]==b Comparer.compare(a,b) öğesini çağırır, vb.
12345678910111213...28
Yeni yorum