OOP vs prosedürel programlama - sayfa 14
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
OOP olmadan yapmamak daha iyi olan aynı türdeki bu görevlere özel bir örnek verebilir misiniz?
OOP olmadan çözebilirsin ama OOP ile daha hızlı demiştim sana..
Örneğin, bir şablon 0 ila 100 mum kalıbı, 0 ila 30 farklı gösterge ve her birinde 1 ila 5 farklı sinyal içerebilir. - kalıplar ve 2 gösterge, her biri 1 sinyal.. Ve ikinci örnek 12 diğer desen ve 8 diğer gösterge içerir. Daha sonra, her iki örneğin birbirinden 4 çubuktan daha fazla açılmaması için bir sinyal vermesi koşulunu belirledik..
Tüm bu tortular, sinyal kalıpları ve diğer her şey sınıfta açıklanırsa 5 saniye içinde yapılır. örnek sayısını ve her birinin özelliklerini artırmak için numaralandırma ile .. iyi, vb.))
Bu ana argüman değil.
Prosedürel programlamadapolimorfizmin bir benzeri yoktur.
Gariptir ki, tüm uygulamalarımda, programlamada tam bir cahil olarak başlayıp bir dereceye kadar böyle devam ederek, polimorfizm kullanma ihtiyacına gelmedim ... Bu muhtemelen kader.
Allah bilir neden...))
OOP olmadan çözebilirsin ama OOP ile daha hızlı demiştim sana..
Örneğin, bir şablon 0 ila 100 mum kalıbı, 0 ila 30 farklı gösterge ve her birinde 1 ila 5 farklı sinyal içerebilir. - kalıplar ve 2 gösterge, her biri 1 sinyal.. Ve ikinci örnek 12 diğer desen ve 8 diğer gösterge içerir. Daha sonra, her iki örneğin birbirinden 4 çubuktan daha fazla açılmaması için bir sinyal vermesi koşulunu belirledik..
Tüm bu tortular, sinyal kalıpları ve diğer her şey sınıfta açıklanırsa 5 saniye içinde yapılır. örnek sayısını ve her birinin özelliklerini artırmak için numaralandırma ile .. iyi, vb.))
Bütün bu OOP evrensel ölçekte yetiştirildi.
Sonuçta, böyle bir şeyi küresel ölçekte ilerletmek için BÖYLE bir yeteneğe sahip olmanız gerekir.
Ve hiçbir şey özür dileyenleri durduramaz.
Yerel özür dileyenleri alırsanız. Burunlarının altında bir µl dil kılavuzu var. Bölümlere bakalım. Verilere yalnızca üç bölüm ayrılmıştır ve geri kalanı EYLEM'i tanımlar: program, dizilerle işlemler, veri dönüşümleri ....
Belki de "gelişmiş fikirlere" karşılık gelmeyen mikrolitre dilidir?
Çok daha büyük bir yazılım sistemi alın: R.
Her biri işlev içeren 10.000'den fazla paket içerir - bunlar nesneler değil eylemlerdir.
Benim düşünceme göre, yerel sızıntının tüm bu OOP savunucuları ve küresel GENEL OLARAK programlamada hiçbir şey anlamıyor, yani: herhangi bir verinin değeri (anlambilimi) bir işlevdir, bu verileri işleyen bir eylemdir . int yazdı. Bu karakterlerin anlamı, bu değişkenle EYLEM gerçekleştirebilen işlemcinin komut seti tarafından belirlenir.
Ardından, sınıflara geçelim.
R alırsanız, hangi sınıflar dilin bir parçasıdır.
Fonksiyonun girdisi bir sınıfın nesnesidir - çıktı genellikle başka bir sınıfın nesnesidir. Girdi-çıktı alanlarının anlamı, yalnızca tüm bunları işleyen fonksiyon tarafından belirlenir. Ve işlev belirli bir sınıfı algılamıyorsa, bu işlev için böyle bir sınıf mantıklı değildir. Bu nedenle her paketin belgeleri µl ile tamamen aynıdır: eylemler, işlevler listelenir. Ve bir paketteki işlevler veya başka bir paketteki işlevlerle olan ilişkiler, belirli bir işlevin çalıştığı sınıfın adıyla belirlenir.
Tekrar. R'de nesneler rastgele karmaşıklıkta olabilir ve aslında çok karmaşık olabilir. Ancak belirli bir sınıftaki bir nesnenin her alanının değeri, tamamen bu nesneyi oluşturan işlev tarafından belirlenir.
Bu özellikle derleyiciler yazanlar için açıktır (ve ben yaptım). Belirli bir kod dizisi yazılır. Bu kod ne yapar? Bu kodun anlamı nedir? Herhangi bir programlama dilinin kaynak dilindeki metnin anlamı, derleyicinin üreteceği ve sonunda işlemci tarafından kabul edilecek yürütülebilir kod tarafından belirlenecektir. Bir dilden derleyici yazılı satırların değerini bulur ve diğeri onu bulamaz, yani. bu öteki için yazılı satırların bir anlamı yoktur.
Dolayısıyla: bir nesnenin anlamı her zaman bir fonksiyondur, girdi verilerini eylem kılavuzu olarak algılayabilen ve çıktıda belirli bir alan listesi oluşturabilen bir eylemdir, değer yalnızca bu fonksiyon tarafından belirlenir.
Yukarıda Konov, EYLEMLER'den gitmek gerektiğini açıklamaya çalıştı. Eylemlerle uğraşmak gerekir ve bu eylemleri bağlayan nesneler daha sonra eylemler belirlenirken. Ancak, kodun netliği ve etkinliği, yalnızca tüm EYLEMLER hiyerarşisini ve bunların etkileşimini düzenlemenin ne kadar iyi mümkün olduğundan kaynaklanmaktadır.
OOP savunucuları diyor ki: hadi nesneler yaratalım. Ve bu alanlarla eylemler tanımlanmamışsa, nesnelerin alanlarının değeri nedir.
Kalıplar içeren bir şablon nasıl uygulanır? Bir işlev mi, dizi mi yoksa başka bir şey mi? Kalıplar nasıl kaydedilir?
evet genelde anlatılır konu o değil..
Başka bir örnek .. bir sınıf, kitapların bulunduğu bir kütüphane gibidir ve bir örnek bir arabadır .. Kitaplıktan seçmek için kitapları sepete koyabilirsiniz .. Optimizer'da, örneğin, karmaşık bir görev ayarlayabilirsiniz, böylece ve içindeki her kitap seti otomatik olarak seçilecektir. OOP ile zaten daha iyi
Şu anda kabul ettiğim geliştirme aşamasında OOP lehine tek argüman bu.
Boşuna kabul ediyorsun.
Çalıştığım son ekipte yaklaşık 300 kişi vardı. Tüm yazılım projesi için toplam işçilik maliyetleri yaklaşık 1500 adam-yıldır. BÖYLE bir ekibin koordineli çalışmasının organizasyonu hiçbir FKÖ'ye yardımcı olmayacaktır. Bunun için, tüm sorunun aşamalara bölünmesi ve her adımda her şeyin dikkatli bir şekilde düzenlenmesi ile ilgili başka yaklaşımlar vardı. Bunu anlatan GOST'lar vardı. Programlamada bu, ESPD'dir (birleşik program dokümantasyonu sistemi). Emek yoğunluğu açısından, kodlamanın kendisi işçilik maliyetlerinin yaklaşık %20'sini aldı.
FKÖ savunucularını dinlemeyin. Doğru yoldasın. İki değişkeni tek bir yapıda birleştirmemiş olsanız bile - böyle bir birlikten kazanç görünmez
Yüzeyde yatan başka bir basit örnek.. Metaeditördeki danışmanların jeneratörü... Programlamayı bile bilmeyen herkes, çok sayıda gösterge ve koşuldan oluşan bir danışmanı 10 saniyede perçinleyebilir )) ) Ve tüm bunlar OOP ))
Jeneratörden bahsetmeyelim yoksa 2 ay daha küfür etmemeye karar verdim)))
Değerli MQ geliştiricileri, size büyük saygı duyuyorum. Ciddiyim.
Ve bu kurucuları yaratmanın nedenlerini anlıyorum. Ayrıca tüm bu inşaatçıların neden vakumlu osuruklar olduğunu da anlıyorum.
Evet, bu MQL5 öğrenmek için bir tür örnek olarak kabul edilebilir, ancak hiçbir şekilde gerçek bir robot için bir başlangıç olarak değil.
Boşuna kabul ediyorsun.
Çalıştığım son ekipte yaklaşık 300 kişi vardı. Tüm yazılım projesi için toplam işçilik maliyetleri yaklaşık 1500 adam-yıldır. BÖYLE bir ekibin iyi koordine edilmiş çalışmasının organizasyonu hiçbir FKÖ'ye yardımcı olmayacaktır. Bunun için, tüm sorunun aşamalara bölünmesi ve her adımda her şeyin dikkatli bir şekilde düzenlenmesi ile ilgili başka yaklaşımlar vardı. Bunu anlatan GOST'lar vardı. Programlamada bu, ESPD'dir (birleşik program dokümantasyonu sistemi). Emek yoğunluğu açısından, kodlamanın kendisi işçilik maliyetlerinin yaklaşık %20'sini aldı.
FKÖ savunucularını dinlemeyin. Doğru yoldasın. İki değişkeni tek bir yapıda birleştirmemiş olsanız bile - böyle bir birlikten kazanç görünmez
San-Sanych, iddiaya göre bir progger tarafından yakın zamanda benimle iletişime geçildi, hatta Market'te bir şeyler satmayı başardı.
Birkaç programı yapıştırmaya çalıştığımı söylüyor, ancak bir derleme hatası var, tabiri caizse kendi yapıştırmasını bana gönderdi. Ödemeye söz verdi.
Baktım hastalandım 59 derleme hatası
n,c,m türünde bir grup global değişken
Her şey birbiriyle çelişiyor.
Ve insanlar bir şeyi değiştirmeleri gerektiğinden eminler ve onu Market'e atabilirsiniz.
...
Benim düşünceme göre, yerel sızıntının tüm bu OOP savunucuları ve küresel GENEL OLARAK programlamada hiçbir şey anlamıyor, yani: herhangi bir verinin değeri (anlambilimi) bir işlevdir, bu verileri işleyen bir eylemdir . int yazdı. Bu karakterlerin anlamı, bu değişkenle EYLEM gerçekleştirebilen işlemcinin komut seti tarafından belirlenir.
...
hafıza için
Boşuna kabul ediyorsun.
Çalıştığım son ekipte yaklaşık 300 kişi vardı. Tüm yazılım projesi için toplam işçilik maliyetleri yaklaşık 1500 adam-yıldır. BÖYLE bir ekibin iyi koordine edilmiş çalışmasının organizasyonu hiçbir FKÖ'ye yardımcı olmayacaktır. Bunun için, tüm sorunun aşamalara bölünmesi ve her adımda her şeyin dikkatli bir şekilde düzenlenmesi ile ilgili başka yaklaşımlar vardı. Bunu anlatan GOST'lar vardı. Programlamada bu, ESPD'dir (birleşik program dokümantasyonu sistemi). Emek yoğunluğu açısından, kodlamanın kendisi işçilik maliyetlerinin yaklaşık %20'sini aldı.
FKÖ savunucularını dinlemeyin. Doğru yoldasın. İki değişkeni tek bir yapıda birleştirmemiş olsanız bile - böyle bir birlikten kazanç görünmez
Şimdi bu tür programlar bir kişi tarafından üç günde yazılıyor.