OOP vs prosedürel programlama - sayfa 38
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
OnInit()'im hemen hemen aynı görünüyor - bir düzine satır...
Ne olmuş?
sersemlemiş!
Merak ediyordum: Modern programlamada lanet olası bir yumurtanın seviyesi sorununu karıştırmak için başka bir olasılık var mı?
Ve bunun BÜTÜN program olduğu gerçeği .. başka bir şey yok :-)
Tabii ki değil.
Kül + R'deki diğer her şey (bu sayılmaz)
Hata ayıklama, hata ayıklama mantığıdır: iki denetleyicinin kesişimi vardır, ancak sinyal yoktur. Terminalden değişkenlerin değerlerini anlamada sorunlar var. Buradaki ana şey, hesap türünü değiştirmemek ve komisyoncuyu değiştirmemek tavsiye edilir.
Yukarıda burada yazılan tüm bu tutkular benim için bilinmiyor.
Tabii ki değil.
Kül + R'deki diğer her şey (bu sayılmaz)
Hata ayıklama, hata ayıklama mantığıdır: iki denetleyicinin kesişimi vardır, ancak sinyal yoktur. Terminalden değişkenlerin değerlerini anlamada sorunlar var. Buradaki ana şey, hesap türünü değiştirmemek ve komisyoncuyu değiştirmemek tavsiye edilir.
Yukarıda burada yazılan tüm bu tutkular benim için bilinmiyor.
Sadece açıkçası - en az bir gerçek hesap var mı? tutkular sadece gerçek dünyayla çarpışmalardan ve sömürü / bakım mazolleriyle dolu .. ama testçi için ne ve nasıl yazılacağı önemli değil ..
OOP, bir mekanizmanın parçalarını ayırma, sarma ve gizleme yöntemidir. Gerekli olup olmadığına geliştirici karar verir. Mekanizmanın verimliliğini artırmakla hiçbir ilgisi yoktur. Düşünmeyi yapılandırmak, evet. Doğru yapılandırılıp yapılandırılmadığı bilinmiyor. Bunun gerekli olup olmadığı kişiye bağlıdır. BENİM NACİZANE FİKRİME GÖRE.
İşlev yazarken her zaman bir sorun vardır:
1. bir fonksiyon yazdı
2. başka bir fonksiyon yazıyorsunuz ve ilkinden çok benzer ama farklı olduğunu görüyorsunuz.
Her zaman bir ikilem: Birini bırakmak mı yoksa iki bırakmak mı? Daha çok yönlü, ancak daha karmaşık bir kod elde edersiniz. Basit bir kod alırsınız, ancak bir sürü işlev. OOP ile aynı.
Az sayıda sınıfı ayırt etmek mümkünse, iyi yapılandırılmış ve anlaşılırsa,
bir sürü danışman yazarsan
herhangi bir nedenle onları sık sık değiştirirseniz
O ZAMANLAR
OOP yardımcı olur.
Durum böyle değilse, ticaretle hiçbir ilgisi olmayan bilgilerle kafanızı karıştırmanın bir anlamı yoktur, ancak R'de zaman harcamak daha iyidir.
Tüm başarı!
Sadece açıkçası - en az bir gerçek hesap var mı? tutkular sadece gerçek dünyayla çarpışmalardan ve sömürü / bakım mazolleriyle dolu .. ama testçi için ne ve nasıl yazılacağı önemli değil ..
PAMM dahil 2008'den beri.
Takipte herhangi bir sorun yok.
Ama operasyonla...
Daha sonra yayılma 20'ye çıkarılacak, sonra bazen marj, sonra boşluk, sonra ışık kapatılacak .... sonra eş dokunmatik düğmelerdeki tozu silecek ... Genel olarak, yeterli. Dolayısıyla bu şube Çin'i ziyaret etmek gibi.
İşlev yazarken her zaman bir sorun vardır:
1. bir fonksiyon yazdı
2. başka bir fonksiyon yazıyorsunuz ve ilkinden çok benzer ama farklı olduğunu görüyorsunuz.
Her zaman bir ikilem: Birini bırakmak mı yoksa iki bırakmak mı? Daha çok yönlü, ancak daha karmaşık bir kod elde edersiniz. Basit bir kod alırsınız, ancak bir sürü işlev. OOP ile aynı.
Az sayıda sınıfı ayırt etmek mümkünse, iyi yapılandırılmış ve anlaşılırsa,
bir sürü danışman yazarsan
herhangi bir nedenle onları sık sık değiştirirseniz
O ZAMANLAR
OOP yardımcı olur.
Kişisel olarak çözümlerde evrensellik için çabalıyorum. Bu , kod miktarını artırmadan benzer işlevleri tek bir bloğa "birleştirmeyi" gerektirir. Mekanizmanın verimini arttırır, aşırı yük ve ayırma gerektirmez. Sadece beynini kullan ve hepsi bu.)
Yani, her biri 20 satırlık iki fonksiyon vardı. Her ikisi de benzer eylemler gerçekleştirir veya aynı tür görevleri çözer. Amacım, onları her iki işlevin de işini yapan 20 satırdan fazla olmayan tek bir işlev haline getirmek. Blokları bu şekilde alıyorum.
not.
Eskiden inciler için bir başlık vardı.
onun içinde
Program kılavuzu dokümantasyon değildir.
Kılavuz, programın işlevselliğinin (programın yapabileceklerinin) bir açıklamasıdır. Kullanıcı için gereklidir.
Belgeleme, programın yapısının bir açıklamasıdır (programın nasıl oluşturulduğu). Programcı için gerekli.
Herhangi bir terim çatışması yoktur.
...
Durum böyle değilse, ticaretle hiçbir ilgisi olmayan bilgilerle kafanızı karıştırmanın bir anlamı yoktur, ancak R'de zaman harcamak daha iyidir.
Tüm başarı!
R'nin ticaretteki etkinliğini gösterin - zaten bunun için yeterince zaman harcadınız. Yarışmalara katılın - 1 Eylül; 2. üç ayda bir
https://www.mql5.com/ru/forum/212596
1. OOP kullanımından Uzman Danışmanlarınızın karlılığı ne kadar arttı?
2. Danışmanlarınızın OOP kullanmayı reddetmeleri arasındaki süre ne kadar azaldı?
2. Bu zor))))) bilgisayar programının MTBF... kliniği!