Bu bir OOP sorunu değil, uygulaması ve hatta daha fazlası - onu uygulayanların sorunudur. Onlar da deneyimliyor
özel coşku, hatta OOP'nin yardımıyla inanılmaz derecede yazabileceğiniz gerçeğinden ecstasy
gizlenmiş kod (ve hatta onunla rekabet :). Bundan özel bir elit gibi hissediyorlar.
Hatta okudukları, okudukları, okudukları, okudukları, ama hiçbir şekilde kendi "BÜYÜK KİTABI" ile ortaya çıktılar.
üzerinde okuyabilir. İnsan dilinde buna " Tasarım Kalıpları" denir.
"Çamurlu, anlaşılmaz ve kafa karıştırıcı kod yazmanın en yüksek sanatı" olarak tercüme edilir. Eğer
OOP'yi akıllıca kullanmak için - bu çok, çok harika bir şey, inanılmaz derecede basitleştirici ve
hayatı kolaylaştırıyor.
İşte bu, her zaman şüphelenmişimdir
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23Burada, bu tür makalelerin büyük olasılıkla bu FP'ye ve her biri 20 sekme içerebilen karmaşık kancalarına aşina olmayan kişiler tarafından yazıldığını anlamanız gerekir....
Sert FP başka bir şeydir. sonra bir şekilde OOP'nin özlü ve kullanışlı olduğunu düşünmeye başlarsınız, yani işlevselliğin bir kısmını önceden beyan edebilirsiniz vb. ..... Aslında birbirine benzer bir şey. Ancak bu tür makaleler genellikle yalnızca prosedür koduna hakim olan kişiler tarafından yazılır - ve bu FP'ye yakın bile değildir, bu nedenle kancaların ne olduğunu ve ateşli kullanımını bilmiyorsak, herhangi bir FP'den söz edilemez.
ayrıca "ölen" makalesinde listelenenlerin çoğu diller "FP ve OOP'nin tam işlevselliğini destekliyor, neden eğilmeleri garip ?! ve bunlardan birkaçı BDT'de en yüksek ücretliFP için "boğulma" düşüncesi olmadan, OOP'de "spaggetizasyon" ile ilgiliydi. Benim için prosedürel paradigma, OOP'den gerçekten ve daha fazla kaynak verimlidir.
OOP kodunun kendisinin daha uzun olduğu gerçeğiyle mi ilgili? evet, bir kurucu var ve bazı durumlarda kod daha uzun, kural olarak, üzerinde .... teknik olarak, FP'yi dağıtmak makine kodu oluşturmak için daha verimli olmalı .... ama kod değil daha basit hale gelir ve yazmaktan bahsedersen normal sarmalayıcıları yapamazsın...
günümüzde çoğu zaman birbirinin karışımını bulabilirsiniz - yöntemler birbiriyle karışmaz
OOP kodunun kendisinin daha uzun olduğu gerçeğiyle mi ilgili? evet, bir kurucu var ve bazı durumlarda kod daha uzun, kural olarak, üzerinde .... teknik olarak, FP'yi dağıtmak makine kodu oluşturmak için daha verimli olmalı .... ama kod değil daha basit hale gelir ve yazmaktan bahsederseniz normal sarmalayıcıları yapamazsınız...
günümüzde çoğu zaman birinin diğeriyle bir karışımını bulabilirsiniz.
OOP ve FP olmadan, her şey daha kolay ve daha hızlı sürer (evet, "güzel şeyler", paneller vb. olmadan), ancak bazen kendi kodunuzu bile anlamak zordur)
OOP ve FP olmadan, her şey daha kolay ve daha hızlı sürer (evet, "güzel şeyler", paneller vb. olmadan), ancak bazen kendi kodunuzu bile anlamak zordur)
önce birinde veya diğerinde ve tercihen her ikisinde de ustalaşın ve ardından en çok neyi sevdiğinize karar verin. Ve şimdi olduğu gibi bir yaklaşımla, zamanla, anlamadığı her şeye (yani hemen hemen her şeye) saldıran bir Fedoseev'e dönüşür.
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.
Bana bir Prosedürel Programcıya OOP'de "spagging" den nasıl kaçınılacağını söyle
Tarif, alıntı yapılan makalede verilmiştir: Deterministik fonksiyonlar yazmaya çalışın.
, nasıl sökülür ve başkalarının "spagetti"sini kullanmak mantıklı mı?
İyi kod evet, ama spagetti hayır.
Sonuçta, ne olur, OOP çoğunlukla okunabilirlik ve komut programlama içindir, yani. büyük projeler için.
Doğru.
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.
Avustralya'ya seyahat etmek için bir uçak (PLO) kullanmak daha uygundur, komşu bir şehre seyahat için bir araba veya hatta bir bisiklet (PP) yeterlidir. Hedefe ulaşmak için daha uygun araçlar seçmeniz yeterlidir.
![MQL5 - MetaTrader 5 müşteri terminalinde yerleşik ticaret stratejileri dili](https://c.mql5.com/i/registerlandings/logo-2.png)
- Ücretsiz ticaret uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
İşte bu, her zaman şüphelenmişimdir
https://proglib.io/p/obektno-orientirovannoe-programmirovanie-samaya-bolshaya-oshibka-kompyuternyh-nauk-2021-01-23