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

 

Kesinlikle. MQL ile kendi GUI çerçevemi oluşturmam aylarımı aldı, bunun gibi kütüphaneler oluştururken geçmişte edindiğim deneyimi hesaplamadım. En zor kısım olaylar değil, daha çok mimari ve tüm yuvalamalar ve özyinelemeler nedeniyle kodun hatalarını ayıklamanın neredeyse imkansızlığı, ayrıca hata ayıklama başladığında zaten geçersiz olan fare durumları nedeniyle.

Bu arada, aylar önce bu kütüphanelerle MQ'ya bir işbirliği teklif ettim ve ne yazık ki bir cevap bile alamadım. Ama gerçek şu ki, standart kontrol kitaplığı gerçekten mümkün olana kıyasla sadece güzel ama aynı zamanda kötü bir deneme. Biri çok daha iyisini yapabilir. Belki de buradaki pazar yerindeki kütüphaneyi teklif etmeliyim, ama bunun için tüm belgeleri yazmak için bir sürü işi korkutuyorum.

 
Doerk Hilger :
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ış.
Bununla ne demek istediğini söyleyebilir misin? Söylediklerinin genel hissini anlıyorum ama tam olarak net değil.
Yani, bir çerçeve oluştururken, sadece kaynakları sağlamaya mı özen gösteriyorsunuz? Bunu anlıyorum ama bir şekilde pratik yapmakta zorlanıyorum çünkü eğilimim çok güçlü.

Örneğin, bir çerçeve oluşturursam ve şimdi düğmeyi ve bir tür düğme kabı olan radyo düğmesini oluşturursam - radyo düğmesini oluşturmaya geldiğimde, eğilimim bağımlı nesne, bu durumda düğme üzerinde düşünmektir. ve onunla nasıl iletişim kurduğumu. Bu, prosedürel bir programlama alışkanlığı, geçmişinizde bir ara prosedürelden OO'ya geçiş yapıp yapmadığınızı merak ediyorum ve bu davaya odaklanmam için neye ihtiyacım olduğuna dair net bir görüşe beni yönlendirebilirsiniz. Çünkü radyo düğmesine daha çok düğmeye (bağımlı nesne) odaklanma eğilimindeyim.

Açıklığa kavuşturduğumdan emin değilim, bu sadece bir çerçevede bir seviye oluştururken odaklanılması gereken önemli şeylere dikkat çekmekle ilgili bir soru.
 
Amir Yacoby :
Bununla ne demek istediğini söyleyebilir misin? Söylediklerinin genel hissini anlıyorum ama tam olarak net değil.
Yani, bir çerçeve oluştururken, sadece kaynakları sağlamaya mı özen gösteriyorsunuz? Bunu anlıyorum ama bir şekilde pratik yapmakta zorlanıyorum çünkü eğilimim çok güçlü.

Örneğin, bir çerçeve oluşturursam ve şimdi düğmeyi ve bir tür düğme kabı olan radyo düğmesini oluşturursam - radyo düğmesini oluşturmaya geldiğimde, eğilimim bağımlı nesne, bu durumda düğme üzerinde düşünmektir. ve onunla nasıl iletişim kurduğumu. Bu, prosedürel bir programlama alışkanlığı, geçmişinizde bir ara prosedürelden OO'ya geçiş yapıp yapmadığınızı merak ediyorum ve bu davaya odaklanmam için neye ihtiyacım olduğuna dair net bir görüşe beni yönlendirebilirsiniz. Çünkü radyo düğmesine daha çok düğmeye (bağımlı nesne) odaklanma eğilimindeyim.

Açıklığa kavuşturduğumdan emin değilim, bu sadece bir çerçevede bir seviye oluştururken odaklanılması gereken önemli şeylere dikkat çekmekle ilgili bir soru.

Belki asıl noktayı kaçırdım ama size fikrimi söylemek istiyorum.

Bence çok fazla "teori" üzerindesin ve ışığı başkasından bekliyorsun. Tek bir mükemmel çözüm yok, çözümler var ve bunu deneyiminizden ve somut ihtiyaçlarınız üzerinden bulmanız gerekiyor.

Bu konu pratik bir vakadan başladı ve OOP hakkında belirsiz bir tartışma haline geldiğini biliyor. GUI ile ilgili ilginç bir dizi makale var , bir göz atmalı, ardından Standart Kitaplığı kullanarak ve bu makalelerden kitaplığı kullanarak bir arayüz oluşturmaya çalışmalısınız ve kodu inceleyin...ya da değil.

Sadece bir öneri, çünkü size nasıl daha iyi yardım edilebileceğini gerçekten anlamıyorum.

Graphical Interfaces I: Preparation of the Library Structure (Chapter 1)
Graphical Interfaces I: Preparation of the Library Structure (Chapter 1)
  • 2016.02.01
  • Anatoli Kazharski
  • www.mql5.com
This article is the beginning of another series concerning development of graphical interfaces. Currently, there is not a single code library that would allow quick and easy creation of high quality graphical interfaces within MQL applications. By that, I mean the graphical interfaces that we are used to in familiar operating systems.
 
Alain Verleyen :

Belki asıl noktayı kaçırdım ama size fikrimi söylemek istiyorum.

Bence çok fazla "teori" üzerindesin ve ışığı başkasından bekliyorsun. Tek bir mükemmel çözüm yok, çözümler var ve bunu deneyiminizden ve somut ihtiyaçlarınız üzerinden bulmanız gerekiyor.

Bu konu pratik bir vakadan başladı ve OOP hakkında belirsiz bir tartışma haline geldiğini biliyor. GUI ile ilgili ilginç bir dizi makale var , bir göz atmalı, ardından Standart Kitaplığı kullanarak ve bu makalelerden kitaplığı kullanarak bir arayüz oluşturmaya çalışmalısınız ve kodu inceleyin...ya da değil.

Sadece bir öneri, çünkü size nasıl daha iyi yardım edilebileceğini gerçekten anlamıyorum.

Alain, bir arayüz oluşturdum ve makaleleri okudum.
Belki de OO'yu tartışmanın yeri değil, haklı olabilirsiniz.
Bunu tartışmaya başladım çünkü Doerk konuyu yeni başlayanlara cevap olarak sundu ve doğru OO yaklaşımı hakkında konuştu.
Konuya yeni başlayanların kendisi Doerk'in OO sunumuyla ilgilendi ve bence bunu burada tartışmak doğal.
Belki çok teorik olduğu konusunda haklı olsanız da, yine de benim görüşüm, doğru OO'nun bazı teorileri dahil etmeden yapamayacağı ve sonunda pratik hale geldiğidir.

Benim sorunum OO doğru düşünmek, acaba Doerk'in deneyiminden sunduğum zihinsel zorluğu şans eseri bilip bilmediğini merak ettim.

 
Alain Verleyen :

GUI ile ilgili ilginç bir dizi makale var , bir göz atmalı, ardından Standart Kitaplığı kullanarak ve bu makalelerden kitaplığı kullanarak bir arayüz oluşturmaya çalışmalısınız ve kodu inceleyin...ya da değil.


Ne işe yaradığını görmek için indirdim. Ve ilk izlenim, Standart Kontrol Kitaplığı ile yaptıkları aynı kötü hataları yaptıklarını gösteriyor. Zaten tek bir iletişim penceresi olan ilk örnek, CPU kullanımını %10'dan (yok) %50-65'e (yüklü) yükseltiyor. Bu, yazarların böyle bir kitaplık geliştirmek için gerekli deneyime sahip olmadıklarının ve bunun doğru yapmanın bir yolu olamayacağının en iyi kanıtıdır.

MQ'nun nasıl (yapılmadığını) açıklamak yerine neden profesyonel bir GUI çerçevesi sağlamadığını anlamıyorum. MQL programcılarının çoğu kesinlikle EA'lar ve Göstergeler geliştirmek istiyor, ancak bu tür şeylerle uğraşmak istemiyor.

Ayrıca, örneklerinin paneli strateji test cihazında öldü ve bu, tüm bu GUI işlerinin zaten saçma olduğu yer. Bu size veya yazdıklarınıza karşı bir eleştiri değil, burada MQL için daha iyi kamuya açık şeyler olmadığını biliyorum.

 
Amir Yacoby :

Alain, bir arayüz oluşturdum ve makaleleri okudum.
Belki de OO'yu tartışmanın yeri değil, haklı olabilirsiniz.
Bunu tartışmaya başladım çünkü Doerk konuyu yeni başlayanlara cevap olarak sundu ve doğru OO yaklaşımı hakkında konuştu.
Konuya yeni başlayanların kendisi Doerk'in OO sunumuyla ilgilendi ve bence bunu burada tartışmak doğal.
Belki çok teorik olduğu konusunda haklı olsanız da, yine de benim görüşüm, doğru OO'nun bazı teorileri dahil etmeden yapamayacağı ve sonunda pratik hale geldiğidir.

Benim sorunum OO doğru düşünmek, acaba Doerk'in deneyiminden sunduğum zihinsel zorluğu şans eseri bilip bilmediğini merak ettim.

Burada OOP'yi tartışmak için bir sorun yok.

"OO bazı teorileri dahil etmeden yapamazsınız" konusunda hemfikir değilim, ama bu önemli değil.

 
Alain Verleyen :

Burada OOP'yi tartışmak sorun değil.

"OO bazı teorileri dahil etmeden yapamazsınız" konusunda hemfikir değilim, ama bu önemli değil.

Peki bu durumda kötü oo programlama olduğu gerçeğini nasıl açıklarsınız? Konuyu oluşturanların çözüm bulmaya çalıştığı konuya ve Doerks yanıtına bir göz atın. Doğru ile yanlış arasındaki farkı yaratan bir teori olmalı, değil mi?
 
Doerk Hilger :

Ne işe yaradığını görmek için indirdim. Ve ilk izlenim, Standart Kontrol Kitaplığı ile yaptıkları aynı kötü hataları yaptıklarını gösteriyor. Zaten tek bir iletişim penceresi olan ilk örnek, CPU kullanımını %10'dan (yok) %50-65'e (yüklü) yükseltiyor. Bu, yazarların böyle bir kitaplık geliştirmek için gerekli deneyime sahip olmadıklarının ve bunun doğru yapmanın bir yolu olamayacağının en iyi kanıtıdır.

MQ'nun nasıl (yapılmadığını) açıklamak yerine neden profesyonel bir GUI çerçevesi sağlamadığını anlamıyorum. MQL programcılarının çoğu kesinlikle EA'lar ve Göstergeler geliştirmek istiyor, ancak bu tür şeylerle uğraşmak istemiyor.

Ayrıca, örneklerinin paneli strateji test cihazında öldü ve bu, tüm bu GUI işlerinin zaten saçma olduğu yer. Bu size veya yazdıklarınıza karşı bir eleştiri değil, burada MQL için daha iyi kamuya açık şeyler olmadığını biliyorum.

Doerk, büyük ihtimalle haklısın ama benim amacım bu değil.

Bu CPU sorununun neden oluştuğuna dair somut bir örnek yazmalı, Anatoli'ye (makalelerin yazarı) sorunun ne olduğunu açıklamalısınız. Söylediğim için üzgünüm, %100 haklı olsanız bile şimdiye kadar söylediklerinizin neredeyse hiçbir faydası yok. Bu çok genel ve teorik. Suç yok.

 
Sorun şu ki, bu konu kesin talimatlar vermek için çok karmaşık. İşte bu yüzden ilgilenenlere bazı fikirler ve olası yollar sunmaya çalışıyorum. Ne yazık ki bir makale yazacak ya da tam olarak belgelenmiş bir kitaplık yayınlayacak zamanım yok. Afedersiniz.
 
Doerk Hilger :
Sorun şu ki, bu konu kesin talimatlar vermek için çok karmaşık. İşte bu yüzden ilgilenenlere bazı fikirler ve olası yollar sunmaya çalışıyorum. Ne yazık ki bir makale yazacak ya da tam olarak belgelenmiş bir kitaplık yayınlayacak zamanım yok. Afedersiniz.
shxxx. anladın