Mt4 End desteği. - sayfa 11
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
Vladimir :
Belki arayüzü kullanıcıyla düzenlemek için? OOP için birçok seçeneğin yığıldığı yer burasıdır, bir Delphi görsel bileşenleri kitaplığı bir şeye değer. Danışmanlar ve komut dosyaları, bilgisayardaki bir kişiyi değiştirmek için tasarlanmıştır, bu arayüz doğrudan amaçlarıyla çelişir, buna gerek yoktur. Yani müdahale ediyor. Tıpkı bir çakıdaki fazladan eşyalar gibi. Veya evrensel bir çekiçin çelik sapının ucundaki bir çivi çektirmesi - sadece çizilmekle kalmaz, aynı zamanda ağırlık merkezini vurucudan sapa kaydırır.
Bu hususta size katılmıyorum.
Bugün tam otomatik bir danışmanın yarı otomatik bir danışmandan çok daha az etkili olduğunu anlayan algoritmik tüccarlar tarafından bir grafik arayüze ihtiyaç duyulabilir. Otomatik ve manuel ticareti birleştirmek, ticaret açısından daha profesyonel ve karlı olabilir. İnsanlar bunu anladığında, robotlarının kesinlikle bir arayüze ihtiyacı olacak.
1. Chart_id, Rusça konuşan bir kişi tarafından m_chart_id'den daha hızlı okunur.
2. Programda yüzlerce değişken varsa, o zaman Rus dili vazgeçilmez bir destek sağlar.
Bütün bunlar deneysel olarak doğrulanabilir.
Ana dilde kodu okuma ve anlama hızı her zaman daha yüksek olacak ve ezberleme daha iyi olacaktır.
Değişkenleri Rusça olarak adlandırmak için kurallar geliştirmeniz yeterlidir. "variable_to_store_the_total_profit_of_position" yerine basitçe: Total_profit.
Programda yüzlerce değişken varsa, bunların çoğu kesinlikle yapılarla birleştirilebilir. Ayrıca, işlevleri kullanmayı unutmayın.
Birçok değişken anlamsal bir yük taşımaz, çünkü sayaçlardır, ara verilerin geçici depolarıdır ve bir parantez yığınının arkasında kullanılır. Ve en iyi yanı, tüm parantezlerden sonra aynı değişkenleri tekrar kullanabilirsiniz, ancak yine parantez {....}
Veya başlangıçta OOP ile yazın.
Bence OOP'yi reddetmesinin özü burada yatıyor. Elbette yanılıyor olabilirim, ama genellikle insanları hissederim.
Bana göre FKÖ'yü kabul etmeyen çoğunluğun sorunu, "yasal hakların kısıtlanmasına" karşı iç direniştir.
Eski tarz programcı, herhangi bir zamanda herhangi bir veriye, herhangi bir bloğa, programın herhangi bir özüne tam erişime sahip olduğu gerçeğine alışmıştır. Ve OOP yaklaşımı - tam tersi anlamına gelir - verilerin ve programın eylemlerinin çok küçük bir kısmına erişiminiz olduğunda hakların maksimum kısıtlaması.
Hatırladığım kadarıyla, gerçekten sevmedim. Windows'un henüz başlangıcında, belleğe korumalı erişimden nasıl çok öfkelendiğimi hatırlıyorum - nasıl, sevdiğim adrese erişme fırsatım yok, peki ya sistemdeyse çekirdek? Belki de programdan okumak ya da değiştirmek istiyorum! Sistem kısıtlamalarını atlayarak "yasak" alandan "izin verilen alana" veri gönderecek bir doğrudan bellek erişim denetleyicisi programladığı noktaya geldi.
Ancak zamanla, tüm bu kısıtlamaları gerçekten takdir ettim. "Gereksiz" erişim her zaman hatalara neden olabilir. Bu nedenle erişim denetimi çalışmasını derleyiciye aktarmak çok mantıklıdır. Buradaki erişimin kısıtlanması, "haklarınızın ihlali" değil, "aptallardan korunma" haline gelir. Sahip olmadığınız bir erişime ihtiyacınız varsa - bu sadece yanlış sistem tasarımı anlamına gelir - ihtiyaç duyulduğu için böyle bir erişim olasılığını sağlamak gerekiyordu.
Ve şimdi - aksine, erişimi her zaman maksimumla sınırlandırıyorum. Herhangi bir noktada, yalnızca gerekli olan varlıklara erişim olmalıdır. Diğer tüm nesneler - erişilemez olmalıdır. Bu, erişmemeniz gereken yerlere erişimde hata yapmanızı engeller ve ayrıca her işlemin tek bir yerde gerçekleştirildiği ve başka hiçbir yeri etkilemediği belirli bir sistem geliştirme sırasını öğretir.
Örneğin, kütüphane biçimindeki kapanımlara katlanamıyorum, aptalca çünkü orada ne doldurduklarını ve bana nasıl yardımcı olacağını bilmiyorum, bir düzine daha fazla fonksiyon yazmak daha kolay
Peter Konow'a benzeterek.
Ve neden ?
Aynı işlev birçok yerde gereklidir - neden her şeyi kütüphanelerde bulundurabileceğiniz ve ana kodu gereksiz bloklarla karıştırmadığınız zaman kopyala-yapıştır işlevleri?
Ve neden ?
Aynı işlev birçok yerde gereklidir - neden her şeyi kütüphanelerde bulundurabileceğiniz ve ana kodu gereksiz bloklarla karıştırmadığınız zaman kopyala-yapıştır işlevleri?
Nikolay'ın argümanları nasıl bulduğunu biliyorsun.)
Büyükanne de her şeyi sorunsuz öğrenebilir. Sadece bilinçaltında, yerleşik zihnini gereksiz bilgi döngüsüne sürüklemek için bir tür biblo istemiyor. Doğru yapar.)
Peter, yani sen bir büyükannesin.
Merhaba
Belki burada bana yardımcı olabilirler. MT4 geliştiricilerine bir sorum var. Nerede seslendirilebilir? Bu forumda ise, hangi başlıkta? Veya başka bir yerde? Eğer biliyorsan, lütfen bana söyle.
Bu hususta size katılmıyorum.
Bugün tam otomatik bir danışmanın yarı otomatik bir danışmandan çok daha az verimli olduğunu anlayan algoritmik tüccarlar tarafından bir grafik arayüze ihtiyaç duyulabilir. Otomatik ve manuel ticareti birleştirmek, ticaret açısından daha profesyonel ve karlı olabilir. İnsanlar bunu anladığında, robotlarının kesinlikle bir arayüze ihtiyacı olacak.
Mql'nin yalnızca sunucu erişim işlevlerine sahip olması gerektiğini ve diğer her şeyin üçüncü taraf geliştirme araçlarıyla koltuk değnekleri aracılığıyla programlanması gerektiğini söyleyen kişiyi tam olarak destekliyorsunuz. Parti çizgisinden sapmayın. Tutarlı olun - tüm gelişmelerinizi mql'ye aktarın ve bir köprü yapın - örneğin bir stüdyoya - veya tuvallerinizi orada boyayacağınız yere ... Ardından değirmen üzerindeki bir sonraki zaferiniz hakkında rapor verin.
Örneğin, kütüphane biçimindeki kapanımlara katlanamıyorum, aptalca çünkü orada ne doldurduklarını ve bana nasıl yardımcı olacağını bilmiyorum, bir düzine daha fazla fonksiyon yazmak daha kolay
Peter Konow'a benzeterek.
Peki, enerjinin korunumu yasası: neden kütüphaneyi çözelim ve her şey onsuz çalışıyorsa onu anlayalım?
ZY
geyiğim bir araya geldi mi?
Kodlarınız 10, 20, 30, ..., 100 bin satırı aşmaya başlayınca geri gelin ve kodlarınızı bu kadar hacimde nasıl kopyala-yapıştır yaptığınızı anlatın.
Bana göre FKÖ'yü kabul etmeyen çoğunluğun sorunu, "yasal hakların kısıtlanmasına" karşı iç direniştir.
Eski tarz programcı, herhangi bir zamanda herhangi bir veriye, herhangi bir bloğa, programın herhangi bir özüne tam erişime sahip olduğu gerçeğine alışmıştır. Ve OOP yaklaşımı - tam tersi anlamına gelir - verilerin ve programın eylemlerinin çok küçük bir kısmına erişiminiz olduğunda hakların maksimum kısıtlaması.
Hatırladığım kadarıyla, gerçekten sevmedim. Windows'un henüz başlangıcında, belleğe korumalı erişimden nasıl çok öfkelendiğimi hatırlıyorum - nasıl, sevdiğim adrese erişme fırsatım yok, peki ya sistemdeyse çekirdek? Belki onu programdan okumak ya da değiştirmek istiyorum! Sistem kısıtlamalarını atlayarak "yasak" alandan "izin verilen alana" veri gönderecek bir doğrudan bellek erişim denetleyicisi programladığı noktaya geldi.
Ancak zamanla, tüm bu kısıtlamaları gerçekten takdir ettim. "Gereksiz" erişim her zaman hatalara neden olabilir. Bu nedenle erişim denetimi çalışmasını derleyiciye aktarmak çok mantıklıdır. Buradaki erişimin kısıtlanması, "haklarınızın ihlali" değil, "aptallardan korunma" haline gelir. Sahip olmadığınız bir erişime ihtiyacınız varsa - bu sadece yanlış sistem tasarımı anlamına gelir - gerekli olduğu için böyle bir erişim olasılığını sağlamak gerekiyordu.
Ve şimdi - aksine, erişimi her zaman maksimumla sınırlandırıyorum. Herhangi bir noktada, yalnızca gerekli olan varlıklara erişim olmalıdır. Diğer tüm nesneler - erişilemez olmalıdır. Bu, erişmemeniz gereken yerlere erişimde hata yapmanızı engeller ve ayrıca her işlemin tek bir yerde gerçekleştirildiği ve başka hiçbir yeri etkilemediği belirli bir sistem geliştirme sırasını öğretir.
OOP'nin neyi reddedebileceğine dair iyi bir örnek verdiniz.
Benim durumumda, biraz farklıydı. OOP çalışmasına kararlılıkla başladım, ancak belirli bir aşamada onu kullanmanın herhangi bir pratik faydasını görmeyi bıraktım. Şimdiye kadar, bu değişmedi. Hepsi, OOP'yi uygulamamdan çıkmaya zorlayan yaklaşımımı oluşturduğum için.
İşte bu ifade - erişimin kısıtlanması, hatalardan kurtaran gerekli bir korumadır, hiçbir şekilde anlayamıyorum. Programın farklı bölümlerindeki değişken isimlerinin tesadüfi ile - şüphesiz evet. Ancak bir dizideki tüm ana global değişkenlerin ortak bir global hafızası varsa, kısıtlamalara gerek yoktur ve karışıklık olmaz.