Gespräche über die PLO in der Lounge - Seite 9

Neuer Kommentar
 
fxsaber:

Offensichtlich werden static und const (dies ist nicht OOP) nicht benötigt.

Was OOP betrifft, ist es sehr interessant, wie die folgende Funktion, die eine breite praktische Anwendung hat (überhaupt nicht abstrakt), im prozeduralen Stil aussehen würde?

Natürlich kann jede OOP im prozeduralen Stil umgeschrieben werden. Aber ich bin an der Praxis interessiert. Also habe ich den obigen kleinen Code genommen, in dem OOP auch auf ein Minimum reduziert ist.

Wie viel schöner/bequemer/lesbarer/korrekter ist also der prozedurale Stil im Vergleich zu OOP in diesem Beispiel? Nun, nicht, um ein paar Seiten lang zu reden, sondern nur, um kurzen Quellcode prozedural vs. OOP zu vergleichen. Ich fordere die OOP-Gegner auf, eine Meisterklasse zu zeigen. Dies ist nicht der gefürchtete MT5, sondern der gute alte MT4.

Ich bin nicht gegen OOP. Nur eine von schlechter Qualität und kryptischem Code. (Ich bin kein Gegner von OOP, nur einer von schlechter Qualität und kryptischem Code)

#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:

Es tut mir sehr leid, in welchem Zusammenhang mit welcher Sprache ziehen Sie diese Schlussfolgerung? :-)




Denis, im Rahmen des Forums ))))))))))

 
Alain Verleyen:

Ich bin nicht gegen OOP. Nur eine von schlechter Qualität und kryptischem Code. (Ich bin kein Gegner von OOP, nur einer von schlechter Qualität und kryptischem Code)

Vielen Dank für den prozeduralen Code! Ich habe es ein wenig optimiert.

#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);
}


Die Vor- und Nachteile der einzelnen Lösungen(OOP-Lösung) können Sie jetzt mit eigenen Augen sehen. Jeder trifft seine eigene Entscheidung, und es ist albern, eine andere Sichtweise aufzudrängen.

 
Dennis Kirichenko:

Es tut mir sehr leid, in welchem Zusammenhang mit welcher Sprache ziehen Sie diese Schlussfolgerung? :-)

Über die Profis, natürlich.

 
fxsaber:

Vielen Dank für den prozeduralen Code! Ein bisschen gezwickt

Um zu verdeutlichen, dass die Kompaktheit auch optimiert werden kann.

#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);
}

Sie könnten natürlich sehen, wie sehr sich die Leistung beim Vergleich von Strukturen/Arrays/Zeilen ändert. Aber das ist eine Aufgabe, die aus dem Zusammenhang gerissen ist, also hat es keinen Sinn.

PS: Und ich bin nicht gegen OOP. Zugunsten der Zweckmäßigkeit.

 
Alexander Puzanov:

Um zu verdeutlichen, dass die Kompaktheit auch optimiert werden kann.

Sie könnten natürlich sehen, wie sehr sich die Leistung beim Vergleich von Strukturen/Arrays/Zeilen ändert. Aber das ist eine Aufgabe, die aus dem Zusammenhang gerissen ist, also hat es keinen Sinn.

PS: Und ich bin nicht gegen OOP. Zugunsten der Zweckmäßigkeit.

Kollabieren!

 
Alexander Puzanov:

Um zu verdeutlichen, dass Kompaktheit etwas anderes ist, an dem man basteln kann

Sie könnten natürlich sehen, wie sehr sich die Leistung beim Vergleich von Strukturen/Arrays/Zeilen ändert. Aber das ist eine Aufgabe, die aus dem Zusammenhang gerissen ist, also hat es keinen Sinn.

PS: Und ich bin nicht gegen OOP. Zugunsten der Zweckmäßigkeit.

Die Verwendung von DEFINE war ein Scherz ;-) Ihre Annäherung würde sehr langsam erfolgen. (Die Verwendung von DEFINE war ein Scherz ;-) Ihre Annäherung wird sehr langsam sein).

 
Alain Verleyen:

Die Verwendung von DEFINE war ein Scherz ;-) Ihre Annäherung wird sehr langsam sein. (Die Verwendung von DEFINE war ein Scherz ;-) Ihre Annäherung wird sehr langsam sein).

Ja, sicher. Auch das ist ein Witz - das ist eine Codeverschönerungsparade, nicht wahr?

Auch das ist ein Witz - eine Wendung zugunsten von Kompaktheit und Klarheit

---

fxsaber:

Es kollabiert!

Es ist eine Messung einer bestimmten Umsetzung, eines bestimmten Falles

 
Alexander Puzanov:

Ja, sicher. Auch das ist ein Witz - das ist eine Code-Schönheits-Parade, nicht wahr?

Ja, wirklich schön.(Ich kann den Witz leider noch nicht verstehen ;-)

Ja, sehr schön. Ich bin leider noch nicht in der Lage, Witz zu fangen ;-)

 
fxsaber:

Die Vor- und Nachteile der einzelnen Lösungen(der OOP-Lösung) können nun selbst gesehen werden. Jeder trifft seine eigene Entscheidung, und es ist albern, eine andere Sichtweise aufzudrängen.

Man muss sich nicht aufdrängen, aber es ist offensichtlich, dass die Logik des Codes in einer prozeduralen Form bereits ohne zusätzliche Gesten sichtbar ist, und jede Geste eines angestellten Programmierers kostet den Arbeitgeber Geld. Wenn ein Arbeitgeber klug ist, wird er sich nicht von OOP täuschen lassen, aber ein cleverer Programmierer kann ihm ein Märchen über fortschrittliche OOP auftischen, um mehr Geld von ihm zu bekommen, indem er seinen geringen Bildungsstand ausnutzt. :)

12345678910111213141516...23
Neuer Kommentar