OOP uzmanları için soru. - sayfa 11
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
Bir programcı forex dünyasına girerse, profesyonel olmaya ve OOP'yi bilmeye gerek yoktur.
Piyasanın inceliklerini incelemek ve karlı bir ticaret stratejisi geliştirmek daha iyidir. OOP kullanıp kullanmamanız önemli değil. Bu, EA'nın karlılığını etkilemeyecektir.
Enerjinizi boşa harcamanıza gerek yok.
George, bu sadece hafızayla ilgili değil. Ana dilimin yanı sıra İngilizceyi de kullanarak kendime rahat bir gelişim ortamı oluşturdum. İki dilli bir kod, tek dilli olandan ÇOK daha iyi hatırlanır. Özellikle standart kelimelere takılıp kalmadığınız ve değişkenleri istediğiniz gibi çağırdığınız zaman. Kontrol. Programlamadaki profesyonellik umurumda değildi ve uygun şekilde yazmaya başladım. Sonuç olarak, kodumda hızlı bir şekilde gezinmeye başladım ve kodu okuması, hatırlaması ve geliştirmesi kolaydı. Sonrası biliyorsun...
Yardımcı olabileceğini sanmıyorum. Benim için, herhangi bir dildeki değişkenlerin adı neredeyse anında hafızadan siliniyor, bilgisayardan kalktım ve zaten sadece genel ilkeleri hatırlıyorum ve hangi değişkenlerin bir yerde veya başka bir yerde tanıtıldığını söyleyemem.
Bu arada, bu yüzden her zaman mqh-mq5 dosyası çiftleri kullanıyorum ve sınıfları tamamen mqh dosyalarına yazmıyorum - genellikle şu veya bu durumda ne olduğunu kendime hatırlatmak için başlık dosyalarına bakmam gerekiyor. sekmelerde gerekli mqh başlıklarını açtım ve bu bilgiyi tekrar yenilemem gerektiğinde onlara geçiyorum. Tüm sınıf (özellikle birkaçı) tek bir mqh dosyasında tanımlandığında, yer imlerinin yardımıyla bile bu dosyanın üzerinden "atlamak" daha streslidir.
Tüm yapıyı hafızamda tutamıyorum, ancak gençliğimde, daha önce de söylediğim gibi, assembler'da bile yazdım, ancak başka seçenek yok - sadece hafıza adresleriniz ve makro assembler'ın izin verdiği maksimum değer var makro ikameleri kullanarak belirli alanların adlarını oluşturmaktır. Bu da mümkün. Ancak uzun zamandır hata sayısının çok daha fazla olduğuna ve bu tür kodlarda hata ayıklamanın çok daha zor olduğuna ikna oldum.
Yukarıda bir örnek zaten verilmiş - bir hata oluştu, bir nedenden dolayı değişken yanlış değiştiriliyor. Ve değişken, programdaki birçok yerden erişime sahiptir. Hatanın olduğu yer nasıl yakalanır? OOP kapsülleme ile her şey çok basittir - arayüz işlevinde değişkeni değiştiren bir kesme noktası belirleriz ve yanlış bir değişiklik meydana gelir gelmez durur ve hemen, çağrı hiyerarşisine göre yanlış değişikliğin nerede olduğunu görürüz. den imal edilmiş. Ve senin yaklaşımınla Peter, bu değişkene erişilen tüm yerlere bakarak, her yere kesme noktaları koyarak ve yalnızca yanlış olanı değil, tüm erişimleri analiz ederek tüm kodu taramamız gerekiyor.
İşte asıl mesele bu, acı çekebilecek olan. Bir arkadaş, koddaki bir hata nedeniyle depozitonun bir kısmını kaybetti ve OOP sadece hata olasılığını azaltır.
Bu onun iyi bir programcı olmadığı anlamına gelir. Karmaşık OOP yapılarında, onsuz olduğundan daha fazla kafanız karışabilir.
Gerektiğinde sınıflar uygulanmalıdır. Bu yüzden bazı programcıların bir çeşit çılgınlığı olduğunu fark ettim, ihtiyaç olmayan her yerde birçok işlevi kullanıyorlar. Bu, sınıflarda da böyledir.
OOP'siz kompakt ve kısa bir program yazmak yerine, bazı programcılar sınıfları, birçok işlevi kullanmaya başlar ve basit bir çözüm bir kilometre uzunluğundaki metne dönüşür.
Bu onun iyi bir programcı olmadığı anlamına gelir. Karmaşık OOP yapılarında, onsuz olduğundan daha fazla kafanız karışabilir.
Ceteris paribus mu? Bundan oldukça şüpheliyim. Tasarımların karmaşıklığı aynıysa, OOP ile başa çıkmak çok daha kolaydır.
Bununla birlikte, bu "toptan serçelere" kuralları değiştirmez, görevin çok basit ve kompakt olduğu büyük OOP çan ve ıslık kullanmak mantıklı değildir.
Yukarıda belirtildiği gibi, OOP, daha sonra birçok projede kullanılan sınıf kitaplıklarını yazmanıza izin verir.
Diyelim ki aynı dizi sınıfları, dosya sınıfları... OOP kullanmadan çok basit bir gösterge yazsanız bile , CFile sınıfını gerekirse bildirmek ve işlevlerini kullanmak, dosyalarla çalışmak için standart işlevleri almaktan çok daha kolaydır. CFile'ı daha spesifik olanlarla kolayca değiştirme yeteneğinden bahsetmiyorum, örneğin, bir CLogFile sınıfım var - satırlara otomatik olarak zaman ve bazı ek veriler (günlük dosyaları için) veya bir CIniFile sınıfı ekleyebiliyorum. verileri standart dosyalar halinde düzenleyin ve ardından bunları gerektiği gibi okuyup kullanın.
Bu onun iyi bir programcı olmadığı anlamına gelir. Karmaşık OOP yapılarında, onsuz olduğundan daha fazla kafanız karışabilir.
Gerektiğinde sınıflar uygulanmalıdır. Bu yüzden bazı programcıların bir çeşit çılgınlığı olduğunu fark ettim, ihtiyaç olmayan her yerde birçok işlevi kullanıyorlar. Bu, sınıflarda da böyledir.
OOP'siz kompakt ve kısa bir program yazmak yerine, bazı programcılar sınıfları, birçok işlevi kullanmaya başlar ve basit bir çözüm bir kilometre uzunluğundaki metne dönüşür.
Asıl çalışmanın yüz satır olması ve kalan birkaç bin satırın uzun zaman önce yazılmış ve hata ayıklanmış kitaplık olması uygun mudur? )))
Bir programcı programında CTrade, CAccountInfo, CPositionInfo gibi hazır sınıflar kullanıyorsa, bu, programının OOP tabanlı olduğu anlamına gelmez.
Bu, programcının kendisinin bu tür sınıfları oluşturmasına veya bu sınıfların içini (kaynak kodu düzeyinde) bilmeden bunları kullanmasına bağlıdır.
....
Yukarıda bir örnek zaten verilmiş - bir hata oluştu, bir nedenden dolayı değişken yanlış değiştiriliyor. Ve değişken, programdaki birçok yerden erişime sahiptir. Hatanın olduğu yer nasıl yakalanır? OOP kapsülleme ile her şey çok basittir - arayüz işlevinde değişkeni değiştiren bir kesme noktası belirleriz ve yanlış bir değişiklik meydana gelir gelmez durur ve hemen, çağrı hiyerarşisine göre yanlış değişikliğin nerede olduğunu görürüz. den imal edilmiş. Ve senin yaklaşımınla Peter, bu değişkene erişilen tüm yerlere bakarak, her yere kesme noktaları koyarak ve yalnızca yanlış olanı değil, tüm erişimleri analiz ederek tüm kodu taramamız gerekiyor.
Evet, çekirdeğim programın tüm bölümlerinde değiştirildi ve hatalar oluyor, ancak kesme noktaları olmadan yapıyorum. Değerleri kontrol etmek için aklımda hesaplar ve birkaç yere uyarı koyarım. Ben böyle buluyorum. Programımı çok iyi bildiğimi vurgulayayım.
Ancak artısı, bu tür bilgilerle, sözdizimsel engellerin olmaması ve ana dilimin hızlı gelişme için büyük fırsatlara sahip olmasıdır. İşte bu yüzden kararlarımda OOP'a karşıyım.
Kod bölme, yabancı tek dilliliği, yeni sözdizimi, ek kurallar - tüm bunlar programın gelişimini yavaşlatacaktır. Daha fazla güç kaybedeceğim ve daha az sonuç alacağım. Kesinlikle biliyorum.
Görevlerim bir programı hazır kod parçalarından bir araya getirmek ve hatalarını ayıklamaksa, yalnızca OOP ve kitaplıklar. Büküm ve yeni çözümler geliştirmek iki farklı şeydir. Pek çoğu, başka birinin kodunun parçalarını kullanmak ve çabadan tasarruf etmek istedikleri için OOP'yi savunuyor. Çözümlerimi tescilli teknolojiyi kullanarak oluşturuyorum ve OOP konusunda farklı ihtiyaçlarım ve görüşlerim var.
Evet, programın tüm bölümlerinde çekirdeğim değiştirildi ve hatalar oluyor, ancak bunu kesme noktaları olmadan yapıyorum. Değerleri kontrol etmek için aklımda hesaplar ve birkaç yere uyarı koyarım. Ben böyle buluyorum. Programımı çok iyi bildiğimi vurgulayayım.
Ancak artısı, bu tür bilgilerle, sözdizimsel engellerin olmaması ve ana dilimin hızlı gelişme için büyük fırsatlara sahip olmasıdır. İşte bu yüzden kararlarımda OOP'a karşıyım.
Kod bölme, yabancı tek dilliliği, yeni sözdizimi, ek kurallar - tüm bunlar programın gelişimini yavaşlatacaktır. Daha fazla güç kaybedeceğim ve daha az sonuç alacağım. Kesinlikle biliyorum.
Görevlerim bir programı hazır kod parçalarından bir araya getirmek ve hatalarını ayıklamaksa, yalnızca OOP ve kitaplıklar. Büküm ve yeni çözümler geliştirmek iki farklı şeydir. Pek çoğu, başka birinin kodunun parçalarını kullanmak ve çabadan tasarruf etmek istedikleri için OOP'yi savunuyor. Çözümlerimi tescilli teknolojiyi kullanarak oluşturuyorum ve OOP konusunda farklı ihtiyaçlarım ve görüşlerim var.
İletişim kutusu şablonunu VC++'da en az bir kez kullanmanızı, MFC'den CDialog tabanlı bir uygulama oluşturmanızı, üzerine her türlü Kontrolü görsel modda yüklemenizi , OOP'nin tam gücünü anlamak için hazır işlevleri kullanmanızı öneririm.
Borland C++'da Oracle ile çalışmak için çok uygun sınıflar oluşturulduğunu da ekleyeceğim. 2012'ye kadar onunla çalıştım, şimdi nasıl bilmiyorum.
İletişim kutusu şablonunu VC++'da en az bir kez kullanmanızı, MFC'den CDialog tabanlı bir uygulama oluşturmanızı, üzerine her türlü Kontrolü görsel modda yüklemenizi , OOP'nin tam gücünü anlamak için hazır işlevleri kullanmanızı öneririm.
Borland C++'da Oracle ile çalışmak için çok uygun sınıflar oluşturulduğunu da ekleyeceğim. 2012'ye kadar onunla çalıştım, şimdi nasıl bilmiyorum.
bahçede 2019'un ikinci yarısında .... ama 20'sinde ve 25'inde ve ....'de OOP kullanma ihtiyacı hakkında da konuşacaklar mı?
))))
beğendik, beğenmedik - peki, bugün ayağa kalkma, kalktım, kullanmıyoruz
önceden yazılmış küçük alt rutinleri kullanarak programlar yazmaya alışkın - yaz, yanlış ayağa kalktın ... peki, tüm bu alt rutinleri kaynak kodun yerine koy ve büyük bir kod parçası al
insanlara PL için harika fırsatlar verdi, hala aynı değil, işlevselliği saf C'ye indirdi, yine böyle olmayacak))))
Not: Zaten geliştiricilerden birinin forumu okuduğundan şüpheleniyorum ... Bence bu konu kesinlikle onların ruh halini yükseltiyor! ))))