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 karşıtlarından bir ana sınıf göstermelerini istiyorum . Bu korkunç bir MT5 değil, eski güzel bir MT4.
OOP'a karşı değilim. Sadece bir tanesi kalitesiz ve şifreli kod. (OOP rakibi değilim. Sadece kalitesiz ve şifreli kodlardan biriyim)
#define MC 200#define MYOWNSELECT OrderSelect#define MYOWNTICKET OrderTicket#define MYOWNOTIPE OrderType#define MYOWNOLOT OrderLots// Возвращает true только в случае, если с последнего вызова произошли торговые измененияbool IsChanged_NoOOP_Cryptic_aka_fxsaber( void )
{
staticint ptot= 0 ,tickets[MC],types[MC];
staticdouble lots[MC];
int total;
bool res=ptot!=(total=:: OrdersTotal ());
for ( int i= 0 ,j= 0 ; i<total; i++)
if (MYOWNSELECT(i, SELECT_BY_POS ))
{
if (res=(res || (tickets[j]!=MYOWNTICKET() || types[j]!=MYOWNOTIPE() || lots[j]!=MYOWNOLOT())))
{
tickets[j]=MYOWNTICKET();
types[j]=MYOWNOTIPE();
lots[j]=MYOWNOLOT();
}
j++;
}
ptot=total;
return (res);
}
OOP'a karşı değilim. Sadece bir tanesi kalitesiz ve şifreli kod. (OOP rakibi değilim. Sadece kalitesiz ve şifreli kodlardan biriyim)
Prosedürel kod için teşekkürler! biraz ayarlandı
#define MC 200#define MYOWNSELECT OrderSelect#define MYOWNTICKET OrderTicket#define MYOWNOTIPE OrderType#define MYOWNOLOT OrderLots// Возвращает true только в случае, если с последнего вызова произошли торговые измененияbool IsChanged_NoOOP_Cryptic_aka_fxsaber( void )
{
staticint ptot= 0 ,tickets[MC],types[MC];
staticdouble lots[MC];
int total;
bool res=ptot!=(total=:: OrdersTotal ());
int j = 0 ;for ( int i= 0 ; i<total; i++)
if (MYOWNSELECT(i, SELECT_BY_POS ))
{
if (res=(res || (tickets[j]!=MYOWNTICKET() || types[j]!=MYOWNOTIPE() || lots[j]!=MYOWNOLOT())))
{
tickets[j]=MYOWNTICKET();
types[j]=MYOWNOTIPE();
lots[j]=MYOWNOLOT();
}
j++;
}
ptot=j;return (res);
}
Çözümlerin ( OOP çözümü ) her birinin artıları ve eksileri artık ilk elden görülebilir. Herkes kendi seçimini yapar ve farklı bir bakış açısını dayatmak aptalcadır.
Kompaktlık ile netlik için başka bir şeyi düzeltebilirsiniz
#define MC 200#define MYOWNSELECT OrderSelectbool IsChanged_NoOOP_Cryptic_aka_fxsaber( void )
{
staticint ptot= 0 ;
staticstring History_Unit[MC];
string Order_Data;
int total;
bool res=ptot!=(total=:: OrdersTotal ());
int j = 0 , i = total;
while (i-- > 0 )
if (MYOWNSELECT(i, SELECT_BY_POS ))
{
Order_Data = StringFormat ( "%u|%u|%.2f" , OrderTicket (), OrderType (), OrderLots ());
if (res=(res || History_Unit[j]!=Order_Data)) History_Unit[j]=Order_Data;
j++;
}
ptot=j;
return (res);
}
Yapıları / dizileri / dizeleri karşılaştırırken performansın ne kadar önemli ölçüde değişeceğini elbette görebilirsiniz. Ancak bu, bağlamdan çıkarılan bir görev parçası, bu yüzden hiçbir anlam ifade etmiyor.
Kompaktlık ile netlik için başka bir şeyi düzeltebilirsiniz
Yapıları / dizileri / dizeleri karşılaştırırken performansın ne kadar önemli ölçüde değişeceğini elbette görebilirsiniz. Ancak bu, bağlamdan çıkarılan bir görev parçası, bu yüzden hiçbir anlam ifade etmiyor.
Kompaktlık ile netlik için başka bir şeyi düzeltebilirsiniz
Yapıları / dizileri / dizeleri karşılaştırırken performansın ne kadar önemli ölçüde değişeceğini elbette görebilirsiniz. Ancak bu, bağlamdan çıkarılan bir görev parçası, bu yüzden hiçbir anlam ifade etmiyor.
PS Ve ben OOP'ye karşı değilim. çıkar için
DEFINE kullanmak bir şakaydı ;-) Yaklaşımınız çok yavaş olacak. (DEFINE kullanımı şakaydı ;-) Yaklaşımınız çok yavaş olacaktır.)
Çözümlerin ( OOP çözümü ) her birinin artıları ve eksileri artık ilk elden görülebilir. Herkes kendi seçimini yapar ve farklı bir bakış açısını dayatmak aptalcadır.
Empoze etmek gerekli değildir, ancak prosedürel biçimde kodun mantığının gereksiz hareketler olmadan zaten görülebildiği ve işe alınan bir programcının her hareketinin işverene paraya mal olduğu açıktır. Bu nedenle, işveren aptal değilse, OOP'ye düşmeyecektir, ancak diğer yandan kurnaz bir programcı, avantajından yararlanarak ondan daha fazla kesinti yapmak için OOP'nin ilericiliği hakkında ona erişte asabilir. okuma yazma bilmeme. :)
MQL5.com web sitesine giriş yapmak için çerezlerin kullanımına izin vermelisiniz.
Lütfen tarayıcınızda gerekli ayarı etkinleştirin, aksi takdirde giriş yapamazsınız.
Hesabınıza giriş yaptınız. İki faktörlü kimlik doğrulama devre dışı bırakıldı. Yeniden kurup yeni bir QR kodu tarayın veya iki faktörlü kimlik doğrulama devre dışıyken devam edin.
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 karşıtlarından bir ana sınıf göstermelerini istiyorum . Bu korkunç bir MT5 değil, eski güzel bir MT4.
OOP'a karşı değilim. Sadece bir tanesi kalitesiz ve şifreli kod. (OOP rakibi değilim. Sadece kalitesiz ve şifreli kodlardan biriyim)
Çok üzgünüm, hangi dil bağlamında böyle bir sonuca varıyorsunuz? :-)
Denis, forum bağlamında)))))))))
OOP'a karşı değilim. Sadece bir tanesi kalitesiz ve şifreli kod. (OOP rakibi değilim. Sadece kalitesiz ve şifreli kodlardan biriyim)
Prosedürel kod için teşekkürler! biraz ayarlandı
Çözümlerin ( OOP çözümü ) her birinin artıları ve eksileri artık ilk elden görülebilir. Herkes kendi seçimini yapar ve farklı bir bakış açısını dayatmak aptalcadır.
Çok üzgünüm, hangi dil bağlamında böyle bir sonuca varıyorsunuz? :-)
Tabii ki faydaları hakkında.
Prosedürel kod için teşekkürler! biraz ayarlandı
Kompaktlık ile netlik için başka bir şeyi düzeltebilirsiniz
Yapıları / dizileri / dizeleri karşılaştırırken performansın ne kadar önemli ölçüde değişeceğini elbette görebilirsiniz. Ancak bu, bağlamdan çıkarılan bir görev parçası, bu yüzden hiçbir anlam ifade etmiyor.
PS Ve ben OOP'ye karşı değilim. çıkar için
Kompaktlık ile netlik için başka bir şeyi düzeltebilirsiniz
Yapıları / dizileri / dizeleri karşılaştırırken performansın ne kadar önemli ölçüde değişeceğini elbette görebilirsiniz. Ancak bu, bağlamdan çıkarılan bir görev parçası, bu yüzden hiçbir anlam ifade etmiyor.
PS Ve ben OOP'ye karşı değilim. çıkar için
çökecek!
Kompaktlık ile netlik için başka bir şeyi düzeltebilirsiniz
Yapıları / dizileri / dizeleri karşılaştırırken performansın ne kadar önemli ölçüde değişeceğini elbette görebilirsiniz. Ancak bu, bağlamdan çıkarılan bir görev parçası, bu yüzden hiçbir anlam ifade etmiyor.
PS Ve ben OOP'ye karşı değilim. çıkar için
DEFINE kullanmak bir şakaydı ;-) Yaklaşımınız çok yavaş olacak. (DEFINE kullanımı şakaydı ;-) Yaklaşımınız çok yavaş olacaktır.)
DEFINE kullanmak bir şakaydı ;-) Yaklaşımınız çok yavaş olacak. (DEFINE kullanımı şakaydı ;-) Yaklaşımınız çok yavaş olacaktır.)
Elbette. Bu da şaka - bu bir kod güzellik geçit töreni, değil mi?
Bu aynı zamanda bir şakadır - kompaktlık ve görünürlük lehine bir numara
---
çökecek!
Bu, belirli bir uygulamanın, özel bir durumun ölçümüdür.
Elbette. Bu da şaka - bu bir kod güzellik geçit töreni, değil mi?
Evet gerçekten güzel.
(Maalesef şakayı henüz yakalayamıyorum ;-)
Evet, gerçekten güzel. Ne yazık ki, şakayı yakalayamıyorum ;-)
Çözümlerin ( OOP çözümü ) her birinin artıları ve eksileri artık ilk elden görülebilir. Herkes kendi seçimini yapar ve farklı bir bakış açısını dayatmak aptalcadır.
Empoze etmek gerekli değildir, ancak prosedürel biçimde kodun mantığının gereksiz hareketler olmadan zaten görülebildiği ve işe alınan bir programcının her hareketinin işverene paraya mal olduğu açıktır. Bu nedenle, işveren aptal değilse, OOP'ye düşmeyecektir, ancak diğer yandan kurnaz bir programcı, avantajından yararlanarak ondan daha fazla kesinti yapmak için OOP'nin ilericiliği hakkında ona erişte asabilir. okuma yazma bilmeme. :)