MQL5'te OOP hakkında sorular - sayfa 25
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
14 yaşında olmasına rağmenhttps://githut.info/ burada detaylı istatistikler var.
github ile ilgili son istatistikler https://madnight.github.io/githut/#/pull_requests/2019/2
Bu yazıda profesyonellerin görüşlerini okumanın herkes için faydalı olacağını düşünüyorum.
İyi şanlar
Bu yazıda profesyonellerin görüşlerini okumanın herkes için faydalı olacağını düşünüyorum.
makalenin tüm (kesinlikle taraflı) sonuçları basit bir soru ile dengelenir.
FP uzun süredir piyasada, bu kadar harikaysa neden hala bu kadar küçük bir yeri var?
Hiçbir şekilde OOP'nin en iyi konsept veya FP'nin berbat olduğu seçeneklerin dışında olduğunu kastetmiyorum.
makalenin tüm (kesinlikle taraflı) sonuçları basit bir soru ile dengelenir.
FP uzun süredir piyasada, bu kadar harikaysa neden hala bu kadar küçük bir yeri var?
Makalede bu sorunun cevabı var. Dikkatli okumadın.
Makalede bu sorunun cevabı var.
Kesinlikle önyargılı ve hiçbir şey hakkında.
Kodu gerçekten yazan geliştiriciler var. Kelimeden hiç programlama yapamayan yöneticiler var.
Dolayısıyla teknoloji yığını mutlaka geliştiriciler tarafından seçilmez. Ve belirli bir yığın, ekibin sorunu daha verimli bir şekilde çözmesine izin veriyorsa, bunu anlamak için teknolojiye sahip olmak ve bilmek gerekli değildir.
Hala makalenin soruyu cevapladığını düşünüyor musunuz?
Bu yazıda profesyonellerin görüşlerini okumanın herkes için faydalı olacağını düşünüyorum.
İyi şanlar
İşte her zaman nasıl. aşırı bakış açıları. Hangisinin daha iyi olduğunu tartışmak gibi - çekiç mi balyoz mu?
C# ile iyi odun yazamazsınız, ancak saf C ile ciddi bir uygulamada dallanmış mantıksal bağlantıları tanımlayabilir ve hatalarını ayıklayabilirsiniz.
Yani makale hiçbir şey hakkında değil.
İşte her zaman nasıl. aşırı bakış açıları. Hangisinin daha iyi olduğunu tartışmak gibi - çekiç mi balyoz mu?
C# ile iyi odun yazamazsınız, ancak saf C ile ciddi bir uygulamada dallanmış mantıksal bağlantıları tanımlayabilir ve hatalarını ayıklayabilirsiniz.
Yani makale hiçbir şey hakkında değil.
elbette, makalede biraz doğruluk var ... en azından kalıtım, aslında ihtiyaç duyulmayan yöntemleri ve alanları "çekecek", ama ne yazık ki, her şey için ödeme yapmanız gerekiyor - zaman kazandırır, ancak bellek kullanımını veya çözümün genel performansını artırabilir, ancak beşi o kadar üzücü değil, derleyicilerin seviyesi ve kod optimizasyonu şu anda çok iyi, bu nedenle çıktı genellikle kısa bir geliştirme süresinde soruna iyi bir çözümdür
C# hakkında, deyim yerindeyse, amaçları farklıdır, belirli bir bilgisayarda veya sınırlı bir bilgisayarda hızlı sonuç almak için tamamen "Windows dili"dir, hatta yüklenmeyen .Net güncellemeleri bile kritik bir hataya neden olabilir. erişiminiz olmayan bilgisayarlarda, ancak pahalı yakalamak için yeterli - C# ticareti için bir panel yazdım zaten kontrol ettim, sanal bir makinede , güncellemelerdeki tüm "yamalar" yüklenmemişse, o zaman proje beklenmedik bir şekilde çökebilir - GitHub'daki tüm yeni öğeler yeni .Net derlemeleri altında yayınlanır - yani. sadece başarılarınla sınırlı olacaksın
genel olarak, başka yerlerde olduğu gibi - yenilik "acı verici ve uzun ve üzücü", BT devleri tarafından belirlenen trendleri takip etmeniz gerekiyor, sonra her şey hızlı ve sorunsuz bir şekilde yazılıyor, peki, Microsoft elinden gelen her şeyi OOP tarzında yazdı, sahip olduğunuz tüm bunları kullanmak için yoksa sıfırdan yazacaksınız, tüm WinForm'unuz vb. Win-95'ten beri binlerce ton ve terabayt kod yazılmıştır)))
Yazıda elbette doğruluk payı var...
Bir miktar? ) Aslında tam olarak bu oluyor. Ancak yazar Amerika'yı keşfetmiyor, bariz şeyler gibi görünüyor (en azından benim için). Bana öyle geliyordu ki, deneyimli herhangi bir programcı, geçici bir durumun sorunları hakkında aynı farkındalığa geliyor. Bu arada, geçenlerde çok benzer bir makale gördüm, sadece daha kısa. Ancak, görünüşe göre bu, işlevselciler ve oop-shnik'ler arasında sonsuz bir holivardır)
Ama aslında, hiç kimse OOP'yi doğru kullanmakla uğraşmaz . Yazarın kendisi bile değişmez nesneleri kullanabileceğinizden bahseder. Ve açıklanan sorunların% 99'u hemen ortadan kalkıyor. Onlar. her şey, kullanılan paradigmaya değil, yalnızca kolların ve başın omuzlardaki düzlüğü sorununa dayanır.
Tabii ki, popüler OOP dillerinin nesnelerin değişebilirliğini kontrol etmek için bir araç sağlamaması süreci karmaşıklaştırıyor. Bu yüzden const/salt okunur yerine değişmez anahtar kelimeye sahip olmak gerçekten harika olurdu.
Ancak işlevsel dillerin popüler olmamasının nedenleri hakkında - burada yazara katılmıyorum. Buradaki nokta, gördüğüm kadarıyla, bu tür bir kodun daha karmaşık bir algısıdır. Sadece OOP ve FP karşıtlığı değil, zorunlu ve işlevsel yaklaşımların karşıtlığıdır. İlki, bence çoğu insan için daha yakın ve anlaşılması daha sezgisel. Sadece gıyaben işlevsel dillere aşinayım, bu yüzden nesnel olarak yargılayamıyorum, ancak lambdalarla aşırı yüklenmiş kod gördüğümde, beni bilişsel uyumsuzlukla tanıştırıyor) Çok kafa karıştırıcı ve zor. Ve muhtemelen çoğu insan da öyle düşünüyor.
Ayrıca, işlevsel diller, dış çevre ile etkileşimle ilgili bir dizi görev için tasarlanmamıştır. Aynı grafik arayüzünü alın. Öyle ya da böyle, olaylar arasındaki küresel değişen durumu kaydetmek gerektiğinde.
Bir miktar? ) Aslında tam olarak bu oluyor. Ancak yazar Amerika'yı keşfetmiyor, bariz şeyler gibi görünüyor (en azından benim için). Bana öyle geliyordu ki, deneyimli herhangi bir programcı, geçici bir durumun sorunları hakkında aynı farkındalığa geliyor. Bu arada, geçenlerde çok benzer bir makale gördüm, sadece daha kısa. Ancak, görünüşe göre bu, işlevselciler ve oop-shnik'ler arasında sonsuz bir holivardır)
Ama aslında, hiç kimse OOP'yi doğru kullanmakla uğraşmaz . Yazarın kendisi bile değişmez nesneleri kullanabileceğinizden bahseder. Ve açıklanan sorunların% 99'u hemen ortadan kalkıyor. Onlar. her şey, kullanılan paradigmaya değil, yalnızca kolların ve başın omuzlardaki düzlüğü sorununa dayanır.
Tabii ki, popüler OOP dillerinin nesnelerin değişebilirliğini kontrol etmek için bir araç sağlamaması süreci karmaşıklaştırıyor. Bu yüzden const/salt okunur yerine değişmez anahtar kelimeye sahip olmak gerçekten harika olurdu.
her neyse, yakın gelecekte hiçbir şey değişmeyecek, BT devleri bu paradigmayı destekliyor, belki de bu faydalıdır - yazılım geliştiricilerini çalışmak için daha güçlü donanım gerektirecek karmaşık uygulamalar yapmaya zorlamak ve ayrıca işletim sistemi veya derleyiciler için belgelerini göndermek için hazır kütüphaneler çoğunlukla OOP biçimindedir, bu da geliştiricileri zorlar .... ve sonsuza kadar devam eder ;)
OOP ile bu hikayenin, bir zamanlar doktorlar tarafından Latince'nin zorunlu bilgisinin gerekli olmadığı, ancak profesyonel düzeyde bir iletişim aracı olarak kullanılmasının gerekli olduğunu varsayabiliriz;)