OOP vs prosedürel programlama
Burada bir holivar oluşturmak istemiyorum, ancak merak ediyorum, OOP destekçileri, bu çözümün OOP'siz bir çözümden daha verimli olduğu açıkça görülen bazı sorunları çözen bir kod sağlayabilir mi?
Ben OOP'siz bir problem çözücüyüm ve OOP'lu bir problem çözücü ile rekabet etmek istiyorum.
Burada bir holivar oluşturmak istemiyorum, ancak merak ediyorum, OOP destekçileri, bu çözümün OOP'siz bir çözümden daha verimli olduğu açıkça görülen bazı sorunları çözen bir kod sağlayabilir mi?
Ben OOP'siz bir problem çözücüyüm ve OOP'lu bir problem çözücü ile rekabet etmek istiyorum .
Bu, karşılaştırmayı yeniden oluşturabileceğiniz platform değildir - program tek sayfadır (tek dosya). Burada istediğiniz gibi yazabilirsiniz ve programa erişim ve performans neredeyse aynı seviyede kalacaktır. Her ne kadar herhangi bir yazı tarzında, hatta prosedürel, hatta OOP'de bile pisliği mahvedebilseniz de.
Bu, karşılaştırmayı yeniden oluşturabileceğiniz platform değildir - program tek sayfadır (tek dosya). Burada istediğiniz gibi yazabilirsiniz ve programa erişim ve performans neredeyse aynı seviyede kalacaktır. Her ne kadar herhangi bir yazı tarzında, hatta prosedürel, hatta OOP'de bile pisliği mahvedebilseniz de.
ben seni pek anlamadım "Tek sayfalık program" ne anlama geliyor? İki farklı yaklaşımla bir problemin çözümlerinin basit bir karşılaştırmasını yapmak mümkündür. Karşılaştırma yaparken her çözümü ana kriterlere göre değerlendirin: çözümün kendisi, kodun kısalığı, kodun okunabilirliği .
Programlamada ana kriterler bu kriterlerdir.
- www.metatrader5.com
Yüzlerce satıra yayılan devasa kod blokları yazarım. Neredeyse yorumsuz. OOP yok. Rusça kod. Her şey çok verimli çalışıyor. Yaklaşık 100 bağlantılı dosya olmasına rağmen programda yönlendirme ile ilgili bir sorunum yok. Muhtemelen buna zaten alıştığım ve her şeyi uzun zamandır hatırladığım için. Bu nedenle, ana şey programınızı bilmek ve iyi anlamaktır, gerisi ikincildir. BENİM NACİZANE FİKRİME GÖRE.
İşin "verimliliğine" gelince, tartışılabilir.
Aynı şey değiştirilebilirlik için de geçerlidir - kodunuz farklı bir hassasiyetteki alıntılarda kullanılacaksa - değişiklik gerektirecek mi ve bunları uygulamak kolay olacak mı?
Bu tür projelerde temel sorun sadece değişiklik yapmaktır. Uygulamanın gösterdiği gibi - ne kadar çok blok - değişiklik sırasında hata verme olasılığı o kadar yüksektir. Yorumların olmaması bir artı değil, eksidir. Bu yüzden hatırlanacak çok şey var.
Burada bir holivar oluşturmak istemiyorum, ancak merak ediyorum, OOP destekçileri, bu çözümün OOP'siz bir çözümden daha verimli olduğu açıkça görülen bazı sorunları çözen bir kod sağlayabilir mi?
Ben OOP'siz bir problem çözücüyüm ve OOP'lu bir problem çözücü ile rekabet etmek istiyorum.
Yukarıda zaten böyle bir kod sağladım. Ticaret geçmişi ile çalışmanın yapıldığı tamamen sanal bir arayüz var. Aynı sistemi mevcut konumla çalışırken ve diğer benzer yerlerde kullandım.
OOP sayesinde, işin tam bütünlüğü hem MT4 hem de MT5'te ve MT5'te - bir riskten korunma veya netleştirme sistemi olup olmadığına bakılmaksızın - gerçekleştirilmektedir.
Ek olarak, OOP sayesinde, büyüleri farklı olan birkaç TS'yi tek bir Uzman Danışman içinde kolayca kullanabilirim.
Özünde, OOP sadece kod bakımını basitleştirmek için icat edildi. Aynı zamanda, yazarken yüksek maliyetler ödemek zorundasınız. Kod yazarsanız, değişiklik yapmadan kullanın ve ardından silin, o zaman gerçekten de OOP ile uğraşmanın bir anlamı yoktur. OOP, tam olarak aynı kodun birçok yerde gerekli olduğu ve periyodik olarak değiştirilmesi gerektiğinde avantajlıdır.
Buna göre, OOP'nin kapsamı ve uygulanmaması, tam olarak kodu destekleme ve değiştirme ihtiyacına göre belirlenir.
İşin "verimliliğine" gelince, tartışılabilir.
Aynı şey değiştirilebilirlik için de geçerlidir - kodunuz farklı bir hassasiyetteki alıntılarda kullanılacaksa - değişiklik gerektirecek mi ve bunları uygulamak kolay olacak mı?
Bu tür projelerde temel sorun sadece değişiklik yapmaktır. Uygulamanın gösterdiği gibi - ne kadar çok blok - değişiklik sırasında hata verme olasılığı o kadar yüksektir. Yorumların olmaması bir artı değil, eksidir. Bu yüzden hatırlanacak çok şey var.
Blokların çok yönlülüğü de bir diğer değerlendirme kriteridir. Tabii ki, blok çok çeşitli görevler için kullanılmalı ve değişen koşullara kolayca uyum sağlamalıdır. bende tam olarak bu var Örneğin, sözde "odak" teknolojisini kullanıyorum. Yani ana parametrelerin değerleri global değişkenlerde her zaman sabittir ve bu değişkenler tüm bloklara yapıştırılır.
Blokların çok yönlülüğü de bir diğer değerlendirme kriteridir. Tabii ki, blok çok çeşitli görevler için kullanılmalı ve değişen koşullara kolayca uyum sağlamalıdır. bende tam olarak bu var Örneğin, sözde "odak" teknolojisini kullanıyorum. Yani ana parametrelerin değerleri global değişkenlerde her zaman sabittir ve bu değişkenler tüm bloklara yapıştırılır.
Korkarım global değişkenler de bir eksi. Tüm bloklarda mümkün olduğunca az global değişken bulunmalıdır. Öyle ki, her blok yalnızca ihtiyaç duyduğu verileri alır ve mümkün olan her yerde - yalnızca sabit bir biçimde, böylece değişikliklerin ima etmediğini değiştirmek mümkün olmaz.
Projelerimde yalnızca iki global değişken var - bu, işlevleri Init(), OnTick() ve diğer olayların işlevselliğini içine alan CExpert sınıfının bir nesnesi ve izlemenin içine girdiği bir günlük dosyası olan CLogFile nesnesidir. çıktı, çünkü izleme makroları programın herhangi bir yerinden çalışması gerekir.
Bana göre hafızaya güvenmek en iyi çözüm değil, çünkü en azından Sherlock Holmes'un dediği gibi, gerekli bilgi bir anda gereksiz bir çöp dağının altına gömülecek. Eh, aynı zamanda hafızayı da bozabilir.
Korkarım global değişkenler de bir eksi. Tüm bloklarda mümkün olduğunca az global değişken bulunmalıdır. Öyle ki, her blok yalnızca ihtiyaç duyduğu verileri alır ve mümkün olan her yerde - yalnızca sabit bir biçimde, böylece değişikliklerin ima etmediğini değiştirmek mümkün olmaz.
Projelerimde yalnızca iki global değişken var - bu, işlevleri Init(), OnTick() ve diğer olayların işlevselliğini içine alan CExpert sınıfının bir nesnesi ve izlemenin içine girdiği bir günlük dosyası olan CLogFile nesnesidir. çıktı, çünkü izleme makroları programın herhangi bir yerinden çalışması gerekir.
Bana göre hafızaya güvenmek en iyi çözüm değil, çünkü en azından Sherlock Holmes'un dediği gibi, gerekli bilgi bir anda gereksiz bir çöp dağının altına gömülecek. Eh, aynı zamanda hafızayı da bozabilir.
Pratikte karşılaştırmamız gerekiyor. Aksi takdirde, bu gereksiz bir tartışmadır.
Neden "işe yaramaz"? Çok kullanışlı.
Ancak pratikte "destek kolaylığı" nasıl karşılaştırılır?
Burada, diyelim ki, kod büyük bir bloğa yazılır ve kod işlevsel parçalara bölünür - her iki durumda da değişiklik yapmak tamamen aynıdır. Tek fark, ilk durumda - değişiklikten etkilenecek tüm bağlantıları hatırlamanız ve bunları dikkate almanız gerektiğidir. Ve ikinci durumda - bloğun yalnızca çalışması gereken bağlantılara erişimi olduğundan - değişiklik mevcut tüm bağlantıları etkileyecektir. Hiçbir şeyi hatırlamanıza gerek yok - değiştirilmekte olan blok için mevcut olan her şeyi sürekli olarak düzeltiyoruz.
İşte farkı nasıl değerlendirebiliriz? Tam olarak aynı miktarda bir şey üzerinde çalışın!
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz