Benim yaklaşımım. Çekirdek - Motor. - sayfa 16
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım 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
Şu anda bir müşterim var. Kendilerine verilen görevleri çok hızlı bir şekilde tamamlarım. 3-4 saat ve yeni, tamamen işlevsel bir pencere hazır. Bir bağlantı arayüzü ile birlikte. Ayrıca motor hatalarını hızlı bir şekilde düzeltirim ve yeni sürümleri buna zorlarım. Birkaç günde 9 pencere + motor değişiklikleri, hata düzeltmeleri, eklenen özellikler... Her şey çok hızlı.
Çok fazla boş zamanınız olmalı.
Eh, tek başına yeterli olmadığını anlıyorsun. Motorunuzun kütle karakteri, diğer programcıların beğenip beğenmemesine bağlı olacaktır (tek başına tüm müşteriler için yeterli olmayacaksınız). Ve programı beğenmiyorsanız, o zaman ... ne yazık ki ve ah, yaratılışınızın kaderi şerefsiz olacak.
Programcıların motor koduna girmesine gerek kalmayacak. Bağlantı arayüzünü bir dosyada alacaklar. Bunu zaten test ettim. Her şey çalışıyor.
Şu anda bir müşterim var. Kendilerine verilen görevleri çok hızlı bir şekilde tamamlarım. 3-4 saat ve yeni, tamamen işlevsel bir pencere hazır. Bir bağlantı arayüzü ile birlikte. Ayrıca motor hatalarını hızlı bir şekilde düzeltirim ve yeni sürümleri buna zorlarım. Birkaç günde 9 pencere + motor değişiklikleri, hata düzeltmeleri, eklenen özellikler... Her şey çok hızlı.
Orada doğru yazılmış mı? Bir pencere oluşturmak için 3-4 saat ? Dakika değil mi?
Bunu bir yıldan fazladır yapıyorum. Ve kafam karışmadı.))
Karşılaştırma için, aynısını OOP kullanarak uygulayın. Bir dene, belki hoşuna gider. :)
Orada doğru yazılmış mı? Bir pencere oluşturmak için 3-4 saat ? Dakika değil mi?
Numara. Başka bir pencerenin kodunu kopyalayıp değişiklik yaparsanız dakikalar içinde yapabilirsiniz. Ancak, grafikleri düşünerek ve stil üzerinde çalışarak sıfırdan yaratmaktan bahsediyordum.
Bu arada Peter, göstergeler gibi çeşitli grafikler eklemeyi unutma, sadece pencerelerde, birkaç veri formatı desteği (OHLC, ZigZag, vb.). Umarım bunların hepsi projenizde kolayca uygulanır.
Deneyeceğim.
Deneyeceğim.
Denemem ama deneyeceğim.) Yaratılışınızın kullanışlılığını artırır.
Orada doğru yazılmış mı? Bir pencere oluşturmak için 3-4 saat ? Dakika değil mi?
bir tür saçmalık... düğmelerin, düzenlemelerin, etiketlerin yüksekliğini ve XY'sini ayarlamak için standart MT teslimatından kitaplıkları kullanarak bile MQL'de 3 pencere yapın 10 dakika ve 20-30 dakika daha çalışın...
Peter'ın çalışmasının neden yararlı olabileceğine dair 2 seçenek görüyorum:
- MQL kaynakları oluşturmak için ayrı bir uygulamanın oluşturulması, ör. GUI yapıcısı ve nasıl çalıştığının ayrıntılarına girmeyin, tabiri caizse Visual MQL++ )))
- veya: kendileri için zorluklar yaratan ve sonra bunları başarıyla aşan insanlar var © Wingston Churchill
Bana öyle geliyor ki Peter'ın tüm OOP üyeleri sürekli olarak ayrıntılara bağlı kalıyor.
Ve sorunun özü sadece sistemin felsefesinde ve mimarisindedir.
Burada, doğru bir şekilde, yukarıda Peter'ın avantajlarına ve rakiplerine - dezavantajları gibi görünen tartışmalı konuların neler olduğunu söylediler:
- küresel olarak kullanılabilen bir dizi değişken, tam bir kapsülleme eksikliği.
- tip kontrolünün olmaması
- belirli bir veri depolama uygulamasına sıkı bağlılık.
Ve Peter doğru bir şekilde OOP kavramının (en azından benim önerilerimde) "programcının rahatlığına dayanarak" basitleştirilmesi gerektiğini söyledi. Kapsülleme, tip kontrolü, arayüzler - tüm bunlar, mümkün olan en iyi şekilde, hata yapma, kafa karıştırıcı, yanlış kullanım olasılığını ortadan kaldırmak için tasarlanmıştır. Pekala.
Peter'ın konsepti tam tersi. Tüm verilere her yerden erişilebilir, kullanıcı kodun herhangi bir yerinden tüm program nesneleri üzerinde tam kontrole sahiptir ve herhangi bir tür kısıtlaması olmaksızın (belki de MQL'nin kendi kısıtlamalarıyla) onları istediği şekilde algılayabilir.
Peter, böyle bir kavramın - "maksimum gelişmeye ulaşmaya izin verdiğini" iddia ediyor. Kolaylık ikinci sırada geliyor.
Şahsen, bir programcı olarak, rahatlığın ikinci sırada yer almasından hoşlanmıyorum. Ancak, gerçekte önemli ölçüde daha büyük bir gelişme elde edersek, bu feda edilebilir. İşte, ne olduğunu görmek istiyorum. Kısıtlamalar ve kapsülleme ile OOP yaklaşımının, tek bir canavarca boyut dizisine atılan çok sayıda özelliğe tam erişime sahip bu yaklaşım gibi bir gelişmeye izin vermediği durumlarda. (Bütün bunları hatırlama ihtiyacından bahsetmiyorum).
Yukarıda belirtildiği doğrudur - yaklaşım Pascal'ın TurboVision'ına benzer. Bununla birlikte, bu kütüphanede hem tip kontrolü hem de kapsülleme kısıtlamaları zaten belirlenmişti.