Prosedürel kodun yapamayacağı hangi OOP kodu yapabilir? - sayfa 2

 
Doerk Hilger :
Programlama GUI'leri, bir programcı olarak tüm zamanımda en çok yaptığım şeydi. Eğer öyleyse, aksi takdirde birkaç yönde iletişim kurması gereken eksiksiz bir GUI'yi kodlamak mümkün değildir. Kodun okunamaz hale geleceğine ve sonunda çok yavaşlayacağına dair o kadar çok ifadeye ihtiyacınız olacak ki bu da hedefe ulaşamamanıza neden olacaktır. Hakikat.

Yanlış olduğunuzu kanıtlamak için prosedürel dilde bir GUI oluşturmayacağım. Ama hiç şüphesiz yapabilirdim.

Bu arada, OOP'de okunamayan ve çok daha yavaş kodu kodlamak da kolaydır ve bildiğiniz gibi Metaquotes Standard Library bunun iyi bir kanıtıdır.

 
Doerk Hilger :

...

Bir CPU'nun OOP hakkında hiçbir şey bilmemesi durumundan dolayı - elbette - sadece işaretçiler ve karmaşık diziler kullanmadan her şeyi kodlayabilirsiniz. Ama bu çok saçma. Ayrıca ekran içeriğimi gerçek zamanlı olarak filme çeken ve duvardaki bir ışık projektörü ile sırayla ışınlayan 10000 kişiyi işe alabilirdim. Bu da hedefe ulaşıyor mu?

Windows işletim sisteminin iyi bir GUI sunduğuna katılıyor musunuz? Bildiğim kadarıyla C ile yazılmış. Prosedürel dilde OOP değil.

Karmaşık bir programın yalnızca OOP ile oluşturulabileceğini düşünüyorsanız, yanılıyorsunuz Dirk. OOP ile kodlamanın neden daha iyi olduğunu açıklamanız gerekir.

 
Doerk Hilger :
Hadi ama ;) Pek değil ;) Yerli bir şey işi bir şekilde garip yapabilirse, o zaman işaretçileri, ancak MQL'de kısıtlamalar var. Aksi takdirde ... kod saçma olur.
İşlev işaretçileri MQL5'te zaten tanıtılmıştır ve MQL4 muhtemelen bu özelliği de destekleyecektir. Prosedürel kod saçma OLMAYACAKTIR, çünkü uzun yıllar boyunca OOP ana akım haline gelmeden önce kodlamanın tek yolu buydu. Prosedürel kod, genel olarak benzer OOP'ye kıyasla daha karmaşık ve anlaşılması daha zor görünecektir - hepsi bu.
 
Alain Verleyen :
OOP'nin daha kısa bir kodlama yolu olduğundan kesinlikle şüpheliyim.
Tabii ki, önemsiz bir fonksiyon vakası değil, kod ayrıştırma , bağımlılık kontrolü ve diğer benzer personel gerektiren bir tür gerçek dünya görevi demek istiyorum.
 
Alain Verleyen :

Windows işletim sisteminin iyi bir GUI sunduğuna katılıyor musunuz? Bildiğim kadarıyla C ile yazılmış. Prosedürel dilde OOP değil.

Karmaşık bir programın yalnızca OOP ile oluşturulabileceğini düşünüyorsanız, yanılıyorsunuz Dirk. OOP ile kodlamanın neden daha iyi olduğunu açıklamanız gerekir.

GUI'leri Assembler'da tamamen kodladım. Ancak Assembler'da işaretçiler ile çalışabilirim, C'de işaretçiler ile çalışabilirim ve tabii ki Windows'un temeli OOP değil, ancak geçersiz işaretçileri yerel şekilde desteklemeyen MQL hakkında konuşuyoruz ve bu nedenle, olmayacaksınız. Karmaşık GUI'leri, en azından büyük bir performans eksikliği olmadan kullanılabilecek bir sonuçla değil, ancak o zaman başka bir şekilde kodlayabilir.

Ve bu cevap, OOP ile neden daha iyi olduğu sorusunu zaten içeriyor - burada "daha iyi" hala yanlış sıfattır. OOP yöntemi, bu tür işaretçilerin kullanımını uygular, ancak sizi bunlarla uğraşmaya zorlamaz. Dahili olarak, OOP, fonksiyon ve değişken işaretçiler için çok boyutlu dizilerle gerçekleştirilir. Böyle şeyleri kodlamaya çalışmak, asla önünüzde olan tekerlek kadar yumuşak bir şekilde yuvarlanmayacak bir tekerleği yeniden icat etmekle tamamen aynı şeydir.

 
Doerk Hilger :

GUI'leri Assembler'da tamamen kodladım. Ancak Assembler'da işaretçiler ile çalışabilirim, C'de işaretçiler ile çalışabilirim ve tabii ki Windows'un temeli OOP değil, ancak geçersiz işaretçileri yerel şekilde desteklemeyen MQL hakkında konuşuyoruz ve bu nedenle, olmayacaksınız. Karmaşık GUI'leri, en azından büyük bir performans eksikliği olmadan kullanılabilecek bir sonuçla değil, ancak o zaman başka bir şekilde kodlayabilir.

Ve bu cevap, OOP ile neden daha iyi olduğu sorusunu zaten içeriyor - burada "daha iyi" hala yanlış sıfattır. OOP yöntemi, bu tür işaretçilerin kullanımını uygular, ancak sizi bunlarla uğraşmaya zorlamaz. Dahili olarak, OOP, fonksiyon ve değişken işaretçileri için çok boyutlu dizilerle gerçekleştirilir. Böyle şeyleri kodlamaya çalışmak, asla önünüzde olan tekerlek kadar yumuşak bir şekilde yuvarlanmayacak bir tekerleği yeniden icat etmekle tamamen aynı şeydir.

Ben bir GUI uzmanı değilim, bu yüzden daha fazla tartışmayacağım. Amacını şu şekilde anladım: OOP, aksi takdirde daha az verimli olacak veya çok fazla iş anlamına gelebilecek karmaşık yazılımlar oluşturmaya izin verir.
 

Küçük(!) tecrübemden dolayı sadece kişisel tercihimdir!

1) Örneğin Java'dan hoşlanmıyorum, çünkü adının ne olabileceğini bilmeden zamanın% 99'unu arıyordum, var olup olmadığını ve yine de kendim kodlamam gerekip gerekmediğini ...

2) C++'ı sevmiyorum çünkü mq4 ve hatta Perl gibi bir dil gibi bir betik yazmak için ihtiyacım olandan daha fazlasını yazmam gerekiyor.

3) C++'ı sevmiyorum çünkü başka birinin kodunu anlamak, dosyadan dosyaya atlamama izin veriyor, burada yalnızca 2,3 satırlı işlevler buluyorum, bu da neyin ve nasıl olduğunu bulmayı gerçekten zorlaştırıyor. hesaplanır. Elbette "durdurma hesabı" gibi açıklamalar var ama hesap prosedürü de farklı dosyalarda çeşitli işlevlere bölünmüş durumda.

4) Numaralandırma ve numaralandırma değişkenleri dizileri konusunda kesinlikle iyiyim. Hayali gerçek nesneleri kodlamama gerek yok. GUI'ler, onları yeniden kullanmanın kolay bir yolu için nesneler olarak kodlanabilecek birçok başka şeyden oluştuğu için farklı bir sorun olabilir. Ancak bir EA'nın kaç farklı nesneye ihtiyacı vardır? Pozisyonlar için bir tane mi? Çok sayıda farklı 'nesne' (GUI) olsaydı, yardımcı olabilirdi - ama onları burada göremiyorum.

5) Son olarak, MQ5 hala müşteri keneleri üzerinde geriye dönük testini çalıştıramıyor :( <Moderatör tarafından konu dışı olarak düzenlendi: bunun mql5 ile değil MT5 ile ilgisi var>

 
Kodları bir araya getiren birine gerçekten saygı duyuyorum, donanımın kendisinin nasıl çalıştığına dair iyi bir bilgiye sahip olmalısınız, tek kelimeyle harika, bugün kimsenin kullanmadığı zor
 
coringajoker :
Kodları bir araya getiren birine gerçekten saygı duyuyorum, donanımın kendisinin nasıl çalıştığına dair iyi bir bilgiye sahip olmalısınız, tek kelimeyle harika, bugün kimsenin kullanmadığı zor

Artık kodlamıyorum, ama geçmişte gerçekten esas olarak. Intel 80x86 yongalarında, görsel performans açısından gerçek bir avantaj elde etmek için tek şans buydu. Ve elbette, bu, artık ayrıntılı olarak ihtiyacım olmasa bile, kaçırmak istemediğim temel bir bilgidir, ancak sonunda kodunuza ne olduğunu her zaman bilirsiniz ve bunu bir avantaj olarak nasıl kullanacağınızı bilirsiniz. yürütme hızının görünümü.

Evet "iyi" eski zamanlar ;) ... Ama çılgınca da, değişkenler bile yoktu, gerçek işlevler yoktu, eğer öyleyse hayır, sadece kayıtlar, yığınlar, kesintiler ve bellek adresleri. çılgın bişi :)

 

OOP, yeniden kullanılabilir küçük parçalara bölünmüş kod için bir araçtır. Ancak en iyi bölüm şablonlardır. Bu özellik, kodu basitleştirmenize izin verir. En iyi örnek dizi sınıfıdır. Java'da tür için bir sınıf oluşturdunuz . C++ ve Mql5'te, gereksiz kodu azaltan ve ilkelleri ve nesneleri karıştırırken bazı sorunları atlayan tek bir sınıfa sahip olabilirsiniz.

Not: ASM hakkında, eski usul. İlk koruma modu derleyicilerinden önce kullandım ve üst geçit sınırlamaları komikti. Selektörlü 64K segmentler o zamanlar kodlayıcıların kabusuydu. Ne zaman yanlış yere yazsan bilgisayarı yeniden başlatıyordun :)