MQL은 Pts에서 OOP 개념을 지원합니다. 제한된 형태, 주로 일부 악기의 일부에서만. MT-MQL은 폐쇄된 자급자족(개발자에 따르면) 디자인(개발자에 따르면 생태계)입니다. MT-MQL 내에서 OOP 개념에 대한 논의 또는 적용은 절대적으로 무의미합니다. 그리고 프레임워크 내에서 - class-inheritance-etc.는 흥미롭지 않습니다.
MQL은 Pts에서 OOP 개념을 지원합니다. 제한된 형태, 주로 일부 악기의 일부에서만. MT-MQL은 폐쇄된 자급자족(개발자에 따르면) 디자인(개발자에 따르면 생태계)입니다. MT-MQL 내에서 OOP 개념에 대한 논의 또는 적용은 절대적으로 무의미합니다. 그리고 프레임워크 내에서 - class-inheritance-etc.는 흥미롭지 않습니다.
흠...
저에게 있어 코드는 거의 변경 없이 C++ 플랫폼으로 전송될 수 있습니다. 거래 작업과 데이터 수신을 서비스하는 기본 클래스를 다시 작성하기만 하면 됩니다. 동시에 새로운 Expert Advisors 또는 지표 작성에는 영향을 미치지 않습니다. 모든 것은 "상단"에서 실제 클래스로 캡슐화됩니다. 모든 사용자는 가상 인터페이스만 처리하며 그 아래에는 MT4, MT5, C ++, C # 또는 기타 C 유사 플랫폼이 있을 수 있습니다. MQL의 OOP에서 무엇이 누락될 수 있는지 알 수 없습니다. 당신은 "약속하지"라고???
저에게 있어 코드는 거의 변경 없이 C++ 플랫폼으로 전송될 수 있습니다. 거래 작업과 데이터 수신을 서비스하는 기본 클래스를 다시 작성하기만 하면 됩니다. 동시에 새로운 Expert Advisors 또는 지표 작성에는 영향을 미치지 않습니다. 모든 것은 "상단"에서 실제 클래스로 캡슐화됩니다. 모든 사용자는 가상 인터페이스만 처리하며 그 아래에는 MT4, MT5, C ++, C # 또는 기타 C 유사 플랫폼이 있을 수 있습니다. MQL의 OOP에서 무엇이 누락될 수 있는지 알 수 없습니다. 당신은 "약속하지"라고???
그리고 PLO의 반대자가 많다는 사실-글쎄, 당신은 무엇을 원했습니까? 이해해야 할 것이 많은 곳이면 어디든 "우리는 타히티에 가본 적이 없다. 우리는 여기에서 배부르다"라고 말하는 반대자들이 있을 것이다.
다시 클래스-상속- 다형성 등에 대해 설명합니다. 피곤하지 않아? 모든 울타리에 이에 대한 모든 것이 이미 기록되어 있습니다.)
그건 그렇고,이 모든 것은 OOP가 아니라 도구 일뿐입니다. OOP 자체의 개념 이데올로기가 없으면 이러한 도구는 거의 무용지물입니다.
지방 당국은 이미 저를 설득했습니다)) 그리고 요점은 - 나는 휴가를 갈 것입니다.
돈 좀 벌면 좋겠어, 어제 맥주에 신이 났어))
다시 클래스-상속- 다형성 등에 대해 설명합니다. 피곤하지 않아? 모든 울타리에 이에 대한 모든 것이 이미 기록되어 있습니다.)
그건 그렇고,이 모든 것은 OOP가 아니라 도구 일뿐입니다. OOP 자체의 개념 이데올로기가 없으면 이러한 도구는 거의 무용지물입니다.
그래서 나는 개념의 장점에 대해 두 번 이상 이야기했습니다.
그래서 나는 개념의 장점에 대해 두 번 이상 이야기했습니다.
MQL은 Pts에서 OOP 개념을 지원합니다. 제한된 형태, 주로 일부 악기의 일부에서만. MT-MQL은 폐쇄된 자급자족(개발자에 따르면) 디자인(개발자에 따르면 생태계)입니다. MT-MQL 내에서 OOP 개념에 대한 논의 또는 적용은 절대적으로 무의미합니다. 그리고 프레임워크 내에서 - class-inheritance-etc.는 흥미롭지 않습니다.
다시 클래스-상속- 다형성 등에 대해 설명합니다. 피곤하지 않아? 모든 울타리에 이에 대한 모든 것이 이미 기록되어 있습니다.)
그건 그렇고,이 모든 것은 OOP가 아니라 도구 일뿐입니다. OOP 자체의 개념 이데올로기가 없으면 이러한 도구는 거의 무용지물입니다.
기지를 소유한 사람들과 개념에 대해 이야기해야 하는 것 아닙니까?
포럼에서 완전한 소강을 원하는 "지방 당국"은 어떤 종류입니까?
예, 그들은 진정을 원하지 않습니다. 모든 것이 정상입니다. 그건 그렇고, 오늘은 부흥이었습니다. 아마, 나는 속임수))))
일반적으로 움직임이 있기 위해서는 당연히 OOP를 이론이 아닌 제품 개발 과정에서 주어야 합니다. 그러나 즉시 문제가 발생합니다. 이것이 나에게 어떤 이점이 있습니까?
예를 들어, 스캘퍼, 그리드 또는 다른 것을 개발하는 것입니다.
MQL은 Pts에서 OOP 개념을 지원합니다. 제한된 형태, 주로 일부 악기의 일부에서만. MT-MQL은 폐쇄된 자급자족(개발자에 따르면) 디자인(개발자에 따르면 생태계)입니다. MT-MQL 내에서 OOP 개념에 대한 논의 또는 적용은 절대적으로 무의미합니다. 그리고 프레임워크 내에서 - class-inheritance-etc.는 흥미롭지 않습니다.
흠...
저에게 있어 코드는 거의 변경 없이 C++ 플랫폼으로 전송될 수 있습니다. 거래 작업과 데이터 수신을 서비스하는 기본 클래스를 다시 작성하기만 하면 됩니다. 동시에 새로운 Expert Advisors 또는 지표 작성에는 영향을 미치지 않습니다. 모든 것은 "상단"에서 실제 클래스로 캡슐화됩니다. 모든 사용자는 가상 인터페이스만 처리하며 그 아래에는 MT4, MT5, C ++, C # 또는 기타 C 유사 플랫폼이 있을 수 있습니다. MQL의 OOP에서 무엇이 누락될 수 있는지 알 수 없습니다. 당신은 "약속하지"라고???
"관점"은 무엇으로 표현되어야 한다고 생각합니까?
일반적으로 움직임이 있기 위해서는 당연히 OOP를 이론이 아닌 제품 개발 과정에서 주어야 합니다. 그러나 즉시 문제가 발생합니다. 이것이 나에게 어떤 이점이 있습니까?
예를 들어, 스캘퍼, 그리드 또는 다른 것을 개발하는 것입니다.
아니요, 글쎄요, 뭔가를 작성하고, 행동에 대해 댓글을 달고, 공유 프로젝트를 통해 코드를 보여주고, 보완하려는 사람들에게 제공하는 등의 이점을 얻을 수 있습니다. 나는 그들이 매우 기꺼이 할 것이라는 데 의심이 있습니다.
흠...
저에게 있어 코드는 거의 변경 없이 C++ 플랫폼으로 전송될 수 있습니다. 거래 작업과 데이터 수신을 서비스하는 기본 클래스를 다시 작성하기만 하면 됩니다. 동시에 새로운 Expert Advisors 또는 지표 작성에는 영향을 미치지 않습니다. 모든 것은 "상단"에서 실제 클래스로 캡슐화됩니다. 모든 사용자는 가상 인터페이스만 처리하며 그 아래에는 MT4, MT5, C ++, C # 또는 기타 C 유사 플랫폼이 있을 수 있습니다. MQL의 OOP에서 무엇이 누락될 수 있는지 알 수 없습니다. 당신은 "약속하지"라고???
"관점"은 무엇으로 표현되어야 한다고 생각합니까?
MT-MQL이 제공하는 도구가 충분하다는 의미일 뿐입니다. 글쎄, 좋아.