Benim yaklaşımım. Çekirdek - Motor. - sayfa 139

 
Georgiy Merts :

Ne millet, Peter'ı OOP'nin faydalarına ikna etmeye mi çalışıyorsunuz?

Artyom Trishkin :

Burada boş yere boncuk atıyorsunuz.

Haklısınız, bunların hepsini biliyorum ve çok iyi anlıyorum. Ama görünüşe göre Peter, "istemiyorum, yapmayacağım" ile OOP-ruhumun bazı zihinsel dizilerine dokunuyor, bu yüzden sürekli olarak bu sonsuz tartışma ve münakaşa açıklamalarına giriyorum.

 
Реter Konow :

Ve motor, bir metin dosyasından çekirdekleri yükleyecektir. Bunu yapmak zor değil.

Temiz, açık, belirgin. Evet, bu daha iyi. Onlar. çekirdeğiniz bir metin dosyasıdır - aslında, motor için bir grup ayardır.

 
Реter Konow :

Hayır, Vasily, her şeyi dramatize etme eğilimindesin.))

Yapıcı, tıklandığında tüm dosyaları yazdıran bir düğmeye sahiptir.

Ve motor, bir metin dosyasından çekirdekleri yükleyecektir. Bunu yapmak zor değil.

dikkatimi dağıttığım için üzgünüm, ama sadece merak ediyorum - refactor nasıl olmalı? örneğin, başarısız isimleri veya genel olarak öğelerin bileşimini / düzenini değiştirin

 
Vasiliy Sokolov :

Temiz, açık, belirgin. Evet, bu daha iyi. Onlar. çekirdeğiniz bir metin dosyasıdır - aslında, motor için bir grup ayardır.

Evet. Aynen öyle. Motorun belirli bir GUI oluşturması ve onunla çalışması için gereken tüm bilgiler. Şimdi onu doğrudan motora yüklüyorum ve ardından yapıcının yazdırdığı bir dosyadan yüklenebilir hale getireceğim.

 
Maxim Kuznetsov :

dikkatimi dağıttığım için üzgünüm, ama sadece merak ediyorum - refactor nasıl olmalı? örneğin, başarısız isimleri veya genel olarak öğelerin bileşimini / düzenini değiştirin

Hepsi yapıcıda. KIB kodu yazılır ve dosya yeniden derlenir.

Yapıcı ile nasıl çalışacağınız aşağıda açıklanmıştır https://www.mql5.com/ru/blogs/post/717782

 
Vasiliy Sokolov :

Veya başka bir örnek. Geçenlerde, aynı anda birden fazla enstrümanla işlem yapabilmesi için prosedürel bir EA'yı değiştirmem istendi (aynı grafikte başlatıldı). Prosedürel bir tarzda, aynı anda farklı semboller üzerinde bağımsız olarak ticaret yapmasını sağlamak çok uzun ve zor bir numara alacaktır. Tüm prosedür kodunu bir sınıfa yerleştirdim ve bunun üç örneğini oluşturdum. Her birine, çalışan bir sembol vb. dahil olmak üzere ayrı bir ayar seti verildi. Kod, ilk seferde olması gerektiği gibi çalıştı. Kullanıcı mutluydu.

Bu hafta buna benzer bir örneğim vardı, bir danışman yapmamı istediler, bir TF'de bir bar açıldığında alımları açıyor ve başka bir TF'de bir bar açıldığında satışları açıyor, ne olduğunu bile anlamadım. bana ilham verdi))

ancak yeni bir çubuk tanımlamanın banal işlevini aldı ve bir sınıfa yeniden yazdı ve yeni çubuk tanımlama sınıfının 2 örneğini yarattı, yapıcıyı başlatırken, TF dönemini parametre olarak geçti

5 dakika çalışır, ancak her şeyin çalışması garanti edilir ve NewBar_TF1() , NewBar_TF2() .... işlevlerinin adlarında herhangi bir karışıklık olmaz, çünkü kullanıcı tarafından TF ayarlarını değiştirdikten sonra başlatmak uygun olur - silindi DeInit() içindeki nesne, nesneyi ONInit() içinde yarattı

IMHO, OOP kullanışlı ve pratiktir

 
Реter Konow :

Hepsi yapıcıda. KIB kodu yazılır ve dosya yeniden derlenir.

Yapıcı ile nasıl çalışacağınız aşağıda açıklanmıştır https://www.mql5.com/ru/blogs/post/717782

ancak olaylardaki tüm özel düzenlemeleri-bağlamaları da geçersiz kılar mı?
 
Реter Konow :

Evet. Aynen öyle...

Bu yüzden motorunuzla ilgili çok fazla kafa karışıklığı başkalarının başına gelir. Sisteminizin elemanlarına standart olmayan isimler veriyorsunuz. Bir çekirdek değil - ancak otomatik olarak oluşturulmuş bir ayarlar dosyası.

 
Maxim Kuznetsov :
ancak olaylardaki tüm özel düzenlemeleri-bağlamaları da geçersiz kılar mı?

Daha ayrıntılı olarak açıklayın.

 
Vasiliy Sokolov :

Bu yüzden motorunuzla ilgili çok fazla kafa karışıklığı başkalarının başına gelir. Sisteminizin elemanlarına standart olmayan isimler veriyorsunuz. Bir çekirdek değil - ancak otomatik olarak oluşturulmuş bir ayarlar dosyası.

Yani dosya yazdırılan çekirdeklerdir. Birkaç tane var.