마운드에서 OOP에 대해 이야기하기 - 페이지 9

새 코멘트
 
fxsaber :

분명히 static 및 const(이것은 OOP가 아님)가 필요하지 않습니다.

OOP의 경우 (전혀 추상적이지 않은) 실제 적용이 넓은 다음 기능이 절차 적 스타일에서 어떻게 보일지 매우 흥미 롭습니다.

분명히 모든 OOP는 절차적 스타일로 다시 작성할 수 있습니다. 하지만 저는 연습에 관심이 있습니다. 따라서 OOP를 최소한으로 사용하는 위의 작은 코드를 사용했습니다.

그렇다면 이 예에서 절차적 스타일은 OOP에 비해 얼마나 더 예쁘고/더 편리하고/더 읽기 쉽고/더 정확할까요? 글쎄, 몇 페이지를 입증하지 않기 위해서가 아니라 단순히 짧은 소스 코드를 절차적 대 OOP를 비교하기 위함입니다. 나는 OOP의 반대자들에게 마스터 클래스를 보여달라고 요청합니다 . 이것은 끔찍한 MT5가 아니라 좋은 오래된 MT4입니다.

나는 OOP에 반대하지 않습니다. 품질이 좋지 않은 암호 코드 중 하나일 뿐입니다. (나는 OOP의 반대자가 아니다. 단지 나쁜 품질과 암호 코드 중 하나일 뿐이다)

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

죄송합니다. 무슨 언어로 그런 결론을 내리는 겁니까? :-)




Denis, 포럼 맥락에서)))))))))

 
Alain Verleyen :

나는 OOP에 반대하지 않습니다. 품질이 좋지 않은 암호 코드 중 하나일 뿐입니다. (나는 OOP의 반대자가 아니다. 단지 나쁜 품질과 암호 코드 중 하나일 뿐이다)

절차 코드 감사합니다! 약간 수정

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


이제 각 솔루션( OOP 솔루션 )의 장단점을 직접 볼 수 있습니다. 모두가 자신의 선택을 하고 다른 관점을 강요하는 것은 어리석은 일입니다.

 
Dennis Kirichenko :

죄송합니다. 무슨 언어로 그런 결론을 내리는 겁니까? :-)

물론 이점에 대해.

 
fxsaber :

절차 코드 감사합니다! 약간 수정

간결함과 명확성을 위해 다른 것을 고칠 수 있습니다.

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

물론 구조/배열/문자열을 비교할 때 성능이 얼마나 크게 변경되는지 확인할 수 있습니다. 그러나 이것은 컨텍스트에서 가져온 작업이므로 의미가 없습니다.

추신 그리고 나는 OOP에 반대하지 않습니다. 편의를 위해

 
Alexander Puzanov :

간결함과 명확성을 위해 다른 것을 고칠 수 있습니다.

물론 구조/배열/문자열을 비교할 때 성능이 얼마나 크게 변경되는지 확인할 수 있습니다. 그러나 이것은 컨텍스트에서 가져온 작업이므로 의미가 없습니다.

추신 그리고 나는 OOP에 반대하지 않습니다. 편의를 위해

무너질 것이다!

 
Alexander Puzanov :

간결함과 명확성을 위해 다른 것을 고칠 수 있습니다.

물론 구조/배열/문자열을 비교할 때 성능이 얼마나 크게 변경되는지 확인할 수 있습니다. 그러나 이것은 컨텍스트에서 가져온 작업이므로 의미가 없습니다.

추신 그리고 나는 OOP에 반대하지 않습니다. 편의를 위해

DEFINE을 사용하는 것은 농담이었습니다 ;-) 귀하의 접근 방식은 매우 느릴 것입니다. (DEFINE의 사용법은 농담이었습니다 ;-) 당신의 접근은 매우 느릴 것입니다.)

 
Alain Verleyen :

DEFINE을 사용하는 것은 농담이었습니다 ;-) 귀하의 접근 방식은 매우 느릴 것입니다. (DEFINE의 사용법은 농담이었습니다 ;-) 당신의 접근은 매우 느릴 것입니다.)

확실한. 이것도 장난아니고 코드미인 퍼레이드죠?

이것은 또한 농담입니다. 컴팩트함과 가시성을 위한 속임수입니다.

---

fxsaber :

무너질 것이다!

이것은 특정 구현의 측정값입니다. 특수한 경우입니다.

 
Alexander Puzanov :

확실한. 이것도 장난아니고 코드미인 퍼레이드죠?

네 정말 좋아요. (아직 장난을 못 쳐서 아쉽네요 ;-)

예, 정말 좋습니다. 불행히도, 나는 농담을 잡을 수 없습니다 ;-)

 
fxsaber :

이제 각 솔루션( OOP 솔루션 )의 장단점을 직접 볼 수 있습니다. 모두가 자신의 선택을 하고 다른 관점을 강요하는 것은 어리석은 일입니다.

강요할 필요는 없지만 절차적 형태에서 코드의 논리는 불필요한 제스처 없이 이미 표시되고 고용된 프로그래머의 각 제스처는 고용주에게 비용이 듭니다. 따라서 고용주가 바보가 아니라면 그는 OOP에 빠지지 않을 것이지만, 반면에 교활한 프로그래머는 OOP의 진행성에 대해 국수를 걸어 OOP의 이점을 활용하여 더 많은 것을 줄일 수 있습니다. 무식. :)

12345678910111213141516...23
새 코멘트