OOP에 대한 흥미로운 해석 - 페이지 10

 
Vitaly Muzichenko :

나는 이 디자인이 가독성과 어수선함 면에서 전혀 마음에 들지 않는다.

동의한다)))

이것에 대한 유일한 정당성은 디버깅입니다)

 
Vitaly Muzichenko :

나는 이 디자인이 가독성과 어수선함 면에서 전혀 마음에 들지 않는다.

이것은 나의 원래 질문 이었습니다.

마지막 예는 @fxsaber 의 실행 시 100% 다른 코드가 있을 것이라는 진술입니다. 몇 페이지 전에 디버거에서 디스어셈블러를 게시했습니다. 코드는 90% 동일합니다.

문제 없이 읽을 수 있는 간단한 구성의 반환을 통해 반환을 거부하는 것에 대해 이야기하는 것이 아닙니다.

 
Igor Makanu :

어딘가에 그들이 썼고 여기에 개발자가 비슷한 정보를 가지고 있습니다.

이것만 찾았습니다:

스위치는 점프 테이블을 사용하는 안전한 goto입니다. 저것들. '케이스' 주소는 정수 에서 계산됩니다.   스위치에서. 이 때문에 스위치는 사전과 같은 더 멋진 컬렉션은 말할 것도 없고 if-else에 비해 매우 효율적입니다.

 
fxsaber :

어떤 품질의 코드가 "컴파일러가 이를 최적으로 빗어 낼 것"을 기반으로 작성하면 여기에 부정적인 영향이 있지 않습니까?

한 가지 스타일로 작성하면 컴파일러가 올바른 작업을 수행한다는 것을 확실히 알 수 있습니다. 다른 하나는 컴파일러가 더 똑똑하기를 바랍니다.

크로스 플랫폼, 다른 컴파일러 등을 고려하여 코드에서 수행 중인 작업에 대한 인식을 선택합니다.

컴파일러가 정확히 어떻게 할 것인지는 그 자신만이 알고 있습니다. 최신 컴파일러에는 놀라운 경험적 방법이 내장되어 있습니다. 그들은 평균적인 코더에 적응하고 그가 필요로 하는 것을 이미 더 잘 알고 있습니다. 컴파일러가 할 수 있는 최선의 방법은 짧은 함수 로 간단하고 명확한 코드를 작성하는 것입니다. 컴파일러가 많은 노드 함수로 구성된 소스 코드 그래프를 분석하여 최종 프로그램을 빌드하는 것이 훨씬 쉽고 효율적입니다. 필요한 기능이 올바른 위치에 인라인되기 때문에 이는 성능에 긍정적인 영향을 미칠 뿐입니다.

 
Vasiliy Sokolov :

스위치는 점프 테이블을 사용하는 안전한 goto입니다. 저것들. '케이스' 주소는 정수 에서 계산됩니다.   스위치에서. 이 때문에 스위치는 사전과 같은 더 멋진 컬렉션은 말할 것도 없고 if-else에 비해 매우 효율적입니다.

시원한! 유용한 정보입니다

고마워!

 

많은 사람들이 소규모 수업을 작성하는 것이 좋습니다. 동일한 Eckel은 "명확하게 정의된 단일 목적을 위한 클래스를 생성합니다."라고 말합니다.

이제 나는 고문에 대해 일하고 있습니다. 조금 단순화된 예를 작성하겠습니다. "최대 정지 손실 수 달성" 매개변수 중 하나가 있습니다. 수신 시 SL은 0까지 카운트다운하는 형태로 작업하여 Advisor의 작업을 중지하고 TP를 수신하면 패널에 표시된 값으로 초기값으로 재설정해야 합니다.

그런 카운터를 위해 별도의 클래스를 만들었습니다. 입력 매개 변수를 설정할 때 OnInit에서, 주문을 닫은 후 입력 필드의 패널에서 여러 지점에서 변경되는 것으로 나타났습니다(sl 및 tp는 값을 다르게 변경함). 또한 주 함수는 OnTick()에서 호출되어 EA를 중지 하기 위한 최대 정지 손실 수의 달성을 모니터링합니다.

아주 간단한 수업인 것 같습니다. 그러나 이 작은 클래스는 패널에 있는 다른 개체(입력 필드, 버튼)에 영향을 줍니다. 다른 기능의 영향을 받습니다. 그리고 그러한 작은 클래스가 10개 있을 때 어떤 함수가 객체를 변경하는지 또는 일부 객체의 어떤 메소드가 다른 객체의 상태를 변경할 수 있는지 추적하는 것이 이미 더 어렵습니다.

이해하고 싶지만 혼란을 줄이기 위해 개체 간의 상호 작용을 구성하는 가장 좋은 방법은 무엇입니까? 코드 예제, 이 주제에 대한 다이어그램 및 좋은 설명이 포함된 좋은 기사나 책이 있습니까? 누군가가 잘 설계된 아키텍처를 작성하는 방법을 배우는 데 도움이 된 내용을 공유하십시오.

 
이것은 OOP 문제가 아니라 전문가 양성에 대한 일반적인 접근 방식의 문제입니다. 기록에 따라 손절매 수를 계산할 필요가 있습니다. 일반적으로 이것은 사람에게 머리가 주어지는 바로 그 것이며 보편적 인 해결책은 없습니다.
 
Vitaly Muzichenko :

나는 이 디자인이 가독성과 어수선함 면에서 전혀 마음에 들지 않는다.

맛과 색 .... 모든 마커가 다릅니다.

그것은 "작은 괴물"의 반대였습니다.

거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼

OOP에 대한 흥미로운 해석

fxsaber , 2021.01.31 01:09

작은 괴물.

   static bool VirtualOrderSelect( const TICKET_TYPE Index, const int Select, const int Pool = MODE_TRADES )
  {
     return (VIRTUAL::SelectOrders ? VIRTUAL::SelectOrders. OrderSelect (Index, Select, Pool) :
           #ifdef VIRTUAL_SNAPSHOT_REFRESHTIME
             VIRTUAL::SnapshotPtr ?
             #ifdef __MQL5__ // Выбор по тикету в MT5 - разнообразный набор вариантов.
               (Select == SELECT_BY_TICKET) ? :: OrderSelect (Index, Select, Pool) && VIRTUAL::SnapshotPtr.CopyOrder()
                                            :
             #endif // #ifdef __MQL5__
                                              ((((Index == INT_MIN ) || (Index == INT_MAX )) && (Pool == MODE_TRADES) &&
                                               :: OrderSelect (Index, Select, Pool) &&
                                             #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY
                                               VIRTUAL::SnapshotPtr.CopyOrder( true ))
                                             #else // #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY
                                               VIRTUAL::SnapshotPtr.CopyOrder())
                                             #endif // #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY #else
                                               || VIRTUAL::SnapshotPtr. OrderSelect (Index, Select, Pool))
                                  :
           #endif // #ifdef VIRTUAL_SNAPSHOT_REFRESHTIME
           #ifdef __MQL5__
             #ifdef __MT4ORDERS__
               :: OrderSelect (Index, Select, Pool)
             #else // __MT4ORDERS__
               false
             #endif // __MT4ORDERS__
           #else // __MQL5__
             :: OrderSelect (Index, Select, Pool)
           #endif // __MQL5__
           );
  }

매크로를 통해 다양한 설정을 사용할 때 논리 연산 을 통해 간결하게 작성할 수 있습니다. 그러나 그것은 물론 끔찍합니다.


 
Andrey Khatimlianskii :

맛과 색 .... 모든 마커가 다릅니다.

사실이 아니다. 색상만 다를 뿐 맛은 모두 동일합니다...))))

 
Vitaly Muzichenko :

나는 이 디자인이 가독성과 어수선함 면에서 전혀 마음에 들지 않는다.

왜 그런 겁니까 ?

반대의 경우 두 개의 "if"가 있습니다. "or" 연산자보다 훨씬 쉽습니다.

분명히 하나의 조건을 먼저 추적하고 실행의 경우 함수를 종료한 다음 다른 조건을 확인하고 실행의 경우 떠나는 것이 더 쉽습니다. 논리적 "or"("and"와 쉽게 혼동될 수 있음)를 통해 복잡한 조건의 결과로 어떤 일이 발생하는지 파악하고 두 반환 옵션을 모두 추적하는 방법.

아래에서 "디버깅에 대한 정당화"를 읽는 것이 매우 재미있습니다. 왜냐하면 이것은 그러한 코드가 훨씬 더 이해하기 쉽다는 것을 의미하기 때문입니다(그렇지 않으면 디버깅에 있는 이유는 무엇입니까?).

"Apotheosis" 나는 fxsaber의 한 표현을 고려하는데, 그 자신이 어떻게 작동하는지 말할 수 없었고 단순히 "코드가 반복적으로 테스트되었고 작동합니다."라고 말했습니다. 제 생각에는 다음과 같이 되어서는 안 됩니다.

ENUM_ORDER_TYPE_FILLING CSymbolInfo::GetTypeFilling(string strSymbol,ENUM_ORDER_TYPE_FILLING otfFilingType)
{
   const ENUM_SYMBOL_TRADE_EXECUTION steExeMode = ( ENUM_SYMBOL_TRADE_EXECUTION ):: SymbolInfoInteger (strSymbol, SYMBOL_TRADE_EXEMODE );
   const int iFillingMode = ( int ):: SymbolInfoInteger (strSymbol, SYMBOL_FILLING_MODE );

   return ((iFillingMode == 0 || (otfFilingType >= ORDER_FILLING_RETURN ) || ((iFillingMode & (otfFilingType + 1 )) != otfFilingType + 1 )) ?
         (((steExeMode == SYMBOL_TRADE_EXECUTION_EXCHANGE ) || (steExeMode == SYMBOL_TRADE_EXECUTION_INSTANT )) ?
           ORDER_FILLING_RETURN : ((iFillingMode == SYMBOL_FILLING_IOC ) ? ORDER_FILLING_IOC : ORDER_FILLING_FOK )) :
          otfFilingType);
};

이 코드는 otfFilingType 순서 를 채울 수 있는지 확인하고 strSymbol 기호에서 사용할 수 있으면 반환하고 그렇지 않으면 올바른지 확인합니다.


나는 그것이 어떻게 작동하는지 잘 이해할 수 없습니다. 그리고 저는 fxsaber의 권위에만 의존합니다.

누군가 설명해줄까요?