OOP için genel gider - 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
Tabii ki, OOP'nin güzelliğini kaynaklarla ve çok fazla hata ayıklama süresiyle ödemek zorundasınız. OOP, yalnızca uygun bir metin sarmalayıcı olarak veya çalışma zamanı ortamını başlatırken minimum kullanımla anlamlıdır ... Özünde, OOP , programcıların çalışma saatlerinin maliyetini artırmak ve daha gelişmiş ekipmanların satın alınmasını teşvik etmek için tamamen Microsoft'tan bir pazarlama işiydi. Üstelik kendileri aptal değiller ve tüm yazılımı C ve assembler'da yazıyorlar.
oh ve saçmalık
MS programcılarının doğrudan makine kodlarına yazdığını herkes bilir.
her programcının masasında işlemcinin makine kodlarını içeren bir kitapçığı vardır ve delikli kartlardaki kodları hemen bulurlar.
Bill Gates kafasında bir işletim sistemi derleyebilir))
oh ve saçmalık
MS programcılarının doğrudan makine kodlarına yazdığını herkes bilir.
Palyaçoluğunuz tam olarak belli değil, assembler'daki insertlerin kodun hızını arttırmak için kullanıldığı biliniyor...
OOP'nin terminalde minimum düzeyde kullanıldığını veya hiç kullanılmadığını varsayabilirim, çünkü dotnet'te olduğu gibi büyük harici kütüphaneler olmadan bu kadar kompakt dosyalar elde etmek zordur...
Söylenenler için anlamlı argümanlar var mı?
Orada. Alexei, aslında, sadece duygusal olarak tepki verdi. Esasen itirazlar şu şekildedir.
OOP, bir tür karmaşık kodu korumanız gerektiğinde çok yararlıdır.
Tabii ki, bir MA göstergesi için tüm OOP numaralarını kullanmanın bir anlamı yok. Temel sınıflar yazıldığında - Mashka için bile - hepsi aynı olsa da, OOP yaklaşımı en azından olağan, prosedürel yaklaşımdan daha kötü değildir.
OOP'nin ana avantajı, gelişmiş nesne yapılarının desteğiyle ortaya çıkar. Kapsülleme nedeniyle, her seferinde aşırı yüklenmiş işlevlerin tüm nüanslarını anlamak gerekli değildir. Polimorfizm nedeniyle kodun yeniden kullanımı önemli ölçüde artar.
OOP'nin özü, herhangi bir nesnenin her zaman özellikleriyle ilişkilendirildiği ve dış dünyayla etkileşim için belirli kurallara sahip olduğu gerçek dünyaya daha yakındır.
"Çalışma saatlerinin maliyetini artırmak" hakkında - bu böyle değil. Tabii ki, OOP tarzında bir sistem tasarlarken, prosedür odaklı bir yaklaşımdan biraz daha fazla çalışma gereklidir. Ancak, bu ek maliyetler, yazılı kodu korumanın ve değiştirmenin rahatlığıyla dengelenmekten daha fazladır.
Şahsen, çok küçük "diz üstü yazılı" göstergelerim var - herhangi bir nesne olmadan yazıyorum. Ancak, biraz daha fazlası gerektiğinde (en azından platformlar arası) - Her zaman OOP stilini ve nesne kitaplıklarındaki mevcut gelişmeleri kullanırım.
Palyaçoluğunuz tam olarak belli değil, assembler'daki insertlerin kodun hızını arttırmak için kullanıldığı biliniyor...
OOP'nin terminalde minimum düzeyde kullanıldığını veya hiç kullanılmadığını varsayabilirim, çünkü dotnet'te olduğu gibi büyük harici kütüphaneler olmadan bu kadar kompakt dosyalar elde etmek zordur...
1. OOP - bazı karmaşık kodlar için desteğe ihtiyacınız olduğunda çok yardımcı olur.
2. Tabii ki, bir MA göstergesi için tüm OOP hilelerini kullanmanın bir anlamı yoktur. Temel sınıflar yazıldığında - Mashka için bile - hepsi aynı olsa da, OOP yaklaşımı en azından olağan, prosedürel yaklaşımdan daha kötü değildir.
3. OOP'nin ana avantajı, gelişmiş nesne yapılarının desteğiyle ortaya çıkar.
1. Ve örneğin? Yüksek sesle sloganlar iyidir, ancak tam olarak neden bahsettiği açık değildir ...
2. Bir metin sarmalayıcı olarak OOP'nin çok yardımcı olduğu söylenmişti, ancak aynı zamanda prosedürel programlamada akla getirilmediği için.
3. Bu "gelişmiş yapılar" neden üretilir? Kodun hızı için bu ölümcül olacaktır ve içindeki hataların yakalanmasının daha kolay ve zaman içinde daha hızlı olacağı bir gerçek değildir.
Modern derleyiciler, ortalama ve hatta iyi programcılardan birçok kez daha iyi optimize eder.
Belki bazı basit ve önemsiz şeyler olabilir, ancak yalnızca insanlar oturup algoritmayı manuel olarak yazdığı için, ancak standart olmayan bir şey varsa, o zaman bu bir gerçek olmaktan uzaktır, özellikle de OOP çanları ve ıslıkları varsa.
Sürücülerde, evet, montajcı kullanıyorlar, ancak hız nedeniyle değil, ekipmanla çalışmak daha kolay.,
Eh, insanlar aptal değil - neden aynı zamanda yavaş olan karmaşık ve kafa karıştırıcı bir şeye ihtiyaçları var?
1. Ve örneğin? Yüksek sesle sloganlar iyidir, ancak tam olarak neden bahsettiği açık değildir ...
2. Bir metin sarmalayıcı olarak OOP'nin çok yardımcı olduğu söylenmişti, ancak aynı zamanda prosedürel programlamada akla getirilmediği için.
3. Bu "gelişmiş yapılar" neden üretilir? Kodun hızı için bu ölümcül olacaktır ve içindeki hataların yakalanmasının daha kolay ve zaman içinde daha hızlı olacağı bir gerçek değildir.
1. Örneğin, bir dizi nesneye ihtiyacınız var. Bu hem yordamsal biçimde hem de CArrayObj ve CObject temelinde yapılabilir. Örneğin nesneleri eklerken veya çıkarırken veya bunları sıralarken davranışı değiştirmek gerektiğinde sorunlar başlayacaktır. OOP'de, gerçek işaretçi dizisi için destek ve onunla çalışma, temel nesnelerde bulunur. Dizide gerçekten bulunan alt nesnelerin değiştirilmesi hiçbir şeyi etkilemez. Prosedürel stille - dizide bulunan gerçek nesnelerin değiştirilmesi - kural olarak, en azından nesnelerin boyutundaki değişikliğin dikkate alınması gerektiğinden, daha fazla yeri etkiler. Hangi hata yapmak çok daha kolay.
Çapraz platform - ayrıca OOP tarzında organize etmek çok daha uygundur. Diyelim ki bir ticaret pozisyonunun talebi üzerine - bir arayüz alıyoruz ve bizim için hangi platformda çalıştığımız önemli değil - arayüz sanal işlevler sunuyor , bu sayede tüm siparişlerdeki tüm verileri alabilirsiniz ( MT4) veya pozisyonlar (MT5) için ayrıca, Bir uzmanın bakış açısından hiçbir fark yoktur. Uzmanın hangi platformda çalıştığını bilmesine gerek yoktur.
2. Ne de olsa, "prosedürel programlamada akla getirmek" - bu, "nesneler-prosedürler yazmak", yani OOP'de nesneleri temsil eden veriler ve prosedürler arasında bazı bağlantılar oluşturmaktır.
3. Ve sonra, diyelim ki, birçok ortak noktanın olduğu bir dizi emir tipine sahibiz. Temel nesne olacak COorderInfo nesnesini ve onun soyundan gelenleri farklı emir türlerini temsil etmek mantıklıdır. Aynı zamanda, alım satım işlemcisi (CTradeProcessor sınıfına sahibim), kendisine iletilen emri tam olarak bu emri işlemek için gereken prosedürlerle tam olarak destekleyecektir.
En az miktarda çapraz bağlantının olduğu yerde hataları yakalamak daha kolaydır. Bu sadece kapsülleme ve polimorfizm ile sağlanır. Alım satım pozisyonu arayüzünü (CTradePositionI) talep ediyoruz - ve bu pozisyonu temsil eden gerçek sınıflara (CMT4PositionInfo, CMT5PositionInfo) tüm linkler - sadece bu arayüz üzerinden yapılıyor, bu da hataları düzeltmeyi doğrudan gerçek fonksiyonlarla çalışmaktan daha kolay hale getiriyor. , hangi ticaret pozisyonu verilerini döndürür.