Ve sınıfları kullanmazsanız, sürekli SymbolInfoDouble (_Symbol,MODE_BID) gibi bir şey yazarak eziyet çekeceksiniz. Her seferinde böyle bir dans - ve parantezler ve altı çizili ve büyük harfe basıp basmayı (ve sonra başka bir yere bakmadan, tüm satırı büyük harflerle yazıp yeniden yazın) veya vardiyayı basılı tutmayı bilmiyorsunuz. En azından bu OOP'de faydalıdır. En azından tüm bu işlevler için sınıflar yaparsanız, evet - çok büyükler. Kendin için yazarsan, sorun değil. Emirlerle çalışmaya gelince, çok sık kullanılan fonksiyonlar yoktur, kütüphaneye sadece birkaç fonksiyon ekleyebilirsiniz. Ancak genel olarak henüz ideal bir yaklaşım yok.
Pekala, tam olarak ve çok değilmiş gibi, oldukça terbiyeli bir şekilde sipariş vermek için eylemler gerçekleştirmeniz gerektiğini söyleyebilirim, işte açabilen / kapatabilen / durdurma kaybını ayarlayabilen / ve ardından durumunu yayınlayabilen bir sınıf için vizyonum: sipariş
class CConstVolume
{
protected :
staticconstdouble VolumeMAX;
staticconstdouble VolumeMIN;
staticconstdouble VolumeSTEP;
staticconstdouble ZerroPrice;
staticconstint VolumeDIGITS;
staticint GetDigitsInVolumeStep(); };
//___________________________________________________________________________staticint CConstVolume::GetDigitsInVolumeStep()
{ int result = 0 ;
long i = 10000000 , k = long (:: SymbolInfoDouble ( _Symbol , SYMBOL_VOLUME_STEP ) / 0.0000001 );
while (result < 7 && k % i > 0 )
{ i /= 10 ;
result++; }
return (result); }
//____________________________________________________________________staticconstdouble CConstVolume::VolumeMAX = :: SymbolInfoDouble ( _Symbol , SYMBOL_VOLUME_MAX );
//____________________________________________________________________staticconstdouble CConstVolume::VolumeMIN = :: SymbolInfoDouble ( _Symbol , SYMBOL_VOLUME_MIN );
//____________________________________________________________________staticconstdouble CConstVolume::VolumeSTEP = :: SymbolInfoDouble ( _Symbol , SYMBOL_VOLUME_STEP );
staticconstdouble CConstVolume::ZerroPrice = :: NormalizeDouble ( 0.0 , _Digits );
//____________________________________________________________________staticconstint CConstVolume::VolumeDIGITS = CConstVolume::GetDigitsInVolumeStep();
//____________________________________________________________________//+------------------------------------------------------------------+//| class COrder |//+------------------------------------------------------------------+class COrder : private CConstVolume
{
private :
SOrderInfo m_info; //структура для инициализации класса, и хранения информации о ордере, тип, цена отркытия, лот, и состояние ордера
CError error; //класс с описание ошибок на 2-х языкахint sl_error_count; //счетчик ошибок установки стоплосса/тейкаbool m_needstoploss; //флаг для установки стоплосса, сбросим когда все ОКbool CheckMarginRequirements();
bool ServerDisable();
intOrdersend ();
int CheckOrderByMagicnumber( int magic_); //метод нужен для поиска открытого ордера по магику, использую в конструктореvoid SetStoploss();
void NULLOrder() { ZeroMemory (m_info); m_info.cmd = - 1 ; m_info.status = ErrorOrder; m_needstoploss = false ; }
void PrintError( string func) { Print (func); error. GetLastError (); }
public :
COrder():m_needstoploss( false ) { NULLOrder(); }
COrder(SOrderInfo &ordersetting);
SOrderInfo GetOrderInfo();
bool Orderclose();};
//________________________________
ve tek bir karakterde kullanmak için - özellikle statik bir sınıf kullanımı olduğunu unutmayın.
genel olarak, her şey amaçlandığı gibi çalışıyor .... ama yukarıda yazdığım gibi hoşuma gitmiyor, bence hantal ve gereksiz bir şey yok
Ve sınıfları kullanmazsanız, o zaman sürekli SymbolInfoDouble(_Symbol, SYMBOL_BID ) gibi bir şeyler yazmaktan zarar görürsünüz. Her seferinde böyle bir dans...
Prosedürel stil çerçevesinde kalırken, bu işlevler için daha kullanışlı ve özlü sarmalayıcılar yapabilirsiniz. Özellikle en son yapılarda ad alanının nihayet eklendiği gerçeği göz önüne alındığında, bu genellikle bir gaftır. Önceden, statik yöntemler şeklinde uygulamak zorundaydınız, şimdi her şey büyük ölçüde basitleştirildi:
Prosedürel stil çerçevesinde kalırken, bu işlevler için daha kullanışlı ve özlü sarmalayıcılar yapabilirsiniz. Özellikle en son yapılarda ad alanının nihayet eklendiği gerçeği göz önüne alındığında, bu genellikle bir gaftır. Önceden, statik yöntemler şeklinde uygulamak zorundaydınız, şimdi her şey büyük ölçüde basitleştirildi:
Ve belirli sınırlar içinde kalmak temelde önemli mi? Sınırlar içinde kalmak önemliyse, işlevler yazabilirsiniz.
Pekala, tam olarak ve çok fazla değilse, oldukça terbiyeli bir şekilde sipariş vermek için eylemler gerçekleştirmeniz gerektiğini söyleyebilirim, işte açabilen / kapatabilen / durdurma kaybını ayarlayabilen / ve ardından durumunu yayınlayabilen bir sınıf için vizyonum sipariş
ve tek bir karakterde kullanmak için - özellikle statik bir sınıf kullanımı olduğunu unutmayın.
genel olarak, her şey amaçlandığı gibi çalışıyor .... ama yukarıda yazdığım gibi hoşuma gitmiyor, bence hantal ve gereksiz bir şey yok
Evet, işte sürekli ortaya çıkan ve net bir cevabı olmayan bir soru daha. Kendi sınıfınızı miras almak gerektiğinde - ki bunu yapmak daha iyidir, onu miras alın veya sınıfınızın yeni bir genişletilmiş versiyonunu yazın.
Prosedürel stil çerçevesinde kalırken, bu işlevler için daha kullanışlı ve özlü sarmalayıcılar yapabilirsiniz. Özellikle en son yapılarda ad alanının nihayet eklendiği gerçeği göz önüne alındığında, bu genellikle bir gaftır. Önceden, statik yöntemler şeklinde uygulamak zorundaydınız, şimdi her şey büyük ölçüde basitleştirildi:
Kısa bir kaydınız yok, kontrol yoksa, olduğu gibi yazmak daha kolaydır:
özlü bir kaydınız yok, çek yoksa, olduğu gibi yazmak daha kolaydır:
SymbolInfoDouble gibi birçok fonksiyon vardır. Herkes için kısa isimler bulmaktan bıktınız. Bunları sınıflarda toplayarak, isimlerin benzersizliği hakkında hiç endişelenmenize gerek yok.
TS'yi sadece Tester için yazıyorum. Günlükler, hata işleyiciler ve diğer tortular eksik. Kod, OOP aracılığıyla yapılırsa (ancak temelde değil) düzenleme için çok özlü, anlaşılır ve dövülebilir olduğu ortaya çıkıyor. KB'de bir örnek yayınladım. Bonus - hızlı optimizasyon .
Ana şey, Test Cihazı için bağımsız bloklara yayılmasıdır. Ticaret sinyallerinin oluşumu - bir blok. Sinyal ticareti farklıdır.
Gerçeğe çeviri her zaman aynı hareketlerin birkaçında yapılır. Araç, kodu düzenlemeden sanal bir ortama yerleştirilir. Bir ortamda aynı anda birkaç TS'ye veya her bir TS'ye kendi başına sahip olabilirsiniz, o zaman OOP özellikle uygun hale gelir. Ardından, işlemleri / siparişleri sanal makineden gerçek makineye kopyalayan bir fotokopi makinesi alınır (Market'te birçoğu vardır, bu nedenle insanlar fotokopi mantığına geçerler).
Bu şema ile bir TS yazmak hızlı ve anlaşılır bir iştir. Gerçeğe çeviri (ve aslında bu nadirdir) her zaman eşit, hızlı ve net bir şekilde yapılır.
Kısa bir kaydınız yok, kontrol yoksa, olduğu gibi yazmak daha kolaydır:
Bu böyle yapılmaz. En azından hem Bid() hem de Ask()'ı aramanız gerekir. Size sadece bir değişken gibi görünüyor ve gerçekte değişmese de değerinin değişmediği izlenimini veriyor.
Alexey Navoykov : Sınıfı esnek ve evrensel yaparak, sembolün adını yapıcıya iletmenizi engelleyen nedir? Portföy ticareti olasılığını temel olarak düşünüyor musunuz?
Çoğunlukla tek karakterli Uzman Danışmanların yazılmasına ve çoğu durumda bir karakterin aktarılmasının ekstra (ve yorucu)) bir eylem olacağı gerçeğine müdahale eder. Başka bir şey de, grafiğin sembolünün varsayılan olarak otomatik olarak seçilmesini ve gerekirse sembolü geçici olarak yeniden tanımlayabilmenizi sağlamaktır. Ancak yine, daha iyi olan soru ortaya çıkıyor - sınıfın bir örneğini kullanmak ve gerekirse sembolü yeniden tanımlamak veya her sembol için kendi örneğini oluşturmak.
Ve sınıfları kullanmazsanız, sürekli SymbolInfoDouble (_Symbol,MODE_BID) gibi bir şey yazarak eziyet çekeceksiniz. Her seferinde böyle bir dans - ve parantezler ve altı çizili ve büyük harfe basıp basmayı (ve sonra başka bir yere bakmadan, tüm satırı büyük harflerle yazıp yeniden yazın) veya vardiyayı basılı tutmayı bilmiyorsunuz. En azından bu OOP'de faydalıdır. En azından tüm bu işlevler için sınıflar yaparsanız, evet - çok büyükler. Kendin için yazarsan, sorun değil. Emirlerle çalışmaya gelince, çok sık kullanılan fonksiyonlar yoktur, kütüphaneye sadece birkaç fonksiyon ekleyebilirsiniz. Ancak genel olarak henüz ideal bir yaklaşım yok.
Pekala, tam olarak ve çok değilmiş gibi, oldukça terbiyeli bir şekilde sipariş vermek için eylemler gerçekleştirmeniz gerektiğini söyleyebilirim, işte açabilen / kapatabilen / durdurma kaybını ayarlayabilen / ve ardından durumunu yayınlayabilen bir sınıf için vizyonum: sipariş
ve tek bir karakterde kullanmak için - özellikle statik bir sınıf kullanımı olduğunu unutmayın.
genel olarak, her şey amaçlandığı gibi çalışıyor .... ama yukarıda yazdığım gibi hoşuma gitmiyor, bence hantal ve gereksiz bir şey yok
Ve sınıfları kullanmazsanız, o zaman sürekli SymbolInfoDouble(_Symbol, SYMBOL_BID ) gibi bir şeyler yazmaktan zarar görürsünüz. Her seferinde böyle bir dans...
Prosedürel stil çerçevesinde kalırken, bu işlevler için daha kullanışlı ve özlü sarmalayıcılar yapabilirsiniz. Özellikle en son yapılarda ad alanının nihayet eklendiği gerçeği göz önüne alındığında, bu genellikle bir gaftır. Önceden, statik yöntemler şeklinde uygulamak zorundaydınız, şimdi her şey büyük ölçüde basitleştirildi:
Prosedürel stil çerçevesinde kalırken, bu işlevler için daha kullanışlı ve özlü sarmalayıcılar yapabilirsiniz. Özellikle en son yapılarda ad alanının nihayet eklendiği gerçeği göz önüne alındığında, bu genellikle bir gaftır. Önceden, statik yöntemler şeklinde uygulamak zorundaydınız, şimdi her şey büyük ölçüde basitleştirildi:
Ve belirli sınırlar içinde kalmak temelde önemli mi? Sınırlar içinde kalmak önemliyse, işlevler yazabilirsiniz.
Pekala, tam olarak ve çok fazla değilse, oldukça terbiyeli bir şekilde sipariş vermek için eylemler gerçekleştirmeniz gerektiğini söyleyebilirim, işte açabilen / kapatabilen / durdurma kaybını ayarlayabilen / ve ardından durumunu yayınlayabilen bir sınıf için vizyonum sipariş
ve tek bir karakterde kullanmak için - özellikle statik bir sınıf kullanımı olduğunu unutmayın.
genel olarak, her şey amaçlandığı gibi çalışıyor .... ama yukarıda yazdığım gibi hoşuma gitmiyor, bence hantal ve gereksiz bir şey yok
Evet, işte sürekli ortaya çıkan ve net bir cevabı olmayan bir soru daha. Kendi sınıfınızı miras almak gerektiğinde - ki bunu yapmak daha iyidir, onu miras alın veya sınıfınızın yeni bir genişletilmiş versiyonunu yazın.
Prosedürel stil çerçevesinde kalırken, bu işlevler için daha kullanışlı ve özlü sarmalayıcılar yapabilirsiniz. Özellikle en son yapılarda ad alanının nihayet eklendiği gerçeği göz önüne alındığında, bu genellikle bir gaftır. Önceden, statik yöntemler şeklinde uygulamak zorundaydınız, şimdi her şey büyük ölçüde basitleştirildi:
Kısa bir kaydınız yok, kontrol yoksa, olduğu gibi yazmak daha kolaydır:
ve tek bir karakterde kullanmak için - özellikle statik bir sınıf kullanımı olduğunu unutmayın.
özlü bir kaydınız yok, çek yoksa, olduğu gibi yazmak daha kolaydır:
SymbolInfoDouble gibi birçok fonksiyon vardır. Herkes için kısa isimler bulmaktan bıktınız. Bunları sınıflarda toplayarak, isimlerin benzersizliği hakkında hiç endişelenmenize gerek yok.
Sorun yaşamadığım aşağıdaki şemaya sahibim.
Kısa bir kaydınız yok, kontrol yoksa, olduğu gibi yazmak daha kolaydır:
Sınıfı esnek ve evrensel yaparak, sembolün adını yapıcıya iletmenizi engelleyen nedir? Portföy ticareti olasılığını temel olarak düşünüyor musunuz?
Çoğunlukla tek karakterli Uzman Danışmanların yazılmasına ve çoğu durumda bir karakterin aktarılmasının ekstra (ve yorucu)) bir eylem olacağı gerçeğine müdahale eder. Başka bir şey de, grafiğin sembolünün varsayılan olarak otomatik olarak seçilmesini ve gerekirse sembolü geçici olarak yeniden tanımlayabilmenizi sağlamaktır. Ancak yine, daha iyi olan soru ortaya çıkıyor - sınıfın bir örneğini kullanmak ve gerekirse sembolü yeniden tanımlamak veya her sembol için kendi örneğini oluşturmak.