Parler de l'OLP dans le salon - page 9

Nouveau commentaire
 
fxsaber:

Apparemment, static et const (ce n'est pas de la POO) ne sont pas nécessaires.

En ce qui concerne la POO, il est très intéressant de savoir à quoi ressemblerait la prochaine fonction, qui a une large application pratique (pas du tout abstraite), dans un style procédural ?

Évidemment, toute POO peut être réécrite en style procédural. Mais c'est la pratique qui m'intéresse. J'ai donc pris le petit code ci-dessus, où la POO est également utilisée au minimum.

Alors, à quel point le style procédural est-il plus agréable/plus pratique/plus lisible/plus correct que la POO dans cet exemple ? Eh bien, pas pour parler pendant quelques pages, mais juste pour comparer le code source court procédural contre OOP. Je demande aux adversaires d'OOP de montrer un cours magistral. Il ne s'agit pas du redoutable MT5, mais du bon vieux MT4.

Je ne suis pas contre la POO. Juste une de mauvaise qualité et un code cryptique. (Je ne suis pas un opposant à la POO, mais seulement à la mauvaise qualité et au code cryptique).

#define  MC 200
#define  MYOWNSELECT        OrderSelect     
#define  MYOWNTICKET        OrderTicket
#define  MYOWNOTIPE         OrderType
#define  MYOWNOLOT          OrderLots
// Возвращает true только в случае, если с последнего вызова произошли торговые изменения
bool IsChanged_NoOOP_Cryptic_aka_fxsaber(void)
{
  static int ptot=0,tickets[MC],types[MC];
  static double 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);
}
 
Dennis Kirichenko:

Je suis vraiment désolé, dans le contexte de quelle langue tirez-vous cette conclusion ? :-)




Denis, dans le cadre du forum ))))))))))

 
Alain Verleyen:

Je ne suis pas contre la POO. Juste une de mauvaise qualité et un code cryptique. (Je ne suis pas un opposant à la POO, mais seulement à la mauvaise qualité et au code cryptique).

Merci pour le code procédural ! Je l'ai un peu modifié.

#define  MC 200
#define  MYOWNSELECT        OrderSelect     
#define  MYOWNTICKET        OrderTicket
#define  MYOWNOTIPE         OrderType
#define  MYOWNOLOT          OrderLots
// Возвращает true только в случае, если с последнего вызова произошли торговые изменения
bool IsChanged_NoOOP_Cryptic_aka_fxsaber(void)
{
  static int ptot=0,tickets[MC],types[MC];
  static double 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);
}


Les avantages et les inconvénients de chacune des solutions(OOP-solution) que vous pouvez maintenant voir de vos propres yeux. Chacun fait son propre choix et il est stupide d'imposer un point de vue différent.

 
Dennis Kirichenko:

Je suis vraiment désolé, dans le contexte de quelle langue tirez-vous cette conclusion ? :-)

Sur les pros, bien sûr.

 
fxsaber:

Merci pour le code procédural ! Je l'ai un peu modifié

Pour qu'il soit clair que la compacité peut également être ajustée.

#define  MC 200
#define  MYOWNSELECT        OrderSelect     

bool IsChanged_NoOOP_Cryptic_aka_fxsaber(void)
{
  static int ptot=0;
  static string 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);
}

Vous pourriez, bien sûr, voir dans quelle mesure les performances changent lorsque l'on compare des structures/réseaux/rangs. Mais c'est un peu une tâche prise hors contexte, donc il n'y a pas de raison.

PS Et je ne suis pas contre OOP. En faveur de l'opportunité.

 
Alexander Puzanov:

Pour qu'il soit clair que la compacité est une autre chose à bricoler

Vous pourriez, bien sûr, voir dans quelle mesure les performances changent lorsque l'on compare des structures/réseaux/rangs. Mais c'est un peu une tâche prise hors contexte, donc il n'y a pas de raison.

PS Et je ne suis pas contre OOP. En faveur de l'opportunité.

Effondrement !

 
Alexander Puzanov:

Pour qu'il soit clair que la compacité peut également être ajustée.

Vous pourriez, bien sûr, voir dans quelle mesure les performances changent en comparant des structures/réseaux/rangs. Mais c'est un peu une tâche prise hors contexte, donc il n'y a pas de raison.

PS Et je ne suis pas contre OOP. En faveur de l'opportunité.

L'utilisation de DEFINE était une blague ;-) Votre approche serait très lente. (L'utilisation de DEFINE était une blague ;-) Votre approche sera très lente).

 
Alain Verleyen:

L'utilisation de DEFINE était une blague ;-) Votre approche sera très lente. (L'utilisation de DEFINE était une blague ;-) Votre approche sera très lente).

Bien sûr. C'est une blague aussi - c'est une parade d'embellissement du code, n'est-ce pas ?

C'est aussi une blague - une torsion en faveur de la compacité et de la clarté.

---

fxsaber:

Il s'effondre !

C'est une mesure d'une mise en œuvre particulière, d'un cas particulier.

 
Alexander Puzanov:

Bien sûr. C'est une blague aussi - c'est un code de parade de la beauté, n'est-ce pas ?

Oui, c'est vraiment bien.(Je ne suis pas encore capable d'attraper la blague malheureusement ;-)

Oui, très bien. Je ne suis pas encore capable d'attraper une blague malheureusement ;-)

 
fxsaber:

Les avantages et les inconvénients de chaque solution(la solution OOP) peuvent maintenant être vus par eux-mêmes. Chacun fait son propre choix et il est stupide d'imposer un point de vue différent.

Pas besoin d'imposer, mais il est évident que sous une forme procédurale la logique du code est déjà visible sans gestes supplémentaires, et chaque geste d'un programmeur engagé coûte de l'argent à l'employeur. Par conséquent, si un employeur est intelligent, il ne se laissera pas duper par la POO, mais un programmeur intelligent peut déformer une histoire sur la POO progressive pour lui soutirer plus d'argent en profitant de son faible niveau d'alphabétisation. :)

12345678910111213141516...23
Nouveau commentaire