Yapı kayaları. Programları yapılandırmayı, olasılıkları, hataları, çözümleri vb. keşfetmeyi öğreniyoruz. - sayfa 3
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
Hadi ama, hiç modelim yoktu, sonra bir prosedürle başladım, sonra objektif bir modele geçtim.
Genel olarak, MQ'dan varsayılan olarak bir olay modelimiz vardır. Başlangıçta bize her şeyin gerçekleştiği olaylar verilir.
mq5'ten mi bahsediyorsun?
peki ya aynısı
" Hatalar, hatalar, sorular " başlığından:
Tasarımın başlangıcı için çok tipik bir sorun: gelecekte (programın) geliştirilebilmesi ve aynı zamanda halihazırda yapılmış olanı en az düzeyde yeniden yapabilmesi için bir programdaki olayların işlenmesinin nasıl organize edileceği (yapılandırılacağı).
Seçenekleri tartışmak ister misiniz?
Genel olarak, bu daha küresel bir konudur ve yetkin bir etkinlik modeli düzenlemekle sınırlı değildir. Çok şey dilin kendisine bağlıdır. Ne yazık ki, MQL5 dil araçları geçen yüzyılın 80'leri seviyesinde. Modern programlama standartları, OOP programlamanın orijinal ilkelerinden çok uzaklaşmıştır. Artık ayrıştırma kalıtım yerine tercih ediliyor, polimorfizm arayüz düzeyinde yatay hiyerarşik olmayan bağlantılar tarafından sağlanıyor ve kodun yeniden kullanımı zengin standart kitaplık koleksiyonları, ayrıştırma tasarımı ve üçüncü taraf derlemelerin projeye şeffaf olarak dahil edilmesi ile sağlanıyor.
Örneğin herhangi bir edebiyat var mı?
Bu konu hakkında özel olarak:
Hangi dili rol model olarak görüyorsunuz (modernite ve kullanım kolaylığı açısından)?
Java/C#
Ve bu benim önyargım bile değil (nerede onsuz olsa da), ancak bu dillerin programlama teknolojilerinin uzun bir evriminin son ürünü olduğu gerçeği. Zamanımızda yaratıldılar ve seleflerinin deneyimlerine dayanarak.
Büyük bir proje yazmadan önce, net, iyi kurulmuş bir proje destek altyapısı oluşturmak güzel olurdu:
Örneğin herhangi bir edebiyat var mı?
Elbette var.
// Edebiyat hakkında: edebi kaynakları paylaşalım. Ancak, canlı iletişimin bazen (büyüklük sırasına göre) öğrenme için kitaplardan (hatta iyi olanlardan) çok daha etkili olduğunu unutmayalım.
--
Bir zamanlar (90'ların başında), kitap çok yardımcı oldu:
B. Liskov, J. Gatag. "Program Geliştirmede Soyutlamaları ve Belirtimleri Kullanma."
Ondan nesne yönelimli programlamanın ana özelliğini iyi öğrendim. Bu, programı uygun "küplere" bölmek için ek bir fırsattan oluşmaz - bunlar yalnızca ilgili ek kolaylıklardır. Ana özellik veri soyutlamasıdır .
sen nesne yönelimli düşünüyorsun, ben işlevselim)
1. Prosedürel (algoritmik) soyutlama, işlevsel programlamanın bir özelliğidir. Soyutlayan bir varlık bir prosedürdür (fonksiyon). Bazı eylem veya hesaplamaları gerçekleştirme isteğini uygulamasından ayırmanıza izin verir. Fonksiyon kodu ayrı bir blokta (prosedür, fonksiyon) tahsis edilir, bu koda erişim, resmi / gerçek parametrelerin ayrılması yoluyla gerçekleşir (bu, prosedürel yaklaşımın özü ve ana özelliğidir). Program, hesaplama veya eylemin yöntemini (algoritmasını) değiştirmek için gerekirse (örneğin, bir dosyaya yazma) değişmeden kalma fırsatı elde eder.
Ancak programın herhangi bir temel veri yapısını (örneğin küresel diziler) değiştirmesi gerekiyorsa, bu, bu verilerle çalışan birçok prosedürü yeniden yazma ihtiyacını gerektirecektir. -- Bu, prosedürel programlama stilinin temel sınırlamasıdır.
2. Veri soyutlama - temel veri yapılarının (üzerlerindeki temel işlemlerle birlikte) temel kurala uygun olarak ayrı varlıklar ("sınıflar") halinde kapsüllenmesi: onlara asla doğrudan erişmeyin (kapsüllenmiş veriler), yalnızca ve yalnızca işlevler aracılığıyla erişin Bu amaç için özel olarak oluşturulmuş aynı sınıfın ("arayüz"). Böylece veri depolama biçiminin bu verilerle çalışma yollarından soyutlanması sağlanır. Ve şimdiye kadar bilinmeyen (prosedürel programlamada) bir fırsat var - önceden veri sunma yolları hakkında endişelenmeden bir program geliştirmek. Verilere standart, değişmez bir arayüz üzerinden erişildiğinden , proje geliştirmenin herhangi bir aşamasında verilerin sunulma şeklini iyileştirmek mümkündür, ancak böyle bir değişiklik projenin diğer bölümlerini değiştirme ihtiyacını gerektirmez. Prosedürel programlamada bu mümkün değildi - ana verilerin yapısı, nasıl işlendiklerini katı bir şekilde belirledi.
programı yazmadan önce bile bana kağıt üzerinde eskiz yapmayı öğrettiler, basitleştirilmiş bir algoritmik dil ama buna hiç alışamadım.
Artık hiçbir normal programcı akış şeması çizmiyor. Bütün bunlar, okul çocuklarına öğretmek için tasarlanmış teorik saçmalıktır, ancak gerçek projelerde çalışmak için değil.
Not Kağıda çiziyorum, benim için daha uygun, bazen net bir yapı ortaya çıkarken 50 sayfaya kadar çıkıyor. Özel editörlerde tabi ki yapabilirsiniz ama her biri benim için sakıncalı (sınırlı) oluyor, bir fantezi uçuşunu gerçekleştirmek mümkün değil kısacası işi yavaşlatıyorlar.
Ve projenin ortasında veya sonuna daha yakın bir zamanda, müşteri aniden değişirse, net yapınıza ne olacak:
Bu, projenizin değişikliklere ne kadar hazır olduğunu ve bunlara karşı ne kadar dirençli olduğunu gösteren iyi bir testtir. Pratikte, kişi her zaman orijinal gereksinimlerdeki değişikliklerle uğraşmak zorundadır. Bu nedenle, genellikle "Her şeyi öngör" paradigmasından "Sorun - çözüm" paradigmasına geçmek daha iyidir.