OOP'a ilginç bir bakış - sayfa 10

 
Vitaly Muzichenko :

Okunabilirlik ve dağınıklık açısından bu tasarımı hiç sevmiyorum.

Kabul ediyorum)))

Bunun için tek gerekçe hata ayıklamadır)

 
Vitaly Muzichenko :

Okunabilirlik ve dağınıklık açısından bu tasarımı hiç sevmiyorum.

bu benim asıl sorumdu

son örnekler @fxsaber'ın çalıştırıldığında %100 farklı kodlar olacağına dair ifadesidir, birkaç sayfa önce hata ayıklayıcıdan ayrıştırıcıyı gönderdim - kodlar %90 aynı

sorunsuz okunan basit yapıların iadesi yoluyla geri dönmeyi reddetmekten bahsetmiyoruz

 
Igor Makanu :

bir yerde yazdılar ve burada geliştiricilerin benzer bilgileri var

sadece şunu buldum:

switch, atlama tablosu kullanan güvenli bir yoldur. Onlar. 'durum' adresi tamsayı anahtarından hesaplanır   anahtarda. Bu nedenle, anahtar, sözlükler gibi daha süslü koleksiyonlardan bahsetmiyorum bile, if-else ile karşılaştırıldığında bile son derece verimlidir.

 
fxsaber :

"Derleyici onu en iyi şekilde tarayacak" temelinde herhangi bir kalitede kod yazıldığında burada olumsuz bir etki olmuyor mu?

Tek bir yazım stiliyle, derleyicinin doğru olanı yapacağından emin olabilirsiniz. Diğeriyle - sadece derleyicinin daha akıllı olduğunu umalım.

Platformlar arası, farklı derleyiciler vb. hesaba katarak, kodda ne yaptığınızın farkındalığını seçiyorum.

Derleyicinin tam olarak nasıl yapacağını sadece kendisi bilir. Modern derleyicilerde yerleşik çarpıcı buluşsal yöntemler vardır. Ortalama kodlayıcıya uyum sağlarlar ve neye ihtiyacı olduğunu zaten daha iyi bilirler. Bir derleyici için yapılacak en iyi şey, kısa fonksiyonlarla basit, anlaşılır kod yazmaktır. Derleyicinin birçok düğüm fonksiyonundan oluşan kaynak kod grafiğini analiz ederek nihai programı oluşturması çok daha kolay ve verimlidir. Bu sadece performans üzerinde olumlu bir etkiye sahip olacaktır, çünkü gerekli işlevler doğru yerlerde sıralanacaktır.

 
Vasiliy Sokolov :

switch, atlama tablosu kullanan güvenli bir yoldur. Onlar. 'durum' adresi tamsayı anahtarından hesaplanır   anahtarda. Bu nedenle, anahtar, sözlükler gibi daha süslü koleksiyonlardan bahsetmiyorum bile, if-else ile karşılaştırıldığında bile son derece verimlidir.

serin! bu yararlı bilgi

TEŞEKKÜR!

 

Birçok kişi küçük sınıflar yazmayı önerir. Aynı Eckel şöyle diyor: "Tek, açıkça tanımlanmış bir amaç için sınıflar oluşturun."

Şimdi bir danışman üzerinde çalışıyorum, biraz basitleştirilmiş bir örnek yazacağım. "Maksimum durdurma kaybı sayısına ulaşılması" parametrelerinden biri vardır. Alındıktan sonra SL, sıfıra geri sayım şeklinde çalışmalı ve danışmanın çalışmasını durdurmalı ve TP alındığında, panelde görüntülenen değerle ilk değerine sıfırlanmalıdır.

Böyle bir sayaç için ayrı bir sınıf yaptım. Giriş parametrelerini ayarlarken OnInit'ten, siparişi kapattıktan sonra panelden giriş alanından birkaç noktadan değiştiği ortaya çıktı (sl ve tp değeri farklı değiştirir). Ayrıca, EA'yı durdurmak için maksimum durdurma kaybı sayısına ulaşılıp ulaşılmadığını izlemek için OnTick()'ten ana işlev çağrılır.

Çok basit bir sınıf gibi görünüyor. Ancak bu küçük sınıfın panelde bulunan diğer nesneleri (giriş alanı, düğmeler) etkilediği ortaya çıktı. Diğer işlevlerden etkilenir. Ve bu kadar küçük on sınıf olduğunda, hangi işlevlerin nesneyi değiştirdiğini veya bazı nesnelerin hangi yöntemlerinin diğer nesnelerin durumunu değiştirebileceğini takip etmek zaten daha zordur.

Anlamak isterim, ancak daha az karışıklık olması için nesnelerin birbirleriyle etkileşimini en iyi nasıl organize edebilirim? Bu konuyla ilgili kod örnekleri, diyagramlar ve iyi bir açıklama içeren iyi makaleler veya kitaplar var mı? Lütfen birisinin iyi tasarlanmış mimarileri nasıl yazacağını öğrenmesine neyin yardımcı olduğunu paylaşın.

 
Bu bir OOP sorunu değil, uzman oluşturmaya yönelik genel yaklaşımın bir sorunudur. Durdurma kayıplarının sayısını tarihe göre saymak gerekir. Genel olarak, bir kişiye kafa verilen şey budur, evrensel bir çözüm yoktur.
 
Vitaly Muzichenko :

Okunabilirlik ve dağınıklık açısından bu tasarımı hiç sevmiyorum.

Tat ve renk .... tüm belirteçler farklıdır.

"Küçük canavar" ile bir tezat oluşturuyordu:

Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum

OOP'a ilginç bir bakış

fxsaber , 2021.01.31 01:09

Küçük canavar.

   static bool VirtualOrderSelect( const TICKET_TYPE Index, const int Select, const int Pool = MODE_TRADES )
  {
     return (VIRTUAL::SelectOrders ? VIRTUAL::SelectOrders. OrderSelect (Index, Select, Pool) :
           #ifdef VIRTUAL_SNAPSHOT_REFRESHTIME
             VIRTUAL::SnapshotPtr ?
             #ifdef __MQL5__ // Выбор по тикету в MT5 - разнообразный набор вариантов.
               (Select == SELECT_BY_TICKET) ? :: OrderSelect (Index, Select, Pool) && VIRTUAL::SnapshotPtr.CopyOrder()
                                            :
             #endif // #ifdef __MQL5__
                                              ((((Index == INT_MIN ) || (Index == INT_MAX )) && (Pool == MODE_TRADES) &&
                                               :: OrderSelect (Index, Select, Pool) &&
                                             #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY
                                               VIRTUAL::SnapshotPtr.CopyOrder( true ))
                                             #else // #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY
                                               VIRTUAL::SnapshotPtr.CopyOrder())
                                             #endif // #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY #else
                                               || VIRTUAL::SnapshotPtr. OrderSelect (Index, Select, Pool))
                                  :
           #endif // #ifdef VIRTUAL_SNAPSHOT_REFRESHTIME
           #ifdef __MQL5__
             #ifdef __MT4ORDERS__
               :: OrderSelect (Index, Select, Pool)
             #else // __MT4ORDERS__
               false
             #endif // __MT4ORDERS__
           #else // __MQL5__
             :: OrderSelect (Index, Select, Pool)
           #endif // __MQL5__
           );
  }

mantıksal işlemler , makrolar aracılığıyla çeşitli ayarları kullanırken kısa ve öz yazmanıza olanak tanır. Ama korkunç tabii.


 
Andrey Khatimlianskii :

Tat ve renk .... tüm belirteçler farklıdır.

Doğru değil. Sadece renkleri farklı ama hepsinin tadı aynı...))))

 
Vitaly Muzichenko :

Okunabilirlik ve dağınıklık açısından bu tasarımı hiç sevmiyorum.

Nedenmiş ?

Tam tersi, iki "if" ile - "veya" operatöründen çok daha kolay.

Açıkçası, önce bir koşulu izlemek ve yürütme durumunda işlevden ayrılmak ve ardından başka bir koşulu kontrol etmek ve yürütme durumunda da bırakmak daha kolaydır. Mantıksal bir "veya" ("ve" ile kolayca karıştırılabilen) aracılığıyla karmaşık bir koşulun sonucu olarak ne olduğunu anlamak ve her iki iade seçeneğini de takip etmek.

Aşağıda "bunun gerekçesinin hata ayıklama olduğunu" okumak oldukça komik, çünkü bu, bu tür kodun çok daha anlaşılır olduğu anlamına geliyor (aksi halde neden hata ayıklamada?).

"Apotheosis", kendisinin nasıl çalıştığını söyleyemediği fxsaber'ın bir ifadesini düşünüyorum, sadece "kod tekrar tekrar test edildi ve çalışıyor" dedi. Bana göre bu olmamalı:

ENUM_ORDER_TYPE_FILLING CSymbolInfo::GetTypeFilling(string strSymbol,ENUM_ORDER_TYPE_FILLING otfFilingType)
{
   const ENUM_SYMBOL_TRADE_EXECUTION steExeMode = ( ENUM_SYMBOL_TRADE_EXECUTION ):: SymbolInfoInteger (strSymbol, SYMBOL_TRADE_EXEMODE );
   const int iFillingMode = ( int ):: SymbolInfoInteger (strSymbol, SYMBOL_FILLING_MODE );

   return ((iFillingMode == 0 || (otfFilingType >= ORDER_FILLING_RETURN ) || ((iFillingMode & (otfFilingType + 1 )) != otfFilingType + 1 )) ?
         (((steExeMode == SYMBOL_TRADE_EXECUTION_EXCHANGE ) || (steExeMode == SYMBOL_TRADE_EXECUTION_INSTANT )) ?
           ORDER_FILLING_RETURN : ((iFillingMode == SYMBOL_FILLING_IOC ) ? ORDER_FILLING_IOC : ORDER_FILLING_FOK )) :
          otfFilingType);
};

Bu kod, otfFilingType siparişinin doldurulup doldurulamayacağını kontrol eder ve strSymbol sembolünde mevcutsa, aksi takdirde doğrudur.


Nasıl çalıştığını tam olarak anlayamıyorum. Ve ben sadece fxsaber'ın otoritesine güveniyorum.

Belki biri açıklar?

Neden: