OOP'a ilginç bir bakış - sayfa 5
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
soru benim örneğim içinse, en azından uygulamayı gizlersiniz (kendinizden bile gizlersiniz) - yani. sadece hesaplamaların mantığını yazın, kullanışlıdır, okunabilirdir, mantıksal hatalardan kaçınmanızı sağlar
Not: Ticaretle ilgili olarak, sipariş verme mantığının A + B - C olarak yazıldığı, A, B ve C'nin önceden tanımlanmış parametrelere sahip siparişler olduğu sipariş ızgaraları ile deneyler yazdım ve hala yapıyorum. genetik algoritmalar için kullanın - ilginç bir konu
Sarmalayıcılar iyi ve mantıklı bir çözümdür. Uygun olduğunda. Ve bence sarmalayıcılar, prosedürel bir dilde bir yeniliktir. Yenilik ve kullanışlılık anlamındadır.
ticaretle ilgili olarak - sipariş verme mantığının A + B - C olarak yazıldığı, A, B ve C'nin önceden tanımlanmış parametrelere sahip siparişler olduğu sipariş ızgaraları ile deneyler yazdım ve hala yapıyorum, kullanımı çok uygun genetik algoritmalar - ilginç konu
Önceden tanımlanmış parametrelerle A, B ve C - genetik algoritmalar için fenotip nasıl?
kapsülleme isim özgürlüğü verir. Ve eğer bu sorun isim mantığı ile çözülürse. Bu, elbette, maliyetlidir. sonra Python fonksiyonlar üzerine yazılabilir. ama bu bir pazar çözümü olmayacak. AMA MÜMKÜN.
python'da, herhangi bir f-i, bir değişken gibi bir nesnedir)
Bu arada, sürekli OOP örneği python'dur. Orada, daha doğrusu, kimse OOP'den başka bir şey olduğunu bilmiyor
kapanışlar var ve hiç kusura bakmadan yazabilirsin, en azından eskilerde, kim neyi severse
python'da, herhangi bir f-i, bir değişken gibi bir nesnedir)
Bağlantılar her şeyi çözebilir. İsimler örtüşmediği sürece. İşlev elbette bir nesnedir, ancak sonucu içeriden aynıdır ve yalnızca genel ve genel sürümde içeriye bakabilirsiniz. piton mantığını severim
kapanışlar var ve hiç kusura bakmadan yazabilirsin, en azından eskilerde, kim neyi severse
peki, yapabilirsin, ama yine de minimum yapı taşı bir nesnedir
uzun zamandır görülmeyen şey.
Gerçekten gerçekten başka lakaplar altına mı gitti?
Hayır, bu Peter değil, tamamen farklı bir yazı stili.
sert kurumsal OOP, Java'dır. Bölgemizde Du * *opy temsil edilmektedir (karşılaşmamak için atlama). Nesne güzelliklerini arzulayın - konu bilindiği için API'lerini ayık bir şekilde anlamaya ve hatırlamaya çalışın :-)
ve hepsi saçmalık..
programlama becerisini yükseltmek için, beyin büken bir iplikte ustalaşmaya değer. Örneğin, Rebol/Red ( https://www.red-lang.org/ ) var - harika bir şey, anlaşılmaz ama harika.
ya da sadece klasikler - Smalltalk ( https://pharo.org/ ) . Birileri üretimde bile kullanıyor
Ve tüm bunlar "A + B'yi farklı tarzlarda yazalım", bebek konuşması, dürüstçe bir kelime.
Ve sonra kimin daha havalı, OOP veya FP ile ilgili tüm sorular kendiliğinden kaybolacak.
peki, yapabilirsin, ama yine de minimum yapı taşı bir nesnedir
itiraz, bir atılımdı.
OOP'nin daha uygun olduğu yerlerde, hafızadan ve zamandan tasarruf etmem ve kendim için kodlamam gereken OOP kullanıyorum - prosedürde kalıyorum. Az önce bir makale buldum, nerede / neyin daha iyi olduğu hakkında fikir almak istedim). Sonuç olarak - Adresimde programlama hakkında değil, farklı şeyler hakkında yeterince şey duydum) Her şey her zamanki gibi.
Yani kimse size yeni bir şey söylemeyecek. Hangisinde rahatsan onu kullan.
Hataları en aza indirmek için kanıta dayalı programlama (özellikle resmi doğrulama) adı verilen bir alan vardır.
Kodun kalitesini iyileştirmek için kısmi önlemler olarak, genel olarak kabul edilen kodlama stillerinden birini (örneğin, google kod stili), iddiaların kullanımını (assert), kısıtlamaları (const, override, erişim belirteçleri ) izlemeyi önerebiliriz. yürütmeyi etkilemez, ancak yanlış kullanım durumunda derleme hatalarına neden olur, genel olarak tasarım yaklaşımlarına aşina olun
Gerçek şu ki, genel olarak kritik programlama alanları dışında, bir üretim sürümünü edinme hızı, kodun kalitesinden daha önemlidir, bu kötü, ancak bu doğru.