Başarılı bir otomatik ticaret sistemi oluşturan var mı? Ne önerirsiniz? - sayfa 16

Yeni yorum
 
Aleksei Stepanenko # :
İyi! OOP ile kâr etmeye ne dersiniz? Okuduktan hemen sonra gidecek mi?

OOP size kompakt, temiz, zarif kod yazma yeteneği verir. Çok pahalı olan kod yazmak, değiştirmek ve hata ayıklamak için birkaç kat daha az zaman harcarsınız. Çok daha karmaşık bir ticaret sistemi kurabilir ve çok daha fazla ticaret seçeneği deneyebilirsiniz. Tabii ki, karlı bir bot için fikirleriniz yoksa, hiçbir şey yapmamak daha iyidir. Ek olarak, iyi bir OOP kodunda olasılığı çok daha az olan bir hata durumunda doğrudan kayıp olasılığını unutmayın.

 
Вадим Калашнков # :

OOP size kompakt, temiz ve zarif kod yazma yeteneği verir.

Bu doğru değil.

 
PapaYozh # :

Bu doğru değil.

Eh, görevi özellikle karmaşıklaştıracak şekilde ayarlarsanız, evet, OOP ile kasıtlı komplikasyon için daha fazla fırsat vardır.

Ancak, Puanlı Maymun gibi olmazsanız, OOP kullanan kodun belirgin şekilde daha net, daha yapılandırılmış ve bakımı daha kolay olduğu ortaya çıkar.

 

Evet, OOP'ye karşı değilim arkadaşlar. Onun nesne fikrini beğendim. Ve onu kısmen de olsa, yapılar şeklinde, daha doğrusu bir dizi yapı şeklinde kullanıyorum. Bu, ticarette grafikteki tüm verileri hedeflenen bir şekilde depolamak ve her çubukta döngüleri yönlendirmek için yeterlidir. Ama bence, daha fazlası ve burada gerekli değil. Elbette alışmış olan her şeyi OOP'ta yazabilirsiniz. Ancak prosedürler kadar kârdan uzaktırlar. Bütün soru karlı bir sistemde, varsa, o zaman goto kodu yazabilirsiniz :)

Şubenin konusu, çözüm yolunun üzerinde geziniyor.

 
Aleksei Stepanenko # :

Ve onu kısmen de olsa, yapılar şeklinde, daha doğrusu bir dizi yapı şeklinde kullanıyorum.


Java'da kendi adı bile vardır: POJO (Plain Old Java Object)

;)

 
Georgiy Merts # :

OOP kullanan kod, gözle görülür şekilde daha net, daha yapılandırılmış ve bakımı daha kolaydır.

Bu her zaman böyle değildir ve OOP'ye değil, kodun saflığına, adlandırmaya bağlıdır.

 
Aleksei Stepanenko # :

Evet, OOP'ye karşı değilim arkadaşlar. Onun nesne fikrini beğendim. Ve onu kısmen de olsa, yapılar şeklinde, daha doğrusu bir dizi yapı şeklinde kullanıyorum. Bu, ticarette grafikteki tüm verileri hedeflenen bir şekilde depolamak ve her çubukta döngüleri yönlendirmek için yeterlidir. Ama bence, daha fazlası ve burada gerekli değil. Elbette alışmış olan her şeyi OOP'ta yazabilirsiniz. Ancak prosedürler kadar kârdan uzaktırlar. Bütün soru karlı bir sistemde, varsa, o zaman goto kodu yazabilirsiniz :)

Şubenin konusu, onu çözme yolunun üzerinde geziniyor.

Yapıların kullanımı OOP değildir. OOP kalıplarını kullanmaya başladığınızda OOP'nin tüm faydaları başlar. Kalıtım, tek tonlar, nesne fabrikaları, arabirim sınıfları vb. Ayrıca ekibinizde 2'den fazla kişi olduğunda OOP'suz yapamazsınız. Örneğin:

 enum Direction
{
  BUY,
  SELL,
  NO_SIGNAL
};

class Signal
{
public :
  Signal() {}
 ~Signal() {}

   virtual Direction check_signal() { return NO_SIGNAL; }
};

Ayrıca, ya kendiniz ya da 3 kişiye sinyal yazması için dağıtarak, örneğin 3 farklı gösterge için:

 class RSISignal : public Signal
{
public :
  RSISignal() {}
 ~RSISignal() {}

  Direction check_signal() 
  { 
    Direction result;
     // Checking signal with RSI
     return result;
  }
};

Sinyalin kullanıldığı yerde yapılması yeterlidir: 

Signal* signal;

switch signal_type
{
   case RSI : signal = new RSI;
   case CCI : signal = new CCI;
   case MA  : signal = new MA;
};

if (signal.check_signal())
.....

Bir kıdemli olarak, işlev organlarının uygulamalarından tamamen soyutlanmışsınız. Sizin için uygulama önemli değil ve hangi göstergenin kullanıldığı. Sadece check_signal kullanın ve bu kadar. Bu örnekte, bir işlev kullanılmıştır. Ve sınıfta çok sayıda işlev varsa, uygulamanın yapılandırmaya veya başka bir seçeneğe bağlı olduğu herhangi bir yere anahtar eklemeniz gerekecektir. Ek olarak, bir veritabanı veya bir dizi yerde bir günlük dosyası kullanıyorsanız, global bir değişken oluşturmanız ve durumunu tüm aşamalarda (dosya veya veritabanı açık olsun, vb.) kontrol etmeniz gerekir. Bu amaçlar için bir singleton kullanırsanız - dosya/veritabanı günlük nesnesini kullandığınız her yerde - veritabanını/dosyayı yeniden açabileceğiniz, durum bayraklarını kullanabileceğiniz, arabelleğe alınmış bir nesne oluşturabileceğiniz nesnenin bir kopyasının her zaman oluşturulacağından emin olabilirsiniz. her çıktıda diske yazmamak için oturum açın vb. 10.000 satırdan fazla kodunuz varsa, işlevsellik geliştirici için yaşayan bir cehenneme dönüşür. Ve yarım yıl içinde, kodunuzun yarısını unuttuğunuzda, onu yeniden anlamak cehenneme dönecek. Ek olarak, iyi bir OOP tasarımı, bir yerde bir şey yaparsanız her şeyin cehenneme gideceğinden korkmadan yeni işlevler eklemenize veya eskisini düzenlemenize olanak tanır.

 
Valeriy Yastremskiy # :
Ve 5k ve 4k'de OOP'deki fark nedir? aydınlatın. Değişim ortamının ayarlarındaki fark açıktır. Eh, çubuklar sondan itibaren numaralandırılmıştır. Dilde bariz bir fark görmüyorum.

Asgari olarak, nihayet bir dizi teleskop işlevinden kurtulduk ve en önemlisi, çok sayıda faydalı sınıfla standart bir kütüphane eklendi.

 
OOP bilgisi bir şekilde hayalimi 100 doların 200'ünü kazanmaya yaklaştıracak mı?
 
Вадим Калашнков # :

Asgari olarak, nihayet bir dizi teleskop işlevinden kurtulduk ve en önemlisi, çok sayıda faydalı sınıfla standart bir kütüphane eklendi.

özellikle Object.mqh

başarısız alıntı yaptığın kitaplardan.. harika desen :-)

Konu, OOP kursuna ne kadar hakim olduğunuz ve onu nasıl savunacağınızı öğrendiğinizle ilgili değil.. bence, çok kötü bir şekilde ustalaştınız.

genel olarak, ders kitaplarını topla ve yarın okula yürü

1...91011121314151617181920212223...42
Yeni yorum