MQL5'te OOP gerekli olacak mı? - 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
Süreçle veya nihai sonuçla ilgileniyor musunuz?)))
Ben - ikisi de, ama sonuç bir şekilde daha fazla. ("...OOP, programlarınızı yavaşlatmanın birçok yolunu sunar...")
OOP'nin prosedürel yaklaşımdan daha hızlı yazmama nerede izin vereceğini ve bu, OOP'nin tüm eksilerinden daha ağır basacağını görmüyorum. Kimin ihtiyacı var - bu çok açık - başkaları için yazan bir geliştirici.
Size bir benzetme yapayım: Birincisi bir bıçak alıp telkari bir heykelcik kesti ve ikincisi aynı bıçakla parmağının yarısını kesti. Bu ne için? Herhangi bir araç hem "şeker" yaratabilir hem de sıradanlığı tamamlayabilir. Her şey programcının zanaatkar olup olmamasına veya bir yetenek kıvılcımına sahip olmasına bağlıdır. Bu bir geri çekilme, ama aslında - FOP size daha yakınsa, onu daha fazla kullanın.
Bir konu oluştururken, MT amaçlı projelerde OOP lehine argümanlar görmek istedim. Belki de cehaletim yüzünden - flört etmiyorum - onları görmedim. Şimdi görmüyorum.
Yazılarınızı özetleyelim (bu arada herkese teşekkürler):
1. Proje uygulamasının kolaylığı ve hızı.
2. Bakım, modernizasyon.
3. 5 daha hızlıdır, çünkü FSU'lar nasıl programlanır.
3. OOP'yi yavaşlatmanın bir nedeni olarak eğrilik.
------------
(omuz silkerek) Anlayın, OOP'ye karşı değilim, sadece MT görevlerinde bana neler verebileceğini kendim bulmak istedim - hindiler, senaryolar, danışmanlar oluştururken.
TAMAM. 5'teki yardım. 5-ke üzerinde OOP kullanılarak yazılan MT4'ün standart teslimatından kim basit bir hindi örneği verebilir?. Orada görünür olacak. Orada, metindeki gecikmeler, programın okunabilirliği vb.
1. Proje uygulamasının kolaylığı ve hızı.
2. Bakım, modernizasyon.
1. OOP - temel ilkeleri anlayanlar için çok kullanışlı. Bu en basit uygulamalarda bile hissedilir. OOP ile herhangi bir uygulama yapmak daha uygundur.
2. Projenin büyüklüğü, anlaşılması zor değilse bir engel değildir. Ve program nesne yönelimliyse, bunu anlamak zor değildir. Bir örnek SaxoBank terminalidir. C# ile yazılmıştır - nesne yönelimli bir dil. Her dll'de yaklaşık 20.000 satır kod vardır. OOP olmasaydı, bu kadar büyük bir bilgiyi anlamak ve hatta daha da fazlasını modernize etmek neredeyse imkansız olurdu.
Zaten OOP olmayanlara dayanıyorlar (mutlak OOP pratikte uygun olmasa da). Başlangıçta soyut sınıflar oluşturmak ve gerçek nesnelere ulaşmak için kalıtım ve polimorfizm kullanmak gerekiyordu. Örneğin, soyut yöntemler ve özelliklere sahip özel göstergeler için bir temel soyut sınıf. Kısacası, hiyerarşik bir sınıf ağacı oluşturun: grafik nesneler, bir hesapla çalışmak, çizelgeler ve zaman serilerine erişim vb. için kendi ağacınız. Ve önceden tanımlanmış prosedürler ve işlevler için yalnızca hız gerektiren basit bir rutin bırakın. Daha sonra, platformun yeteneklerini herhangi bir soyutlama seviyesinden genişletmek mümkün olacak, bu da kodu önemli ölçüde azaltacak, okunabilirliği artıracak ve diğer programcılar tarafından anlaşılması kolay olacaktır. Ve MT5'te prosedürler düzeyinde oldukça karmaşık şeyler zaten uygulanmaktadır (aslında, tüm platform kullanıma hazırdır) ve en azından oluşturulan iç yapıların tanımlayıcılarına işaretçilerle erişme olasılığını görmedim, ki bu büyük ölçüde olacaktır. olasılıkları sınırlayın (yardıma göre değerlendirin). Ve genel olarak, OOP ihtiyacı sorgulanabilir, böyle bir uygulama ile kendimizi yapılar ve dinamik yerleştirme ile sınırlamak mümkün oldu. OOP, dallanmış bir sınıf hiyerarşisi tarafından aşağıdan desteklenmelidir. imha
Programların programcılar tarafından YAZILMADIĞINI, OKUYUN olduğunu anlamak 1-3 yıl programlama gerektirir.
Programların bir bilgisayar için değil, bir kişi için (özellikle kendisi için) yazıldığını anlamak için 1-2 yıl daha gerekiyor.
Ardından, OOP ve C++'ın insansı düşünme düzeniyle ve insan dilleri oluşturma yöntemiyle çeliştiğini fark etmek 1-2 yıl sürer.
Başkalarının hammaddelerini incelemek ve en iyi ve en güvenilir programların klasik Ce ile yazıldığını anlamak için 1-2 yıl daha gerekiyor.
Peki, bundan sonra Dijkstra'nın C++ ve OOP'nin mide ağrısına neden olduğu gerçeğiyle ilgili röportajını okumak yeterli.
Ve bundan sonra (toplam 4-9 yıl) "OOP hakkında" sorular hiç ortaya çıkmaz ve bu tür tartışmalar sadece küçümseyici bir gülümsemeye neden olur.
Ve bundan sonra (toplam 4-9 yıl) "OOP hakkında" sorular hiç ortaya çıkmaz ve bu tür tartışmalar sadece küçümseyici bir gülümsemeye neden olur.
anlayışla karşılıyorum.