Höyükte OOP hakkında konuşun - sayfa 6

Yeni yorum
 
George Merts :

Bu (ve alt çizgi ile başlayan her şey) korumalı bir sınıf özelliğidir.

Böylece bir bütün halinde birleştirilirler!

Yalnızca bir işlev vardır - Karşılaştırma(), ancak içinde iletilen anahtarla karşılaştırmak gerekir. Buna göre, belirli korunan işlevlerden biri seçilir. Bu nedenle, kullanıcının erişemeyeceği şekilde korunurlar (korunurlar) - bunlara yalnızca, alt çizginin gösterdiği gibi Karşılaştır () üzerinden erişilir.

Bu aynı zamanda kod tasarım kurallarından biridir - alt çizgi ile başlayan bir işlevin kullanıcılar tarafından çağrılması amaçlanmamıştır, yalnızca belirli sınıf içi görevlere hizmet eder. Buna erişim sınırlıdır.

Peki, neden böyle sirk hileleri, klasiklerle her şey çok daha kolay yapılırken. İç içe değişkenleri ve işlevleri gizlemek ve bunlara erişilmesini önlemek için sarmalayıcı işlevleri ve küme parantezlerini kullanın; sorun olmaz. Bu koruyucularla sadece kendinizi ve başkalarını karıştıracaksınız ...

 
Andrei :

Peki, neden böyle sirk hileleri, klasiklerle her şey çok daha kolay yapılırken. İç içe değişkenleri ve işlevleri gizlemek ve bunlara erişilmesini önlemek için sarmalayıcı işlevleri ve küme parantezlerini kullanın; sorun olmaz. Bu koruyucularla sadece kendinizi ve başkalarını karıştıracaksınız ...

Anlamıyorum... Korumalı, bir işlev için erişim değiştiricisidir. Yani, yalnızca bir sınıf işlevinden veya onun soyundan gelen erişim mümkün olan korumalı bir işlev kullanılır. Artı benim için alt çizgi karakteri, kişisel olarak, kullanırken dikkate alınması gereken bazı örtük varsayımlar olduğu anlamına gelir.

Dennis Kirichenko haklı olarak not etti - her şeyi tek bir Karşılaştırma() işleviyle yazmak mümkün olurdu. Ama o zaman iki düzine ekranda ortaya çıkacaktı, Onu araştırmak gerçekçi olmayacaktı, onu değiştirmek şimdi olduğundan daha zor olurdu.

Karşılaştırma() işlevinde yalnızca tuş seçiciyi bıraktım ve belirli tuşlarla karşılaştıran kodu ayrı işlevlere böldüm. Bu işlevler son derece bağlama özel olduklarından, yalnızca başka bir sınıf işlevinden veya soyundan erişilebilecekleri şekilde sınıfın korumalı bölümünde bildirilirler. Ve bu işlevlerin başka bir işlevin içinde belirli bir dar görevi gerçekleştirmek üzere tasarlandığını kendime hatırlatmak için onlara bir alt çizgi ile başlıyorum. Gelecekte böyle bir fonksiyonla karşılaşırsam, onu çağırırken dikkate alınması gereken örtük varsayımlar olduğunu hemen göreceğim.

Görünüşe göre siz ("sizinle devam edelim") erişim değiştiricilerin ne olduğunu ve neden gerekli olduklarını tam olarak anlamıyorsunuz.

 
George Merts :

Anlamıyorum... Korumalı, bir işlev için erişim değiştiricisidir. Yani, yalnızca bir sınıf işlevinden veya onun soyundan gelen erişim mümkün olan korumalı bir işlev kullanılır. Artı benim için alt çizgi karakteri, kişisel olarak, kullanırken dikkate alınması gereken bazı örtük varsayımlar olduğu anlamına gelir.

Bir işleve erişimi, herhangi bir OOP olmadan klasik yollarla kısıtlayabilirsiniz.
 
Artyom Trishkin :

Eh, kişisel hakaretler olmadan ...

Lütfen ipliği selden temizleyin, sadece eğitim mesajları bırakın Alexey Volchanskiy
 
Andrei :
Bir işleve erişimi, herhangi bir OOP olmadan klasik yollarla kısıtlayabilirsiniz.

Nasıl ?

İşte görev - gelecekte, kodu değiştirirken, belirli bir işlevi "herhangi bir yerde" almak ve kullanmak imkansız olacak şekilde yapmak. Bunu, kamu korumalı-özel değiştiricileri kullanarak sınıf alanına erişimi kısıtlamayan OOP olmadan nasıl yapılır?

 

Görünüşe göre, static ve const (bu OOP değildir) gerekli değildir.

OOP'ye gelince, geniş pratik uygulaması olan (hiç de soyut olmayan) bir sonraki işlevin prosedürel tarzda nasıl görüneceği çok ilginç?

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

Sipariş numaralandırma döngüsünün organizasyonu

fxsaber , 2017.10.18 12:29

Tarihe başvurmadan sürüm.
 struct HISTORY_UNIT
{
   long Ticket;
   int Type;
   double Lots; 
    
  HISTORY_UNIT( void ) : Ticket(:: OrderTicket ()), Type(:: OrderType ()), Lots(:: OrderLots ())
  {
  }

   bool operator !=( const HISTORY_UNIT &Unit ) const
  {
     return (( this .Ticket != Unit.Ticket) || ( this .Type != Unit.Type) || ( this .Lots != Unit.Lots));
  }
      
   bool IsChange( void )
  {
     const HISTORY_UNIT Tmp;
     const bool Res = ( this != Tmp);
    
     if (Res)
       this = Tmp;
      
     return (Res);
  }
};

// Возвращает true только в случае, если с последнего вызова произошли торговые изменения
bool IsChange( void )
{
   static HISTORY_UNIT History[];  

   const int Total = OrdersTotal ();  
   bool Res = ( ArraySize (History) != Total);

   for ( int i = 0 , j = Res ? ArrayResize (History, 0 , Total) : 0 ; i < Total; i++)      
     if ( OrderSelect (i, SELECT_BY_POS ))
    {
       if (Res || (Res = History[j].IsChange()))
         ArrayResize (History, j + 1 , Total);
      
      j++;
    }
  
   return (Res);
}

Bu sürüm özellikle bir VPS'deki MT5 için geçerlidir, çünkü. MT5, History ile çok yavaş çalışır ve hesaplama açısından pahalıdır.

Açıkçası, herhangi bir OOP prosedürel bir tarzda yeniden yazılabilir. Ama pratikle ilgileniyorum. Bu nedenle, OOP'nin minimumda kullanıldığı yukarıdaki küçük kodu aldım.

Peki bu örnekte OOP ile karşılaştırıldığında prosedürel stil ne kadar daha güzel/daha uygun/daha okunabilir/daha doğru? Pekala, birkaç sayfayı asılsızlaştırmamak için, ancak prosedürel kısa kaynak kodlarını OOP ile karşılaştırmak için. OOP muhaliflerinden bir ana sınıf göstermelerini istiyorum. Bu korkunç bir MT5 değil, eski güzel bir MT4.

 
Vladimir Pastushak :
Lütfen ipliği selden temizleyin, sadece eğitim mesajları bırakın Alexey Volchanskiy

zaten geç))) dahası, sadece dışarı çıkmak için zaman bulacağım, aniden çok meşgul olduğum ortaya çıktı

Biraz ders çalışayım, belki videolar çıkar

 
Vladimir Pastushak :
Lütfen ipliği selden temizleyin, sadece eğitim mesajları bırakın Alexey Volchanskiy

Vladimir, bunca yıldır öğrenmediysen bence başlamak için çok geç ;)

 
fxsaber :

Görünüşe göre, static ve const (bu OOP değildir) gerekli değildir.

OOP'ye gelince, geniş pratik uygulaması olan (hiç de soyut olmayan) bir sonraki işlevin prosedürel tarzda nasıl görüneceği çok ilginç?

Açıkçası, herhangi bir OOP prosedürel bir tarzda yeniden yazılabilir. Ama pratikle ilgileniyorum. Bu nedenle, OOP'nin minimumda kullanıldığı yukarıdaki küçük kodu aldım.

Peki bu örnekte OOP ile karşılaştırıldığında prosedürel stil ne kadar daha güzel/daha uygun/daha okunabilir/daha doğru? Pekala, birkaç sayfayı asılsızlaştırmamak için, ancak prosedürel kısa kaynak kodlarını OOP ile karşılaştırmak için. OOP muhaliflerinden bir ana sınıf göstermelerini istiyorum. Bu korkunç bir MT5 değil, eski güzel bir MT4.

Bu basit örnekte bile çok sofistikesin. OOP'yi yeniden yazmak, başka birinin kodunu anlamaktan her zaman daha kolaydır .... Ne yapmak istiyorsun, en azından bana basit insan dilinde söyle? Siparişlerin geçmişindeki değişikliğin ne olduğunu öğrenin ?
 
Vasiliy Sokolov :

Vladimir, bunca yıldır öğrenmediysen bence başlamak için çok geç ;)


Ve kim olduklarını ve ne öğrenmediklerini açıklayabilir misiniz? Moderatörler temizlemeyi veya başka bir şeyi öğrenmediler)

Not: Bu arada, tüm şubede, her zamanki gibi, herhangi bir konuyu ele almak için tek bir dilek görmedim, her zamanki kavga. Bu yüzden OOP cihazında sıfırdan YouTube'da videolar kaydetmeye karar verdim, en azından bir faydası olacak. Her neyse, bir süre sonra dal, branch_sump'ta olacaktır.

12345678910111213...23
Yeni yorum
Neden: