OOP vs prosedürel programlama - 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
Benim düşünceme göre, problem çözme sisteminizde bir çeşit kusur var. Görevin kendisi kristal berraklığında ve kesin olmalıdır ve dolayısıyla çözümü de olmalıdır. Karar belirsizse ve "Sistem kendini çok makul gösterdi" (270 kb kodda nasıl makul olabilir?!) sözleriyle tanımlanmışsa, bu, yazarın sisteminin nasıl çalıştığını yaklaşık olarak anladığı anlamına gelir. Ve sözdiziminin korkunç çanları ve ıslıkları ve çözmede gereksiz olan özü anlaması sonuna kadar engellenir.
Mantıklılık, "öngörü gücünde" yatıyor - çalışma protokollerinde önemli bir değişiklik - çalışmalarının mantığından sorumlu uzmanların kodunda değişiklik gerektirmedi. Kod değişikliği, yalnızca doğrudan terminalle düşük seviyede çalışan yerde gerçekleştirildi.
Verilen kod, tüm OOP zil ve ıslıklarının tamamen "işlevsel ziller ve ıslıklar" ile nasıl değiştirilebileceğini çok iyi gösteriyor. Yani, tam olarak yukarıda bahsettiğim şey - bu şekilde ve bu şekilde yazabilirsiniz.
Ancak kodunuza baktığımda, bellekte tutulması gereken çok daha fazlasının olduğunu görüyorum. Diyelim ki, çoğu zamanınızda - bir anda "boğuldum". Doğrular, ancak bu kodu korumam gerekseydi, her koşuldan önce, bu kontrolün ne yaptığını ve dizide tam olarak bu tür alanların neden kullanıldığını birkaç satır yorum eklerdim. Kodumda CTradePositionI arayüzünü bildirmeden önceki yoruma benzeterek. Artı - zor koşullar - şahsen ben de çok gergin olurdum.
Şahsen, kodunuzda daha fazla hata yapardım ve onları yakalamak daha zor olurdu. Yani, böyle bir kodun tüm doğruluğu ve mantığı ile, onu desteklemek benim için her şeyi OOP tarzında yazmamdan daha zor olurdu.
OOP tarzında, pencerelerin arayüzlerini, tuval detaylarını, elemanları, tuvalleri bildirirdim, sonra bu nesnelerin gerçek sınıflarını bu arayüzleri kullanarak yazardım ve sonra gerekli bloklarda bu arayüzlere işaretçiler verirdim ve özellikle şu anda ihtiyaç duyulacak varlıklarla çalışın - bu yerde diğer her şeye erişilemez. Tam olarak neyin neye ait olduğunu ve neyin neyin sorumlu olduğunu hatırlamamak için. Birkaç fonksiyondan en basit arayüzü elde edersiniz - bu yüzden onunla çalışın ve geri kalanı - buna ihtiyacınız yok, bu yüzden sizin için mevcut değil. Hiçbir şeyi hatırlamanıza gerek yok.
Neyse batırdılar...
Evet, herhangi bir görevin hem OOP tarzında, arayüzlerin tahsisi, miras hiyerarşisinin inşası , sanal fonksiyonların beyanı ile çözülebileceği açıktır ve tamamen prosedürel bir tarzda - hatta her şeyi bire yapıştırabilirsiniz. büyük işlev.
Sorun, desteğin rahatlığı ve verimliliğidir.
MT'de - OOP'ye en uygun yer sipariş sistemidir. Şahsen, "konumlar" ve "konum bileşenleri" sanal arayüzlerim var. "Pozisyon", MT4'teki bir dizi emir veya bir dizi MT5 pozisyonudur. Bir "pozisyon bileşeni", tek bir sipariş veya tek bir MT5 pozisyonudur (hedge veya ağ).
İşte gerçek arayüz dosyası ( Peter Konow , kod miktarına göre yorum sayısını tahmin edebilirsiniz ve bazı incelikleri hatırlamadığım gerçeğiyle karşılaştığımda periyodik olarak oraya ekliyorum. gerçek nesneler "konum bileşenidir". Sadece bunu hatırlamama gerek yok - EA, arayüze göre bileşenlerle çalışır ve aslında bu arayüzün arkasında neyin durduğu önemli değil. Ancak, değiştirirken buna geri dönmek zorundayım. - bu nedenle, genellikle bu dosyadaki ilk yoruma ihtiyacım var):
Ticaret bileşeni arayüz dosyası aşağıdaki gibidir (yukarıda zaten verdim ama tekrar edeceğim:
Bu arayüzlere göre hem gerçek hem de tarihi siparişler için hem MT4 hem de MT5 sipariş sistemlerini uyguladım.
Pozisyon talebinde bulunan bir Uzman Danışman bu arayüzü alır ve MT4 ve MT5 emirleri ile çalışmanın farkını hiç dikkate alması gerekmez. Ayrıca yeni bir emir tipi eklenirse veya onlarla çalışma sırası değişirse Expert Advisor için hiçbir şey değişmeyecek, sadece yeni emir tipinin sınıfı eklenecek ve bu arayüz de desteklenecek.
Riskten korunma hesapları tanıtıldığında sistemin çok makul olduğu kanıtlandı. Uzmanlar hiç değişmedi.
Peter Konow , MT4 ve MT5'te sipariş tiplerindeki farklılık sorununu nasıl çözüyorsunuz?
Yeni bir hesap türü tanıtılırsa (koruma ve netleştirmeye ek olarak) - tek bir yerde hangi değişikliklerin yapılması gerekecek?
Benim düşünceme göre, gerçekten, tüm kodunuzu mektuba hatırlıyorsanız ve bir yıl önce kodunuzda şu veya bu satırın neden yazıldığını kolayca söyleyebilirseniz, o zaman, aslında, tüm bu OOP çanları ve ıslıkları sadece gereksiz jestlerdir. kimsenin ihtiyacı yok.
OOP, kodu değiştirirken her şeyi hatırladığınızda tam olarak gereklidir - OOP, herhangi bir anda mevcut olan varlık setini programdaki belirli bir yerle sınırlamak için blokları birbirinden ayırmanıza izin verir.
Georges, bazen kadınlar hakkında böyle bir klinik yazıyorsun, ama kurallara saygı göster)))
Mantıklılık, "öngörü gücünde" yatıyor - çalışma protokollerinde önemli bir değişiklik - çalışmalarının mantığından sorumlu uzmanların kodunda değişiklik gerektirmedi. Kod değişikliği, yalnızca doğrudan terminalle düşük seviyede çalışan yerde gerçekleştirildi.
Verilen kod, tüm OOP zil ve ıslıklarının tamamen "işlevsel ziller ve ıslıklar" ile nasıl değiştirilebileceğini çok iyi gösteriyor. Yani, tam olarak yukarıda bahsettiğim şey - bu şekilde ve bu şekilde yazabilirsiniz.
Ancak kodunuza baktığımda, bellekte tutulması gereken çok daha fazlasının olduğunu görüyorum. Diyelim ki, çoğu zamanınızda - bir anda "boğuldum". Doğrular, ancak bu kodu korumam gerekseydi, her koşuldan önce, bu kontrolün ne yaptığını ve dizide tam olarak bu tür alanların neden kullanıldığını birkaç satır yorum eklerdim. Kodumda CTradePositionI arabirimini bildirmeden önceki yoruma benzeterek. Artı - zor koşullar - şahsen ben de çok gergin olurdum.
Şahsen, kodunuzda daha fazla hata yapardım ve onları yakalamak daha zor olurdu. Yani, böyle bir kodun tüm doğruluğu ve mantığı ile, onu desteklemek benim için her şeyi OOP tarzında yazmamdan daha zor olurdu.
OOP tarzında, pencerelerin arayüzlerini, tuval detaylarını, elemanları, tuvalleri bildirirdim, sonra bu nesnelerin gerçek sınıflarını bu arayüzleri kullanarak yazardım ve sonra bu arayüzlere gerekli bloklarda işaretçiler verirdim ve özellikle şu anda ihtiyaç duyulacak varlıklarla çalışın - bu yerde diğer her şeye erişilemez. Tam olarak neyin neye ait olduğunu ve neyin neyin sorumlu olduğunu hatırlamamak için. Birkaç fonksiyondan en basit arayüzü elde edersiniz - bu yüzden onunla çalışın ve geri kalanı - buna ihtiyacınız yok, bu yüzden sizin için mevcut değil. Hiçbir şeyi hatırlamanıza gerek yok.
Kodumda, çok sayıda ifof ve bunların yuvalanması, farklı kontrol yapanların farklı olaylar ve farklı durumlardaki karmaşık davranışlarından kaynaklanmaktadır. Ancak, bu özellik tüm bu seçenekleri kapsar ve GUI'nin tamamına tam olarak "hizmet eder". Herhangi bir elemanı yeniden çizerken, parçanın rengi, çekirdekteki orijinal renk değeri ve bu fonksiyon tarafından belirlenir.
PS OOP veya prosedür stili ile ilgili olarak, o zaman - "Herkesin kendisine" (c).
Georges, bazen kadınlar hakkında böyle bir klinik yazıyorsun, ama kurallara saygı göster)))
Kod hakkında - Gurur duydum. (Aslında şaka değil.)
Ve kadınlara gelince... Şey, ben senin gibi bir Casanova değilim... Hala kendimi tutuyorum ve düşündüğüm her şeyi ifade etmiyorum... Her zaman yaşadım ve hala çok büyük gerginlikler yaşıyorum. bu bağlamda, rahat bir kişisel yaşam benim için her zaman çok önemli olmuştur ... Bazen şansın bana gülümsemesi iyi ve sonuçta hatırlanması gereken bir şey var.
Kod hakkında - Gurur duydum. (Aslında şaka değil.)
Kadınlara gelince... Şey, ben senin gibi bir Casanova değilim... Hala kendimi tutuyorum ve düşündüğüm her şeyi ifade etmiyorum... Her zaman yaşadım ve hala çok zorlandım. bu bağlamda, rahat bir kişisel yaşam benim için her zaman çok önemli olmuştur ... Bazen şansın bana gülümsemesi iyi ve sonuçta hatırlanması gereken bir şey var.
Sadece kadınlara karşı farklı bir bakış açımız var. Sanırım yardıma ihtiyaçları var. Evet, kendi dürtüleriyle kaprislidirler, tercihlerinde değişkendirler, vb. Onları ciddiye almamalısın, yoksa ahlaki trajediler olacak.
Neyse batırdılar...
Evet, herhangi bir görevin hem OOP tarzında, arayüzlerin tahsisi, miras hiyerarşisinin inşası , sanal fonksiyonların beyanı ile çözülebileceği açıktır ve tamamen prosedürel bir tarzda - hatta her şeyi bire yapıştırabilirsiniz. büyük işlev.
Sorun, desteğin rahatlığı ve verimliliğidir.
Bu mümkündür, ancak farklı işleyiş verimliliği ile. Burada destekten söz edilmiyor, çok göreceli.
Prosedürel olarak en iyi şekilde çözülemeyen problemler vardır.
Sadece kadınlara karşı farklı bir bakış açımız var. Sanırım yardıma ihtiyaçları var. Evet, kendi dürtüleriyle kaprislidirler, tercihlerinde değişkendirler, vb. Onları ciddiye almamalısın, yoksa ahlaki trajediler olacak.
Alexey, bir deney yaptın mı, bir kadının yardım alma arzusu ne kadar sonsuz? Yardımla tatmin oldu ve ne kadar sürdü?
Anladığım kadarıyla, veri depolamak için yapıları bile kullanmıyorsunuz? Çok boyutlu dizileriniz , yapı eksikliği için bu tür çözümleri kullanmak zorunda kaldığınız eski MQL4'ün anılarını geri getiriyor. Ama şimdi ne anlamı var? Diyelimki
ile değiştirilebilir
Daha kısa, daha güvenilir (daha güvenli) ve daha hızlı. İlk durumda, içine kaydırdığınız dizi indekslerinin değerleri üzerinde derleme zamanı kontrolü yoktur. Ve sonra çalışma zamanında her türlü "aralık dışı diziyi" tırmıklayın - ve bu en iyi ihtimalle. Dizin geçerli ancak yanlış olduğunda daha kötü. Bu nedenle iyi bir programlama uygulaması, derleyiciyi maksimum düzeyde kullanmak, hataları derleme aşamasında tespit etmek ve sizinki gibi süreçteki hataları yakalamamaktır.
Evet, şimdi hangi değerleri göndermeniz gerektiğini hala iyi hatırlıyorsunuz. Ancak bunun nedeni muhtemelen sürekli olarak bu projeyle meşgul olmanızdır. Diyelim ki yarım yıl ara vermeye çalışın ve farkı hissedeceksiniz. Bazılarınız burada bundan zaten bahsetmişti. Yoksa burada düz sklerotiklerin chtol topladığını mı düşünüyorsun? :) Bu bir programcı için yaygın bir şeydir...
Dolayısıyla görev, kendinizi ayağınızdan vurma olasılığını en aza indirmek için bunu yapmaktır. Her yerde bulunan int yerine enum kullanarak kendi türlerinizi oluşturmanızı şiddetle tavsiye ederim. Ayrıca, numaralandırılmış değerlere sahip olmaları gerekmez, asıl mesele, bunun derleyici tarafından kontrol edilecek ve size işlev argümanlarını vb. karıştırma fırsatı vermeyecek olan ayrı bir bağımsız tür olmasıdır.
Sadece ve özel olarak OOP yazıyorum.
1900'ün tüylü bir yılında, içine giremedim - Pascal 6.0, ardından Borland C++ 4.5. Ama taşındığımda, başka türlü hayal edemiyorum - her şey çok basit ve kullanışlı hale geldi.
Anladığım kadarıyla, veri depolamak için yapıları bile kullanmıyorsunuz? Çok boyutlu dizileriniz , yapı eksikliği için bu tür çözümleri kullanmak zorunda kaldığınız eski MQL4'ün anılarını geri getiriyor. Ama şimdi ne anlamı var? Diyelimki
ile değiştirilebilir
Daha kısa, daha güvenilir (daha güvenli) ve daha hızlı. İlk durumda, içine kaydırdığınız dizi indekslerinin değerleri üzerinde derleme zamanı kontrolü yoktur. Ve sonra çalışma zamanında her türlü "aralık dışı diziyi" tırmıklayın - ve bu en iyi ihtimalle. Dizin geçerli ancak yanlış olduğunda daha kötü. Bu nedenle iyi bir programlama uygulaması, derleyiciyi maksimum düzeyde kullanmak, hataları derleme aşamasında tespit etmek ve sizinki gibi süreçteki hataları yakalamamaktır.
Evet, şimdi hangi değerleri göndermeniz gerektiğini hala iyi hatırlıyorsunuz. Ancak bunun nedeni muhtemelen sürekli olarak bu projeyle meşgul olmanızdır. Diyelim ki yarım yıl ara vermeye çalışın ve farkı hissedeceksiniz. Bazılarınız burada bundan zaten bahsetmişti. Yoksa chtol toplanan düz sklerotikler olduğunu düşünüyor musunuz? :) Bu bir programcı için yaygın bir şeydir...
Yani görev, kendinizi ayağınızdan vurma olasılığını en aza indirmek için bunu yapmaktır. Her yerde bulunan int yerine enum kullanarak kendi türlerinizi oluşturmanızı şiddetle tavsiye ederim. Ayrıca, numaralandırılmış değerlere sahip olmaları gerekmez, asıl mesele, bunun derleyici tarafından kontrol edilecek ve size işlev argümanlarını vb. karıştırma fırsatı vermeyecek olan ayrı bir bağımsız tür olmasıdır.
Diğer branşlardaki yazılarınızı okudum ve programlama konusunda harika bir uzman olduğunuzu anladım. Doğal olarak, değilim ve öyleymiş gibi davranmıyorum. Ancak, kendimi bu tür sorunları çözmede uzman olarak görüyorum. Sonuçta, en önemli olanın kararın etkililiği olduğunu kabul edeceksiniz.
Söz dizimi yığınları ve kuralların karmaşıklığı, çözümlerin etkinliğinin korunmasına hiçbir zaman katkıda bulunmamıştır. Kod bloklarının özlülüğü, evrenselliği ve okunabilirliği ile ifade edilen sadelik ve kısalığa katkıda bulunmuştur.
Programlamadaki kurallarım, daha az kod, daha az kural, daha az sözdizimi ve ana dili ve anlamlı değişken ve fonksiyon adlarını kullanarak daha az yorum.
Ana tezim, "Çözümde bir şey olmadan yapabiliyorsan, kesinlikle onsuz yapmalısın."
Sklerotiklerin burada toplandığını hiç sanmıyorum.)) Sadece verilen kodlara bakıldığında, neden kolayca unutuldukları anlaşılıyor. Bir yabancı dilde programlama gerçeği bile bir rol oynar. Kendi dilinizde programladığınızda, tamamen farklı hissettiriyor. Gerginlik ve sertlik değil, güç ve özgürlük hissedersiniz. Bir yabancı dil daha fazla çaba gerektirir, kodu anlamak daha fazla zaman alır ve kafanızdan daha hızlı uçar. Bu sadece bir "biyolojik faktör".
Bu nedenle, sorunlarımı çözmek için OOP'nin bir bütün olarak kullanılmasının (oldukça haklı olarak) verimsiz olduğunu düşünüyorum. Bir dizi kural, sözdizimi ve yabancı dilde her şey. Yani yetenek gerçekten dönmüyor, bu da sonucun daha kötü olacağı anlamına geliyor. BENİM NACİZANE FİKRİME GÖRE.