dinamik olarak nesneler nasıl oluşturulur? (Bazı OOP şeyler) - sayfa 3

Yeni yorum
 

BTW, 1325'in işlevlere tanıtılan işaretçileri oluşturduğunun farkında mısınız?
Bu, üçgen iletişimin uygulanmasında herhangi bir fark yaratır mı?

MQL5: Olay modellerinin düzenlenmesini basitleştirmek için işlevlere işaretçiler için destek eklendi.

Bir işleve işaretçi bildirmek için "işlev işaretçisi" türünü belirtin, örneğin:

 typedef int (*TFunc)( int , int );

Şimdi, TFunc bir türdür ve değişken işaretçisini işleve bildirmek mümkündür: 

TFunc func_ptr;

func_ptr değişkeni, daha sonra bildirmek için işlev adresini saklayabilir:

 int sub( int x, int y) { return (x-y); }
int add( int x, int y) { return (x+y); }
int neg( int x)       { return (~x);  }

func_ptr=sub;
Print (func_ptr( 10 , 5 ));

func_ptr=add;
Print (func_ptr( 10 , 5 ));

func_ptr=neg;           // error: neg is not of  int (int,int) type
Print (func_ptr( 10 ));     // error: there should be two parameters

Fonksiyonlara yönelik işaretçiler parametre olarak saklanabilir ve iletilebilir. Statik olmayan bir sınıf yöntemine işaretçi alamazsınız.

 
İşlev işaretçilerinin kullanımının MT4 ile de uygulanıp uygulanmadığından emin değilim. Eğer öyleyse, elbette, bu tür işaretçiler diziler tarafından da yönetilebildiği sürece, bu şekilde yapmak da mümkündür, çünkü bu, sınıf işaretçileriyle mümkündür.
 

muhtemelen sadece MT5 içindir ve gördüğüm kadarıyla hala yöntemler için değil, sadece işlevler içindir.

Her neyse, temel sınıf içindeki üçüncü taraf yeteneğini, örneğin trend çizgisi ve konteyner bağlamında, 3. nesnenin nerede olduğunu hala anlamıyorum.

Ama tekrar okumaya çalışacağım.

 
OO ve MQL5 ile bağlantılı olarak olay modelini anlamada eksik olduğum şey, olayları göndermenin doğru türünün ne olduğudur.
Demek istediğim, kimin (hangi sınıfın) neyi (olay) alacağına nasıl ve nerede karar verileceği.
En iyi dağıtıcının, yerel dilin, yani ::OnChartEvent dilinin bir projede yalnızca bir kez, üst düzey sınıfta yazıldığı açıktır.

Öyleyse buradan, olayları farklı nesnelere göndermenin doğru yolu veya yolları nedir?
Gönderen bir olay sınıfı olmalı mı? Sadece if ifadelerine dayalı olarak ::OnChartEvent'te mi yapılmalı?
 
tamam, sanırım anladım. Prosedürden oop'a geldiğinizde gerçek bir kavram kayması sorunu var.
Sizi doğru anladıysam, demek istediğiniz şey, CTrendLine'ın, CTrade'in varlığını bilmek zorunda kalmadan, olay aracılığıyla bir CTrade miras nesnesine fiyat çaprazını bildirmesinin bir yolu, değil mi?
 
Amir Yacoby :
OO ve MQL5 ile bağlantılı olarak olay modelini anlamada eksik olduğum şey, olayları göndermenin doğru türünün ne olduğudur.
Demek istediğim, kimin (hangi sınıfın) neyi (olay) alacağına nasıl ve nerede karar verileceği.
En iyi dağıtıcının, yerel dilin, yani ::OnChartEvent dilinin bir projede yalnızca bir kez, üst düzey sınıfta yazıldığı açıktır.

Öyleyse buradan, olayları farklı nesnelere göndermenin doğru yolu veya yolları nedir?
Gönderen bir olay sınıfı olmalı mı? Sadece if ifadelerine dayalı olarak ::OnChartEvent'te mi yapılmalı?
Bu hiç soru değil. OOP, doğanın ilkelerine dayanmaktadır. Dünya sizi beslemez, sadece kaynakları sağlar ve neye, ne zaman ve nerede ihtiyacınız olduğu size kalmış.
 
Amir Yacoby :
tamam, sanırım anladım. Prosedürden oop'a geldiğinizde gerçek bir kavram kayması sorunu var.
Sizi doğru anladıysam, demek istediğiniz şey, CTrendLine'ın, CTrade'in varlığını bilmek zorunda kalmadan, olay aracılığıyla bir CTrade miras nesnesine fiyat çaprazını bildirmesinin bir yolu, değil mi?
evet iddia ediyorum.
 
bu nedenle aslında her CObject artık olayların alıcısı olan bir nesnenin yerine sahiptir ve ayrıca dinleme nesnesinin bu şekilde abone olması için bir kayıt yöntemine ve alıcı tarafından kullanılan bir olay gönderici yöntemine ve bir olay işleyici yöntemine sahiptir.

Bu güzel, bana gözlemci modelini hatırlatıyor, sadece gözlemcinin birden fazla olası alıcısı olduğunda, m_reciever bir nesne dizisidir.

Aslında, bir zamanlar gözlemciyi uygulamak istedim ve MQL'deki arayüz eksikliği veya çoklu kalıtım nedeniyle yapmadım. Aynı nesnenin arayüzü her iki tarafta da zorlayabileceği konusundaki iyi fikrinizi düşünmedim.


 
Amir Yacoby :
bu nedenle aslında her CObject artık olayların alıcısı olan bir nesnenin yerine sahiptir ve ayrıca dinleme nesnesinin bu şekilde abone olması için bir kayıt yöntemine ve alıcı tarafından kullanılan bir olay gönderici yöntemine ve bir olay işleyici yöntemine sahiptir.

Bu güzel, bana gözlemci modelini hatırlatıyor, sadece gözlemcinin birden fazla olası alıcısı olduğunda, m_reciever bir nesne dizisidir.

Aslında, bir zamanlar gözlemciyi uygulamak istedim ve MQL'deki arayüz eksikliği veya çoklu kalıtım nedeniyle yapmadım. Aynı nesnenin arayüzü her iki tarafta da zorlayabileceği konusundaki iyi fikrinizi düşünmedim.


Sadece sizi cesaretlendirmek için, MQL4 ile dinleyicileri çok kullanıyorum.
 
Ovo Cz :
Sadece sizi cesaretlendirmek için, MQL4 ile dinleyicileri çok kullanıyorum.

Teşekkürler ama cesaretli hissetmiyorum (:

Bunu yapmayı başardım, ancak yayıncı ile dinleyici arasındaki bir sözleşmeyle değil, yani yayıncı, dinleyicinin işleme yöntemine sahip olduğunu varsaymak zorunda kaldı, ancak hiçbir şey buna zorlamadı.
Veya tüm dinleyicileri bir ana dinleyici nesnesinden devralmam gerekirdi - ancak o zaman elbette tüm puanları kaybederdim çünkü diğer sınıfları devralamazlar.

Her neyse, programlamada profesyonelim ama kesinlikle henüz deneyimimin olmadığı OO'da değilim ve Doerk gibi deneyimli oo programcılarınızdan hiçbiriyle rekabet etmiyorum.
Bildiğim şey, prosedürel olmanın size iyi mantık ve programlama becerileri kazandırdığı, ancak geçişin zihinsel olarak zor olduğu, özellikle benim gibi prosedür odaklı bir OO çerçevesi oluşturma misyonuyla karşı karşıyaysa, bu tamamen farklı bir zihin durumudur. Ve GUI kısım çerçevesi, ilgilenilmesi gereken birçok olayla en ayrıntılı çerçevedir, sanırım sizler, çerçeveler arasında inşa edilmesi en zor olanı olduğu konusunda hemfikir olacaksınız.

12345
Yeni yorum