글쎄, 왜 그런 서커스 트릭이 고전을 통해 모든 것이 훨씬 더 쉬워졌습니까? 래퍼 함수와 중괄호를 사용하여 중첩된 변수와 함수를 숨기고 액세스할 수 없도록 하면 문제가 없습니다. 이 보호 장치를 사용하면 자신과 다른 사람만 혼동할 수 있습니다 ...
이해할 수 없습니다... Protected는 함수에 대한 액세스 한정자입니다. 즉, 보호된 함수가 사용되며 클래스 함수 또는 그 하위 함수에서만 액세스할 수 있습니다. 또한 개인적으로 밑줄 문자는 사용할 때 고려해야 할 몇 가지 암시적 가정이 있음을 의미합니다.
Dennis Kirichenko 는 올바르게 언급했습니다. 하나의 Compare() 함수로 모든 것을 작성할 수 있습니다. 하지만 그때는 20여 개의 화면에 나왔을 것이고, 조사하는 것은 비현실적이었고, 지금보다 수정하기가 더 어려울 것입니다.
Compare() 함수에는 키 선택자만 남겨두고 특정 키로 비교하는 코드를 별도의 함수로 분할했습니다. 이러한 함수는 컨텍스트에 따라 다르기 때문에 다른 클래스 함수 또는 하위 항목에서만 액세스할 수 있도록 클래스의 보호된 섹션에 선언됩니다. 그리고 이러한 함수는 다른 함수 내에서 특정 좁은 작업을 수행하도록 설계되었음을 상기시키기 위해 밑줄로 시작합니다. 미래에 그런 함수를 만난다면 호출할 때 고려해야 하는 암시적 가정이 있다는 것을 즉시 알 수 있습니다.
struct HISTORY_UNIT
{
long Ticket;
int Type;
double Lots;
HISTORY_UNIT( void ) : Ticket(:: OrderTicket ()), Type(:: OrderType ()), Lots(:: OrderLots ())
{
}
booloperator !=( const HISTORY_UNIT &Unit ) const
{
return (( this .Ticket != Unit.Ticket) || ( this .Type != Unit.Type) || ( this .Lots != Unit.Lots));
}
bool IsChange( void )
{
const HISTORY_UNIT Tmp;
constbool Res = ( this != Tmp);
if (Res)
this = Tmp;
return (Res);
}
};
// Возвращает true только в случае, если с последнего вызова произошли торговые измененияbool IsChange( void )
{
static HISTORY_UNIT History[];
constint Total = OrdersTotal ();
bool Res = ( ArraySize (History) != Total);
for ( int i = 0 , j = Res ? ArrayResize (History, 0 , Total) : 0 ; i < Total; i++)
if ( OrderSelect (i, SELECT_BY_POS ))
{
if (Res || (Res = History[j].IsChange()))
ArrayResize (History, j + 1 , Total);
j++;
}
return (Res);
}
이 버전은 특히 VPS의 MT5와 관련이 있습니다. MT5는 History와 함께 매우 느리게 작동하며 계산 비용이 많이 듭니다.
분명히 모든 OOP는 절차적 스타일로 다시 작성할 수 있습니다. 하지만 저는 연습에 관심이 있습니다. 따라서 OOP를 최소한으로 사용하는 위의 작은 코드를 사용했습니다.
그렇다면 이 예에서 절차적 스타일은 OOP에 비해 얼마나 더 예쁘고/더 편리하고/더 읽기 쉽고/더 정확할까요? 글쎄, 몇 페이지를 입증하지 않기 위해서가 아니라 단순히 짧은 소스 코드를 절차적 대 OOP를 비교하기 위함입니다. OOP의 반대자들에게 마스터 클래스를 보여달라고 요청합니다. 이것은 끔찍한 MT5가 아니라 좋은 오래된 MT4입니다.
OOP의 경우 (전혀 추상적이지 않은) 실제 적용이 넓은 다음 기능이 절차 적 스타일에서 어떻게 보일지 매우 흥미 롭습니다.
분명히 모든 OOP는 절차적 스타일로 다시 작성할 수 있습니다. 하지만 저는 연습에 관심이 있습니다. 따라서 OOP를 최소한으로 사용하는 위의 작은 코드를 사용했습니다.
그렇다면 이 예에서 절차적 스타일은 OOP에 비해 얼마나 더 예쁘고/더 편리하고/더 읽기 쉽고/더 정확할까요? 글쎄, 몇 페이지를 입증하지 않기 위해서가 아니라 단순히 짧은 소스 코드를 절차적 대 OOP를 비교하기 위함입니다. OOP의 반대자들에게 마스터 클래스를 보여달라고 요청합니다. 이것은 끔찍한 MT5가 아니라 좋은 오래된 MT4입니다.
이 간단한 예에서도 너무 정교합니다. OOP는 항상 다른 사람의 코드를 이해하는 것보다 다시 작성하는 것이 더 쉽습니다. .... 최소한 간단한 인간 언어로 말해서 무엇을 하고 싶습니까? 주문 내역의 변경 사항이 무엇인지 알아보십시오.
그리고 그들이 누구이며 무엇을 배우지 않았 는지 명확히 할 수 있습니까? 중재자는 청소하는 법이나 다른 것을 배우지 않았습니다)
추신: 그건 그렇고, 전체 지점에서 나는 항상 그렇듯이 일반적인 말다툼과 같은 주제를 다루려는 단일 희망을 보지 못했습니다. 그래서 OOP 장치에서 처음부터 YouTube에 비디오를 녹화하기로 결정했습니다. 적어도 약간의 이점이 있을 것입니다. 어쨌든, 잠시 후 분기는 branch_sump에 있을 것입니다.
이것은(그리고 밑줄로 시작하는 모든 것) 보호된 클래스 기능입니다.
그래서 그들은 하나로 합쳐졌습니다!
오직 하나의 함수 - Compare()가 있지만, 전달된 키로 비교할 필요가 있습니다. 따라서 특정 보호 기능 중 하나가 선택됩니다. 따라서 사용자가 액세스할 수 없도록 보호(보호)되어 있으며 밑줄이 표시되는 Compare()에서만 액세스할 수 있습니다.
이것은 또한 코드 디자인 규칙 중 하나입니다. 밑줄로 시작하는 함수는 사용자가 호출하기 위한 것이 아니라 특정 클래스 내 작업만 제공합니다. 액세스가 제한됩니다.
글쎄, 왜 그런 서커스 트릭이 고전을 통해 모든 것이 훨씬 더 쉬워졌습니까? 래퍼 함수와 중괄호를 사용하여 중첩된 변수와 함수를 숨기고 액세스할 수 없도록 하면 문제가 없습니다. 이 보호 장치를 사용하면 자신과 다른 사람만 혼동할 수 있습니다 ...
글쎄, 왜 그런 서커스 트릭이 고전을 통해 모든 것이 훨씬 더 쉬워졌습니까? 래퍼 함수와 중괄호를 사용하여 중첩된 변수와 함수를 숨기고 액세스할 수 없도록 하면 문제가 없습니다. 이 보호 장치를 사용하면 자신과 다른 사람만 혼동할 수 있습니다 ...
이해할 수 없습니다... Protected는 함수에 대한 액세스 한정자입니다. 즉, 보호된 함수가 사용되며 클래스 함수 또는 그 하위 함수에서만 액세스할 수 있습니다. 또한 개인적으로 밑줄 문자는 사용할 때 고려해야 할 몇 가지 암시적 가정이 있음을 의미합니다.
Dennis Kirichenko 는 올바르게 언급했습니다. 하나의 Compare() 함수로 모든 것을 작성할 수 있습니다. 하지만 그때는 20여 개의 화면에 나왔을 것이고, 조사하는 것은 비현실적이었고, 지금보다 수정하기가 더 어려울 것입니다.
Compare() 함수에는 키 선택자만 남겨두고 특정 키로 비교하는 코드를 별도의 함수로 분할했습니다. 이러한 함수는 컨텍스트에 따라 다르기 때문에 다른 클래스 함수 또는 하위 항목에서만 액세스할 수 있도록 클래스의 보호된 섹션에 선언됩니다. 그리고 이러한 함수는 다른 함수 내에서 특정 좁은 작업을 수행하도록 설계되었음을 상기시키기 위해 밑줄로 시작합니다. 미래에 그런 함수를 만난다면 호출할 때 고려해야 하는 암시적 가정이 있다는 것을 즉시 알 수 있습니다.
액세스 수정자가 무엇인지, 왜 필요한지 이해하지 못하는 것 같습니다.
이해할 수 없습니다... Protected는 함수에 대한 액세스 한정자입니다. 즉, 보호된 함수가 사용되며 클래스 함수 또는 그 하위 함수에서만 액세스할 수 있습니다. 또한 개인적으로 밑줄 문자는 사용할 때 고려해야 할 몇 가지 암시적 가정이 있음을 의미합니다.
글쎄, 개인적인 모욕없이 ...
글쎄, 당신은 어떤 OOP 없이 고전적인 방식으로 함수에 대한 접근을 제한할 수 있습니다.
어떻게 ?
다음은 작업입니다. 미래에 코드를 수정할 때 "어디서나" 특정 기능을 가져 와서 사용하는 것이 불가능하도록 만드는 것입니다. public-protected-private 수정자를 사용하여 클래스 공간에 대한 액세스를 제한 하는 OOP 없이 어떻게 합니까?
분명히 static 및 const(이것은 OOP가 아님)가 필요하지 않습니다.
OOP의 경우 (전혀 추상적이지 않은) 실제 적용이 넓은 다음 기능이 절차 적 스타일에서 어떻게 보일지 매우 흥미 롭습니다.
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
주문 열거 주기의 구성
fxsaber , 2017.10.18 12:29
이 버전은 특히 VPS의 MT5와 관련이 있습니다. MT5는 History와 함께 매우 느리게 작동하며 계산 비용이 많이 듭니다.
분명히 모든 OOP는 절차적 스타일로 다시 작성할 수 있습니다. 하지만 저는 연습에 관심이 있습니다. 따라서 OOP를 최소한으로 사용하는 위의 작은 코드를 사용했습니다.
그렇다면 이 예에서 절차적 스타일은 OOP에 비해 얼마나 더 예쁘고/더 편리하고/더 읽기 쉽고/더 정확할까요? 글쎄, 몇 페이지를 입증하지 않기 위해서가 아니라 단순히 짧은 소스 코드를 절차적 대 OOP를 비교하기 위함입니다. OOP의 반대자들에게 마스터 클래스를 보여달라고 요청합니다. 이것은 끔찍한 MT5가 아니라 좋은 오래된 MT4입니다.
홍수에서 스레드를 청소하고 교육 게시물 만 남겨주세요 Alexey Volchanskiy
이미 늦었어)))) 더군다나 난 밖에 나갈 시간밖에 없을거야 갑자기 너무 바빠서
공부 좀 하고 영상 나올지도 몰라
홍수에서 스레드를 청소하고 교육 게시물 만 남겨주세요 Alexey Volchanskiy
블라디미르, 그동안 배우지 못했다면 시작하기에는 너무 늦었다고 생각합니다;)
분명히 static 및 const(이것은 OOP가 아님)가 필요하지 않습니다.
OOP의 경우 (전혀 추상적이지 않은) 실제 적용이 넓은 다음 기능이 절차 적 스타일에서 어떻게 보일지 매우 흥미 롭습니다.
분명히 모든 OOP는 절차적 스타일로 다시 작성할 수 있습니다. 하지만 저는 연습에 관심이 있습니다. 따라서 OOP를 최소한으로 사용하는 위의 작은 코드를 사용했습니다.
그렇다면 이 예에서 절차적 스타일은 OOP에 비해 얼마나 더 예쁘고/더 편리하고/더 읽기 쉽고/더 정확할까요? 글쎄, 몇 페이지를 입증하지 않기 위해서가 아니라 단순히 짧은 소스 코드를 절차적 대 OOP를 비교하기 위함입니다. OOP의 반대자들에게 마스터 클래스를 보여달라고 요청합니다. 이것은 끔찍한 MT5가 아니라 좋은 오래된 MT4입니다.
블라디미르, 그동안 배우지 못했다면 시작하기에는 너무 늦었다고 생각합니다;)
그리고 그들이 누구이며 무엇을 배우지 않았 는지 명확히 할 수 있습니까? 중재자는 청소하는 법이나 다른 것을 배우지 않았습니다)
추신: 그건 그렇고, 전체 지점에서 나는 항상 그렇듯이 일반적인 말다툼과 같은 주제를 다루려는 단일 희망을 보지 못했습니다. 그래서 OOP 장치에서 처음부터 YouTube에 비디오를 녹화하기로 결정했습니다. 적어도 약간의 이점이 있을 것입니다. 어쨌든, 잠시 후 분기는 branch_sump에 있을 것입니다.