나는 현대 프로그래밍에서 먹은 계란의 수준 문제를 더 급격하게 혼동시킬 수 있는 다른 가능성이 있는지 궁금합니다.
OOP는 메커니즘의 일부를 분리, 포장 및 숨기는 방법입니다. 필요한지 아닌지는 개발자가 결정합니다. 메커니즘의 효율성을 높이는 것과는 관련이 없습니다. 구조적 사고, 그렇습니다. 제대로 구성되었는지 여부는 알 수 없습니다. 이것이 필요한지 여부는 개인에 따라 다릅니다. 임호.
Реter Konow : OOP는 메커니즘의 일부를 분리, 포장 및 숨기는 방법입니다. 필요한지 아닌지는 개발자가 결정합니다. 메커니즘의 효율성을 높이는 것과는 관련이 없습니다. 구조적 사고, 그렇습니다. 올바르게 구성되었는지 여부는 알 수 없습니다. 이것이 필요한지 여부는 개인에 따라 다릅니다. 임호.
함수를 작성할 때 항상 문제가 있습니다.
1. 함수를 작성했다
2. 다른 함수를 작성하고 매우 유사하지만 첫 번째 함수와 다르다는 것을 알 수 있습니다.
항상 딜레마: 하나를 버릴 것인가, 아니면 둘을 남길 것인가? 더 다양하지만 더 복잡한 코드를 얻을 수 있습니다. 간단한 코드를 얻을 수 있지만 많은 기능이 있습니다. OOP도 마찬가지입니다.
내 OnInit()은 거의 동일하게 보입니다 - 12줄...
그래서 무엇?
기절!
나는 현대 프로그래밍에서 먹은 계란의 수준 문제를 더 급격하게 혼동시킬 수 있는 다른 가능성이 있는지 궁금합니다.
그리고 이것이 전체 프로그램이라는 사실 .. 더 이상 아무것도 없습니다 :-)
당연히 아니지.
ash + R의 다른 모든 것(포함되지 않음)
디버깅은 디버깅 논리입니다. 두 체커가 교차하지만 신호가 없습니다. 터미널에서 변수 값을 이해하는 데 문제가 있습니다. 여기서 중요한 것은 계정 유형을 변경하지 않는 것이며 브로커를 변경하지 않는 것이 좋습니다.
여기 위에 쓰여진 모든 열정은 나에게 알려지지 않았습니다.
당연히 아니지.
ash + R의 다른 모든 것(포함되지 않음)
디버깅은 디버깅 논리입니다. 두 체커가 교차하지만 신호가 없습니다. 터미널에서 변수 값을 이해하는 데 문제가 있습니다. 여기서 중요한 것은 계정 유형을 변경하지 않는 것이며 브로커를 변경하지 않는 것이 좋습니다.
여기 위에 쓰여진 모든 열정은 나에게 알려지지 않았습니다.
솔직히 말해서 - 적어도 하나의 실제 계정이 있습니까? 열정은 현실 세계와의 충돌에서 비롯되고 착취 / 유지 관리 마졸로 가득 차 있습니다. 그러나 테스터에게는 무엇을, 어떻게 작성하는 것이 중요하지 않습니다 ..
OOP는 메커니즘의 일부를 분리, 포장 및 숨기는 방법입니다. 필요한지 아닌지는 개발자가 결정합니다. 메커니즘의 효율성을 높이는 것과는 관련이 없습니다. 구조적 사고, 그렇습니다. 올바르게 구성되었는지 여부는 알 수 없습니다. 이것이 필요한지 여부는 개인에 따라 다릅니다. 임호.
함수를 작성할 때 항상 문제가 있습니다.
1. 함수를 작성했다
2. 다른 함수를 작성하고 매우 유사하지만 첫 번째 함수와 다르다는 것을 알 수 있습니다.
항상 딜레마: 하나를 버릴 것인가, 아니면 둘을 남길 것인가? 더 다양하지만 더 복잡한 코드를 얻을 수 있습니다. 간단한 코드를 얻을 수 있지만 많은 기능이 있습니다. OOP도 마찬가지입니다.
소수의 클래스를 잘 구성하고 이해할 수 있도록 구분할 수 있다면,
어드바이저를 많이 쓰다 보면
어떤 이유로 자주 수정하는 경우
그 다음에
OOP가 도움이 됩니다.
그게 아니라면 거래와 전혀 상관없는 정보로 머리를 어지럽혀도 소용 없겠지만 차라리 R에서 시간을 보내는 게 낫다.
모든 성공!
솔직히 말해서 - 적어도 하나의 실제 계정이 있습니까? 열정은 현실 세계와의 충돌에서 비롯되고 착취 / 유지 관리 마졸로 가득 차 있습니다. 그러나 테스터에게는 무엇을, 어떻게 작성하는 것이 중요하지 않습니다 ..
PAMM을 포함하여 2008년부터.
추적에는 문제가 없습니다.
그러나 수술로 ...
그런 다음 스프레드가 20으로 증가하고 때로는 여백이 증가하고 간격이 끝나면 조명이 꺼집니다 .... 그러면 아내가 터치 버튼의 먼지를 닦을 것입니다 ... 일반적으로 충분합니다. 따라서 이 지점은 중국을 방문하는 것과 같습니다.
함수를 작성할 때 항상 문제가 있습니다.
1. 함수를 작성했다
2. 다른 함수를 작성하고 매우 유사하지만 첫 번째 함수와 다르다는 것을 알 수 있습니다.
항상 딜레마: 하나를 버릴 것인가, 아니면 둘을 남길 것인가? 더 다양하지만 더 복잡한 코드를 얻을 수 있습니다. 간단한 코드를 얻을 수 있지만 많은 기능이 있습니다. OOP도 마찬가지입니다.
소수의 클래스를 잘 구성하고 이해할 수 있도록 구분할 수 있다면,
어드바이저를 많이 쓰다보면
어떤 이유로 자주 수정하는 경우
그 다음에
OOP가 도움이 됩니다.
저는 개인적으로 솔루션의 보편성을 위해 노력합니다. 이를 위해서는 코드 양을 늘리지 않고 유사한 기능을 하나의 블록으로 "연결"해야 합니다. 메커니즘의 효율성을 높이고 과부하 및 분리가 필요하지 않습니다. 두뇌를 사용하면 됩니다.)
즉, 각각 20줄씩 2개의 기능이 있었다. 둘 다 유사한 작업을 수행하거나 동일한 유형의 작업을 해결합니다. 내 목표는 두 기능의 작업을 수행하는 20줄 이하의 코드로 된 하나의 기능으로 만드는 것입니다. 이것이 내가 블록을 얻는 방법입니다.
추신.
진주로 향하는 제목이 있었습니다.
그녀 안에 있어
프로그램 매뉴얼은 문서가 아닙니다.
매뉴얼은 프로그램의 기능(프로그램이 할 수 있는 것)에 대한 설명입니다. 사용자에게 필요합니다.
문서는 프로그램의 구조(프로그램이 어떻게 구축되었는지)에 대한 설명입니다. 프로그래머에게 필요합니다.
용어 충돌이 없습니다.
...
그렇지 않다면 거래와 전혀 상관없는 정보로 머리를 어지럽힐 필요가 없지만 R에 시간을 보내는 것이 좋습니다.
모든 성공!
거래에서 R 의 효율성을 입증하십시오. 이미 충분한 시간을 투자했습니다. 대회 참가 - 9월 1일; 2.분기별
https://www.mql5.com/ru/forum/212596
1. OOP를 사용 하여 Expert Advisors의 수익성이 얼마나 향상되었습니까?
2. 귀하의 어드바이저가 OOP 사용을 거부하는 사이의 시간은 얼마나 감소했습니까?
2. 힘들다))))) 컴퓨터 프로그램의 MTBF... 클리닉!