OOP'a ilginç bir bakış - sayfa 2
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
Konuya bir tür yıkıcı tepki ve yıkıcı bir tartışma. Söyleyin bana, bir Prosedürel Programcı, OOP'de spaggetizasyondan nasıl kaçınılır, nasıl ayrıştırılır ve diğer insanların spagget'larını kullanmanın mantıklı olup olmadığını?
Sonuçta, ne olur, OOP çoğunlukla okunabilirlik ve komut programlama içindir, yani. büyük projeler için. Bakiye/hesap fonlarından maksimum riskin kontrolü ile eklendiği çizelgeye bir sembol ticareti yapan bir Uzman Danışman hiçbir şekilde büyük bir proje olarak adlandırılamaz - bu, prosedürel programlamanın yeterli ve bellek açısından daha karlı olduğu anlamına gelir. /hız.
Sorular:
- kişisel deneyimden OOP'nin eksileri / artıları (zorunlu olarak)
- kişisel deneyimden FP'nin eksileri / artıları (bildirimsel olarak).
Ve beklentiler hakkındaki görüş, özellikle paralel hesaplama yönünde, elbette ilginç. Kuantum konusuna değinmek için bir neden göremiyorum.
Neyin geldiğine bakmalısın, spagetization hakkında hiç anlamadım.
Herhangi bir kodun iyi bir özelliği, işlevlerin mümkün olduğunca kısa olmasıdır. Onlardan daha fazla olsun
Örneğin, OOP'nin özelliklerinin yarısı, kullanım kolaylığı için ayırmak istediğimiz şeylerdir - örneğin, bir dizi işlevi bir gruba ayırın ve ad alanlarında yaşamaları için onlara kendi değişkenlerini verin).
"Sınıf" tipi depolama ile çalıştığımız için, tüm değişkenleri önceden açıkça tanımlayarak onlara belirli bir tip verebiliriz....
harici API'ler oluşturmak için kullanışlıdır. Çalışırken, çok sık kullanılan bir sınıf referansı (8 bayt) ile çalışabilirsiniz.
Örnek: Herhangi bir bağlantılı düğüm listesi vb.
// Buraya sadece gördüğüm özellikleri yazdım, korunan yöntemlerin olasılığı ve özellikleri hakkında yazmanın bir anlamı olmadığı açık ve benzeri .... tabiri caizse sadece şeker
FP özellikleri bir yerde yapmak istediğimiz şeydir, örneğin bir şeyden sonra, fonksiyonda anında yeni bir fonksiyon yazmak istiyoruz - mevcut olanı bölerek, mevcut değişkenlerin bir kısmını fonksiyonumuzdan kullanacak. Yürütülmesini başka bir işleve aktarmak için, hesaplaması henüz yapılmamış olan bekleyen bir işlevi ilettiğimiz ortaya çıktı - tam bir kod parçası şeklinde ....
Aslında oldukça uygun.
Aynı zamanda, kodun tam olarak dağıtılması özelliği kalır. aslında, hangi işlevi aldığımızı açıkça biliyoruz - bu, hesaplama yaparken OOP'den daha hızlı olması muhtemeldir. Bir fonksiyondan diğerine oldukça zor hesaplama transferleri düzenleyebilirsiniz - fonksiyon ayrıca önceki fonksiyonun çağrılan değişkenlerinin ortamlarını tamamen hatırlar - bu çok güzel (aslında bu sadece bildirilen değişkenleri dış kapsamdan kurtarmak olsa da) . FP ayrıca işlevin adresini de ayarlayabilir ve onu bir sınıf gibi bir dizide saklayın - özellikle kullanışlı olmasa da.
Ertelenmiş işlemler, her türlü asenkron fonksiyonlar, paralel hesaplamalar için kod yazma kolaylığı
Korkularımı, alıntı yapılan makaleye ve determinizm kavramına dayanarak açıklayacağım. Beni "spaggetizasyon" (kodun karmaşıklığı ve hesaplama hatalarını bulma görevi) korkutan nedir? Dolayısıyla makalenin odaklandığı şey, değişkenlerdeki "çöp" değerler veya fonksiyonlardan deterministik olmayan dönüşlerdir.
Değişken (gelişen) yapılarım ile sinir ağlarını bir araya getiriyorum/eğitiyorum. Ve onlar için, değerlerde hiçbir yerde "çöp" çıkması çok kritik.
Makalede olduğu gibi - fren pedalına basıyorsunuz ve pedal sizi umursamıyor. Bu kullanımda. Ve başlangıçta montaj (otomatik mimari seçimi) ve sinir ağının eğitimi sırasında "çöp" varsa, o zaman nasıl bir araya gelecek / öğrenecek?
OOP'de "çöp" (determinizm olmayan) mümkün olduğunca nasıl önlenir?
Korkularımı, alıntı yapılan makaleye ve determinizm kavramına dayanarak açıklayacağım. Beni "spaggetizasyon" (kodun karmaşıklığı ve hesaplama hatalarını bulma görevi) korkutan nedir? Dolayısıyla makalenin odaklandığı şey, değişkenlerdeki "çöp" değerler veya fonksiyonlardan deterministik olmayan dönüşlerdir.
Değişken (gelişen) yapılarım ile sinir ağlarını bir araya getiriyorum/eğitiyorum. Ve onlar için, değerlerde hiçbir yerde "çöp" çıkması çok kritik.
Makalede olduğu gibi - fren pedalına basıyorsunuz ve pedal sizi umursamıyor. Bu kullanımda. Ve başlangıçta montaj (otomatik mimari seçimi) ve sinir ağının eğitimi sırasında "çöp" varsa, o zaman nasıl bir araya gelecek / öğrenecek?
OOP'de "çöp" (determinizm olmayan) mümkün olduğunca nasıl önlenir?
Orada, makalede, genel olarak, bir şekilde garip, kişi bariz bir şekilde const değişkeninin türünü belirtmeyi unutmuş, sanki orada js varmış gibi, o zaman en azından salt okunur. Daha sonra, boyutunu değiştirmemesi gereken (sabit olması), bir nedenden dolayı sabit olmayan bir nesne ..... olduğunda bir hata olduğunu söylediklerini yazar ve buna dayanarak, yüksek bir hata olasılığının olduğu sonucuna varır. OOP'de)))
Genel olarak, OOP, değişkenlerin kapsamını kontrol etmenizi sağlar. FP, bir fonksiyondan değişkenlerin geçmesi olarak düşünülür, yani. tür varsayılan olarak bizim tarafımızdan tanımlanmış olmalıdır. muhtemelen azdırlar. Ve eğer bir şey varsa, bu işlevi hareket halindeyken genişletebilirsiniz.
Onlar. OOP daha fazla başlangıç kontrolüne sahiptir
İşte bu, her zaman şüphelenmişimdir
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Bu tür "makaleleri", boş konuşmaları, genel ifadeleri, en azından anlamı kimin yazdığı belli değil.
" Kod bir bütün olarak kafa karıştırıcı ve dağınıktı - buna argoda "spagetti" denir - Toyota'daki kötü programcılar nedeniyle, OOP'deki kodun kafa karıştırıcı olduğunu düşüneceğiz.
" Yerleşik OOP özellikleri yalnızca kafa karışıklığı katar. " - peki, mantık, özellikleri kullanma yeteneği koda karışıklık katar, OOP özelliklerinin (C#) sayısındaki sürekli artışla artık mümkün olmayacaktır. basit kod yaz. Evet.
" Nesne yönelimli dillerin çoğunda, veriler başvuru yoluyla iletilir, bu da programın farklı bölümlerinin aynı veri yapısıyla ilgilenebileceği ve onu değiştirebileceği anlamına gelir. Bu, programı büyük bir küresel durum bloğuna dönüştürür ve orijinal fikirle çelişir. of OOP " - Ve özel , korumalı mı ?
"... Bu alıntıyı beğenmiyorsanız, bunun nedeni genel olarak determinizmin iyi olmamasıdır. " - peki, evet, öngörülemeyen işlevler GetMicrosecondCount, MathRand, CoptBuffer, tüm ağ işlevleri ve diğerleri atılmalıdır, çünkü sonuç dış durumlara bağlıdır. Korku.
Tamam, yeter, her şey açık.
İşte bu, her zaman şüphelenmişimdir
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Orada, argümanların çoğu parmaklardan emilir. OOP'nin tutarsızlığını "kanıtlayan" bazı deneyler genellikle yanlıştır. Normal OOP dillerinde, içine a += b gibi saçmalıklar yazsanız bile, sum(int a, int b) her zaman saf olacaktır. Yine, bir nesne bir yöntem içinde yığın olarak ayrılmışsa, o zaman her zaman korunur, çünkü yalnızca onu çağıran yöntemin kendisine bir referansı vardır. Nabzını kaybedene kadar değiştir. Referans ve değer türleri vardır. Hiç kimse OOP dillerinin yan etkisi olmayan saf işlevler yazmasını engellemez. Örneğin standart matematiksel fonksiyonlar. Evet, bazen paylaşılan kaynaklar olmadan yapamazsınız, ancak bunun için uygun iş parçacığı güvenli koleksiyonlar ve çok daha fazlası vardır. Sonunda, herhangi bir saf FP kaçınılmaz olarak IO, BD, ağ istekleri ve değişkenlik arka plan programlarının kırılacağı her şeyle etkileşime girecek.
Garip yazı....
Nicelik, niteliğe dönüşme özelliğine sahiptir.
Çok sayıda telsiz olduğunda, elektromanyetik uyumsuzluk meydana gelebilir ve çalışmayı durdururlar.
Kodun spagetti özellikleri genellikle miktardan alınır ve farklı durumlarda çok sayıda kullanım ile sarılmış tüm özellikleri dikkate almaz.
Fonksiyonlarda, geri bildirimin varlığı aynı sonuca yol açacaktır. Histerezis hala bir şaka)
Görevleri ve doğru formülasyonlarını anlamak ...))))
// Buraya sadece gördüğüm özellikleri yazdım, korunan yöntemlerin olasılığı ve özellikleri hakkında yazmanın bir anlamı olmadığı açık ve benzeri .... tabiri caizse sadece şeker
FP özellikleri, bir yerde yapmak istediğimiz şeydir, örneğin bir şeyden sonra, fonksiyonda anında yeni bir fonksiyon yazmak istiyoruz - mevcut olanı bölerek, mevcut değişkenlerin bir kısmını fonksiyonumuzdan kullanacak. Yürütülmesini başka bir işleve aktarmak için, hesaplaması henüz yapılmamış olan bekleyen bir işlevi ilettiğimiz ortaya çıktı - tam bir kod parçası şeklinde ....
Aslında oldukça uygun.
Peki, aynı şeyi OOP'de yapmanızı kim engelliyor? Evet, tamamen prosedürel bir dilde bile mi? Bir işlev işaretçisini başka bir işleve iletir ve ertelenmiş yürütme elde edersiniz.
Async genellikle temiz bir tasarım kalıbıdır. Saf C'de asenkron kod da yazabilirsiniz. Bir görevi parça parça yerine getiren bir Durum makinesi yapmak kolaydır. Bu arada bunu uzun zamandır düşünülen MQL'deki göstergelerle yaptım. Grafiği yavaşlatmamak ve tamamlanma yüzdesini değiştiren güzel bir durum çubuğu görüntülemek için.
Peki, aynı şeyi OOP'de yapmanızı kim engelliyor? Evet, tamamen prosedürel bir dilde bile mi? Bir işlev işaretçisini başka bir işleve iletir ve ertelenmiş yürütme elde edersiniz.
Async genellikle temiz bir tasarım kalıbıdır. Saf C'de asenkron kod da yazabilirsiniz. Bir görevi parça parça yerine getiren bir Durum makinesi yapmak kolaydır. Bu arada bunu uzun zamandır düşünülen MQL'deki göstergelerle yaptım. Grafiği yavaşlatmamak ve tamamlanma yüzdesini değiştiren güzel bir durum çubuğu görüntülemek için.
) assembler'da da yapılabilir. Soru hangisinin daha kolay olduğu.
Ve beni bir yöne ya da başka bir yere koyma .... Ben bir şeyin taraftarı değilim
Garip makale. OOP, daha kötüsü için prosedür tarzından hiçbir şekilde farklı değildir, çünkü içinde, varsayılan olarak, her şey prosedürel bir tarzda yapılabilir, ancak bunun tersi, korkunç kod şişmesi olmadan imkansızdır, yani. OOP, temelde farklı bir tarz değil, bir üst yapıdır.
Makale gerçekten prosedürle ilgili değil, işlevsellikle ilgiliyse (hata bulursanız çok açık değil), o zaman neden tamamen farklı uygulama alanlarına sahip bir şeyi karşılaştırın.
Konu başlatıcı, sen kendin bir şeyler yazıyorsun ve şimdi ne hakkında konuşuyorsun? işlevsel mi, prosedürel mi?
Sonuçta, ne olur, OOP çoğunlukla okunabilirlik ve komut programlama içindir, yani. büyük projeler için.
OOP yapamam. Ama ondan ilkel şeyler kullanıyorum. Yakın zamanda, çok basit bir kod yayınladı .
Sonunda ne izlemem gerektiğini anlamadığımda FP'de yazmaya başladım.
OOP'nin ilkel öğeleriyle tamamlandı. Belki FP becerilerimi kaybettim, ancak burada OOP çok daha basit ve daha okunaklı görünüyordu.
Kod çok basit ve kısadır ( açıklama ). FP'ye yazarsanız, karşılaştırmak ilginç olacaktır.