Mt4 End desteği. - sayfa 28
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
Birisi önerdi mi bilmiyorum ama neden MT4'teki her şeyi MT5'e aktarmıyorsunuz, o zaman herkes geçiş yapardı.
George Merts :
İlk önce, parçalar yazılır ve daha sonra bir bütün halinde birleştirilirler, genellikle parçaların birbiriyle zayıf uyumlu olduğu gerçeğiyle karşı karşıya kalırlar - bu arada, "mevcut tüm değişkenlere erişime sahip olma" arzusunu tam olarak açıklayan şey budur. "
Numara. Tüm olası değişkenlere erişim söz konusu değildir, yalnızca ihtiyaç duyulanlara erişim söz konusudur. Genellikle bunlar farklı fonksiyonların girdi ve çıktı değişkenleridir.
Buraya bir kerede ek sınırlar eklemek , kodun okunabilirliğini önemli ölçüde zorlaştıracak ve bir şey bu sınırlar nedeniyle yol boyunca kaybolduğu için bir yere ulaşmadığında olası hataları artıracaktır.
Tabii ki, en azından yararlı bir şey için bir şekilde OOP'nin kulaklarını çekme arzusu anlaşılabilir, ancak bu tür durumlar genellikle programlama alanında değil, ticari alanda, örneğin, ek programlama saatlerini aldatmak, sonsuz tartışmaları beslemek gibi. arayüzlerin mimarisi ve çalışma zamanındaki benzer hoş eğlenceler hakkında.
Böyle bir örnek gerçekten var mı? Seninki olmasın? Derin şüphelerim var. 2000'li yılların başında yazdığım kodların hata ayıklanmış ve çalışan satır sayısını saymayı bıraktım çünkü bir milyonu aştı, ilgimi çekmeye başladı. Ve görevlerin çeşitliliği ve kapsamı çok farklı olmasına rağmen, asla kendi sınıfınızı yaratmanıza gerek yoktu. Çalışmayı birkaç kişi için paralel hale getirmek gerektiğinde, prosedür tipi değişkenler kullanılmalıydı, ancak artık kullanılmamalıdır. Nedenmiş?
Gerçek şu ki, OOP sadece hazır kodun paketlenmesine uygulanabilir, sadece kod yazma aşamasında müdahale eder. Ancak böyle bir ihtiyaç yoksa, OOP gerekli değildir.
Vladimir :
OOP'nin hesaplamaların otomatik paralelleştirilmesini önlediği ortaya çıktı. Şimdi bu çok ciddi bir eksiklik olarak kabul edilmelidir, olasılık OOP için değildir.
Systemverilog gibi dillerde perspektif.
isNewBar() işlevinin doğada hiç olmaması dışında her şey yolunda. Böyle önemsiz bir şeyin etrafında bu kadar çok dans olması komik.
Bu sadece bir değişkendir ve sadece çubuğun zamanı ile karşılaştırılır, eğer tüm durumlar başarılı olursa, sonunda değişkene yeni çubuğun zamanı atanır. Aksi takdirde, tüm durumlar için yalnızca bir deneme tahsis edilir.
Buraya bir kerede ek sınırlar eklemek , kodun okunabilirliğini önemli ölçüde zorlaştıracak ve bir şey bu sınırlar nedeniyle yol boyunca kaybolduğu için bir yere ulaşmadığında olası hataları artıracaktır.
Tam tersi doğrudur - sınırlar, "bu değişken ne için, bu durumda nasıl bir rol oynuyor, dikkate alınmamalı mı?" diye düşünmemenizi sağlar.
Kullanıcının yalnızca dikkate alması gerekenlere ve yalnızca değiştirebileceklerine erişimi vardır. Bunlar "yolda bir şey kaybolduğunda" yapılan hatalardır - ve tam olarak çok fazla mevcut olduğu ve bir şeyin "yol boyunca unutulmuş" olduğu için ortaya çıkarlar. "Kesilmiş" sanal arabirimlerle bunu yapmak çok daha zordur.
İşte en basit örnek: bir pozisyon almak. Bir pozisyon, MT4'teki açık emirler veya MT5'teki açık pozisyonlardır.
Tam erişiminiz varsa, bir konum seçerken, kullanıcının şimdi hangi değişkenlerin okunabileceğini, hangi değişkenlerin şu anda geçersiz olduğunu, hangi değişkenleri değiştirebileceğini, hangilerini değiştiremeyeceğini hatırlaması gerekir.
Arayüz ile - her şey çok daha basit. Anladınız ve yalnızca iki işlev içeriyor: bileşenlerin sayısını alın ve sabit bir bileşene bir işaretçi alın. TÜMÜ. Bu iki işlevin yardımıyla - fiziksel olarak herhangi bir "gereksiz değişkene" erişemezsiniz.
Andrew :
Tabii ki, en azından yararlı bir şey için bir şekilde OOP'nin kulaklarını çekme arzusu anlaşılabilir, ancak bu tür durumlar genellikle programlama alanında değil, ticari alanda, örneğin, ek programlama saatlerini aldatmak, sonsuz tartışmaları beslemek gibi. arayüzlerin mimarisi ve çalışma zamanındaki benzer hoş eğlenceler hakkında.
Ve sen kendin buna er ya da geç geleceksin. Ayrıca, kapsülleme "tamamen prosedürel" bir yaklaşımla yapılabilir. Ancak, OOP yaklaşımında, kalıtım ve polimorfizmi "otomatik olarak" elde ettiğiniz için bu daha uygundur.
Birisi önerdi mi bilmiyorum ama neden MT4'teki her şeyi MT5'e aktarmıyorsunuz, o zaman herkes geçiş yapardı.
Sorun sadece 4-ke'de 5-ke'de olmayan bir şey olması değildir. Ve OOP bile değil.
5, tüccarlara pratikte hiçbir şey vermedi (bir programcı değil, programcı tüccarlar değil - sadece tüccarlar).
Kendi tarih formatı, gelenek yasağı - ancak yalnızca bu iki nokta, geometri ile ticaret yapan herkesi korkuttu. Ve hiçbir "birçok TF" (yıllık, lol olmadan), çubuk başına puan cinsinden ölçekler onları çekmez.
Basit soru. Izgara ne gösteriyor? Öğrenmeye çalışmak, sizi serbest çalışma için başvurmak ve istediğinizi sipariş etmek için bir öneriye götürecektir.
MT - programcılar için terminaller. Bütün cevap bu.
Gerçek şu ki, OOP sadece hazır kodun paketlenmesine uygulanabilir, sadece kod yazma aşamasında müdahale eder. Ancak böyle bir ihtiyaç yoksa, OOP gerekli değildir.
Hayır. Her şey tam tersi.
Etkileşim arayüzleri - başlangıçta, hatta "kod yazma aşamasından önce" tanımlanır. Arayüzler aslında bir programcı için aynı teknik özelliklerdir. Freelance'daki tüm etkileşimler, net referans koşulları kullanılarak gerçekleştirilir. Burada sanal arayüzler - bu, programlamanın başladığı bir tür TK'dir.
Sen sadece, anladığım kadarıyla, OOP'nin özüne yanlış bir yaklaşımsın. Önce bir sürü fonksiyon yazıyorsunuz ve sonra bunları OOP tasarımına "sıkmanız" gerekiyor. Ama bu yanlış yol. Tersini yapmak doğrudur - ilk olarak, sistem bileşenleri arasındaki temel arabirimlerin çok setleri olan OOP tasarımı belirlenir. Ve sonra - her bileşen, bu çok önceden tanımlanmış arayüzlere bağlı kalarak sırayla yazılır.
Evet, yazarken arayüzün bir şey sağlamadığı ortaya çıkıyor. Ve başlıyor ... "Voooot ... prosedürel bir yaklaşımla - tüm bunlara erişimim olurdu, ihtiyacım olanı sorunsuz yapardım ve şimdi - bu değişkenlere nasıl erişeceğim?". Bu, arayüz tasarımı aşamasında bir şey dikkate alınmadığında olur. Ve bu çok tatsız bir durum - ya bazı ek arayüzler eklemeniz ya da mevcut olanları değiştirmeniz gerekiyor - bu da hatalarla dolu. Böyle bir durumdan elbette kaçınılmalıdır.
İşte en basit örnek: bir pozisyon almak. Bir pozisyon, MT4'teki açık emirler veya MT5'teki açık pozisyonlardır.
Tam erişiminiz varsa, bir konum seçerken, kullanıcının şimdi hangi değişkenlerin okunabileceğini, hangi değişkenlerin şu anda geçersiz olduğunu, hangi değişkenleri değiştirebileceğini, hangilerini değiştiremeyeceğini hatırlaması gerekir.
Arayüz ile - her şey çok daha basit. Anladınız ve yalnızca iki işlev içeriyor: bileşenlerin sayısını alın ve sabit bir bileşene bir işaretçi alın. TÜMÜ. Bu iki işlevin yardımıyla - fiziksel olarak herhangi bir "gereksiz değişkene" erişemezsiniz.
Tam tersi doğrudur. Örneğin, kalite modülü testi için kullanıcıların dahili değişkenleri bilmesi genellikle önemlidir, ancak durum böyle değildir. Ve daha sonra bu erişimi nasıl elde edeceklerinin özel zor yollarını buluyorlar. Bu nedenle, prensip olarak, gereksiz bilgi yoktur ve buna ihtiyacı olmayanlar onu kullanamazlar.
Tam tersi doğrudur. Örneğin, kalite modülü testi için kullanıcıların dahili değişkenleri bilmesi genellikle önemlidir, ancak durum böyle değildir. Ve daha sonra bu erişimi nasıl elde edeceklerinin özel kurnaz yollarını buluyorlar. Bu nedenle, prensip olarak, gereksiz bilgi yoktur ve buna ihtiyacı olmayanlar onu kullanamazlar.
"Almak için kurnaz erişime" ihtiyacınız varsa - bu, sistemin yanlış bir tasarımını gösterir.
Örneğin, bir giriş sinyali üreteci yazıyorsak, örneğin para yönetimi ile ilgili bilgilere erişimimiz olmamalıdır.
Tabii ki, hata ayıklama sırasında, örneğin giriş gerçekleşmediğinde bir durum ortaya çıkabilir - bu gerçekleştiğinde durumu derhal ayıklamanız gerekir çünkü para yönetimi işlemi yasaklamıştır (örneğin, yeterli marj yoktur). Ve bunu giriş üretecinden nasıl biliyorsunuz? Hayır, erişiminiz yok. Ancak bu durumda, jeneratörün girişe bir sinyal verdiğinden ve doğru çalıştığından emin olmak yeterlidir. Girdi yoktu - başka bir nedenden dolayı, girdi oluşturucunun dışında. Bunun nedenini bulmak, gerçekten de, tüm para yönetimi değişkenlerine doğrudan erişime sahip olmamızdan biraz daha zor. Ancak, normal, tam zamanlı çalışma sırasında - onlara erişimimiz olan - "yanlış yere girmemiz" çok daha tehlikelidir.
"Almak için kurnaz erişime" ihtiyacınız varsa - bu, sistemin yanlış bir tasarımını gösterir.
Gelişim öncelikle zihnin doğal bir sürecidir.
Bu süreçte fikirler özgürce ve hatta kendiliğinden oluşur.
OOP'yi takip etmek, ücretsiz kod dönüşümünü zorlaştırır.
Doğal gelişim sürecinde, kodun kendisi yavaş yavaş sıkıştırılır ve evrenselleştirilir.
Doğal bir süreçte, işlevler parçalanmaz, aksine büyür ve büyük bloklar halinde birleşir.
Büyük bloklar çok çeşitli sorunları çözer.
OOP, kodu parçalanmış halde bırakarak bu tür blokların oluşumuna müdahale eder.
OOP karmaşık erişim yaratır, bu nedenle değişkenlere yapılan referansların sayısı sürekli artmaktadır.
Erişim kontrolünün avantajları, tek bir mekanizma oluşturmanın zorluğuyla dengelenir.
Ana dezavantaj: OOP, kodu birçok işleve bölme yolunda sizi zorlar.
Bir kişinin parçalanmış kodu algılaması daha kolaydır, ancak parçalanma herhangi bir mekanizmada kontrendikedir.