1) 캡슐화 . 저것들. 객체 자체에 변수, 유사 변수("객체 속성" 또는 간단히 "속성"이라고 함)를 저장합니다. 저것들. 클래스가 제대로 선언되면 외부에서 해당 데이터를 변경할 수 없습니다.
클래스 자체의 기능을 사용하는 경우에만 가능합니다("클래스 메소드" 또는 간단히 "메소드"라고 함). 어떤 변수에 값을 할당할 뿐만 아니라 이러한 필드를 변경하는 것과 관련하여 일부 작업을 수행하기 위해 필요합니다.
그리고 이것은 OOP를 MQL에 도입하는 주된(내 생각에) 유용성이며 기능의 이전이 아닙니다(내 거래 라이브러리의 기능은 EA 인덱스를 매개변수 중 하나로 수신하고 명령).
비뚤어진 손을 가진 사람은 당신이 만든 클래스 의 데이터에 들어갈 수 없으며(소스 코드가 없는 경우) 당신의 코드가 오류와 함께 작동하는 부패를 낳을 수 없습니다.
2) 상속 . 자손 클래스를 생성할 때 조상 클래스의 모든 필드와 메소드를 상속합니다.
여기에서 객체의 디자인 단계에서 아키텍처에 대해 명확하게 생각해야 합니다. 이 클래스가 어떻게 사용되는지, 어떤 필드를 포함할지, 자손에서 어떻게 표시되어야 하는지 등입니다.
강력한 시스템과 클래스 라이브러리에서 사용되며, 거래 작업에서는 개인적으로 볼 수 없는 수준입니다. 하지만 누군가는 필요할 것입니다. 예를 들어, 다른 후행 중지를 사용하여 하위 클래스를 만들 수 있습니다.
그렇기 때문에 메서드 내부에 상수가 없고 모든 것이 외부에서 해당 메서드를 통해(보통 .Set 으로 시작) 메서드 매개변수로 직접 설정되어야 합니다. 나는 당신의 500 에 대해 이야기하고 있습니다.
3) 다형성 . 위에 제가 쓴 글은 자손 클래스에서 재작업한 openorders() 함수가 예전 Buy() 함수 등에 의해 조용히 호출될 때입니다.
다형성의 예는 다른 그림에 대한 기하학적 그림의 면적 계산입니다.
원의 경우 한 가지 방식으로, 사각형의 경우 다른 방식으로 계산됩니다. 그러나 어떤 경우에도 - Figura.GetSquare() 를 호출하면 기본 클래스에서 상속된 특정 그림의 면적을 얻을 수 있습니다 (Square() 선언을 잊지 않은 경우).
다시 말하지만, 기본 클래스 아키텍처를 생성하려면 약간의 기술이 필요합니다. 예를 들어 Square() 를 virtual 로 선언하는 것을 잊었다면 일반적인 방식으로 Square 를 호출할 수 없게 됩니다(각 호출 전에 클래스 유형을 확인하고 정확히 Square 구현을 호출해야 함).
일부는 생성자를 제외한 모든 메서드를 가상으로 만들 것을 권장합니다(클래스를 생성할 때 이 클래스가 성장할 수 있는 범위가 보이지 않는 경우 동일한 관점을 고수합니다). 가장 중요한 것은 소멸자도 가상이어야 한다는 것입니다.
업데이트:
=================
4) 추상화 (동지들의 요청에 따라, 비록 내가 OOP를 공부할 때(1990년대에) 그것은 원칙으로 간주되지 않았지만(사실 그것은 단순히 처음 세 개에서 따랐기 때문임), 기사(아래 링크 참조)에서는 다음과 같습니다. 그것에 대해 작성되었지만 기사 제목에는 없으며 3) 만 있습니다.
실제 사용에서 이것은 "빈" 기본 클래스를 만드는 것입니다(메소드가 선언되었지만 아무 작업도 수행하지 않음). 일부 언어에서는 메서드를 abstract 로 표시할 수 있습니다. 즉, 자손 클래스에서는 재정의 해야 합니다(즉, 어떤 작업을 수행하는 메서드가 추가됨).
PPS: 누구의 기분을 상하게 하고 싶지는 않지만 Work에서 거래 라이브러리 작성을 요청했을 때 단 한 사람만이 가지고 있고 사용하고 있다고 대답했습니다.
5 MQL 프로그래머(Skype에서)는 그 안에 무엇이 들어 있어야 하는지 전혀 모르고 올빼미 중 하나에서 다른 올빼미로 필요한 기능을 복사하여 붙여넣었다고 말했습니다. 실제로는 아무 것도 변경하지 않고 몇 밀리초 이상 실행할 수 없는 코드 섹션 사이에 RefreshRates() 를 붙입니다. 그리고 다음 코드는 변경된 Ask 및 Bid 및 (아마도 변경된 주문 유형) 어떤 식으로든 의존하지 않습니다.
따라서 이전에 다른 프로그래밍 언어의 OOP로 작업한 적이 없는 MQL 프로그래머에게는 MQL의 OOP가 아무런 이점이 없습니다. 최대한 - 외부 변경으로부터 데이터를 숨깁니다(이것도 나쁘지 않음).
언제나처럼 배우고 싶었지만 똑똑하고 더 이상 할 말이 없는 사람들이 분명히 있을 것입니다 ...
나는 그것을 구문 분석하기 위해 간단한 예제를 작성했습니다. OOP로 더 올바르게 작성하는 방법을 모르겠습니다 ... 이것은 단지 예일뿐입니다. 그러한 코드와 OOP를 올바르게 작성하는 방법을 알고 있다면 나와 다른 사람들이 배울 수 있습니다...
OOP는 개체 검색으로 시작됩니다. 객체가 없으면 OOP가 없습니다.
일반적으로 개체는 일종의 리소스인 데이터입니다.
다른 사람들이 어떻게 쓰는지 보고 쓰기만 하면 됩니다. 그러면 올 것이다. 교과서도 읽을 수 있다. 인터넷에 많이 있습니다.
OOP는 객체를 찾는 것으로 시작됩니다. 객체가 없으면 OOP가 없습니다.
일반적으로 개체는 일종의 리소스인 데이터입니다.
다른 사람들이 어떻게 쓰는지 보고 쓰기만 하면 됩니다. 그러면 그냥 옵니다. 교과서도 읽을 수 있다. 그들은 인터넷에 가득 차 있습니다.
몇 가지 자습서를 추천하십시오 ... 귀하의 의견으로는 가장 간단하고 유용합니다 ...
몇 가지 자습서를 추천하십시오 ... 귀하의 의견으로는 가장 간단하고 유용합니다 ...
그래디 부치. "객체 지향 분석 및 설계 . C++의 예제 응용 프로그램 사용"
Ire Paul(때때로 Ira Paul 철자) "C++의 객체 지향 프로그래밍"
1) OOP와 관련이 없지만 거래 작업 오류 처리기( OrderSend() , OrderDelete() , OrderModify() )가 추가되어야 합니다...
OOP와 관련이 있으려면 가상 클래스 메서드로 만듭니다(다른 코드의 처리를 추가하여 자손 클래스에서 재정의할 수 있도록).
2) 지금처럼 자손 클래스에서 작동하지 않을 수 있는 모든 클래스 메서드 - 가상 으로 만듭니다.
첫 번째 후보는 openorders() 입니다.
마이너스 중 - 가상 방법에서는 매개 변수의 수와 유형을 변경할 수 없습니다.
플러스 측면에서 "이전" Buy , Sel , BuyStop 등은 "new"(자식 클래스에서 수정됨) openorders() 를 호출할 수 있습니다.
3) 바로 더 아름다운 이름을 지어보자. 예를 들어, openorders 대신 OpenOrders .
4) 용어에서 무언가를 부르는 것이 관례라면 비슷한 용어를 사용합니다.
판매 = SELL 이면 Sell 또는 SELL을 호출합니다(예: SelStop 대신 SellStop ).
5) 클래스에서 모든 상수(500 등)를 제거해야 합니다.
변수에서 가져오거나 메서드의 매개변수로 설정하도록 합니다.
이제 openorders ()로 연결된 약 500개를 기억합니다. 그런 다음 잊어버리거나 이러한 클래스를 사용하여 많은 올빼미가 작성되고 무언가를 변경하기 어려울 것입니다.
아키텍처 오류는 수정하기 가장 어렵습니다.
이제 골격을 만들고 있습니다(단순한 운동이 아닌 경우).
6) 한 클래스에 모든 것을 담지 마십시오.
clOrder 클래스를 만들고 여기에 SetSL , CloseOrder , GetSL , GetProfit , SetTP , GetTP 등을 첨부합니다.
그리고 clTrade 클래스에서 주문 배열/목록, 기호 및 기호 속성( TICKETSIZE , POINT , TICKETVALUE, MINLOT, MAXLOT, STOPSTEP, LOTSTEP, LOTSIZE 등)을 꿰매십시오.
Ask 및 Bid (심볼 속성으로)를 조이면 OnTick() 에서 업데이트하는 것을 잊지 마십시오.
MT 변수를 업데이트한 후 Ask 및 Bid 속성이 업데이트되도록 RefreshRates() 에 바인딩합니다(주문 상태, 열린 사람 및 닫은 사람도 확인합니다. 닫힌 주문은 주문 목록에서 삭제됨).
거래 일정(클래스를 먼저 만들기도 함)과 후행 중지(별도 클래스 만들기)를 추가할 수 있습니다.
추신: 주말 내내 했습니다(거래용 라이브러리를 만들었습니다). 하지만 이번에는 클래스 없이 하기로 결정했습니다(이 모든 것과 작동하는 구조체, 구조체 배열 및 함수만).
매일의 일정도 있습니다(금의 알프스는 매일 0시부터 1시까지 쉬는 시간이 있기 때문에). 거래 마지막 2분 동안 일정 확인 기능은 모든 거래를 마감하고 모든 주문을 취소합니다.
그리고 마지막 거래 시간에 수익성 없는 거래를 마감하고 주문을 취소하며 수익성 있는 거래를 추적합니다. 후행도 했다. 하나의 유형이지만 다른 매개 변수로 인해 다른 문자에 적합합니다.
체계는 다음과 같습니다. Symbols(필드 포함), Orders(필드 포함), Schedules(필드 포함) 및 자체 필드(마법 등)가 있는 Expert Advisor는 Symbol을 참조하고 목록을 가지고 있습니다. 주문 및 일정 목록.
계층의 맨 위 는 Advisors 목록입니다 (기호+마법 조합은 고유해야 함).
몇 가지 자습서를 추천하십시오 ... 귀하의 의견으로는 가장 간단하고 유용합니다 ...
CodeBase에는 이제 OOP를 사용하여 작성된 예제가 있습니다. VOLDEMAR 'a에서 예)))
사실, https://www.mql5.com/ru/code/11159 에서 구조에 대한 거래 라이브러리를 다시 작성하라는 메시지가 표시되었습니다.
지금은 클래스와 함께 기다리기로 결정했습니다. 아직 MQL에서 사용하는 데 아무런 의미가 없습니다.
또는 MQL5에서만 표준이며 거기에서 새로운 메타 편집기로 마이그레이션했습니다.
CodeBase에는 이제 OOP를 사용하여 작성된 예제가 있습니다. VOLDEMAR 'a에서 예)))
사실, 내가 구조에 대한 거래 라이브러리를 다시 작성하도록 영감을 준 것은 https://www.mql5.com/en/code/11159 였습니다.
지금은 클래스와 함께 기다리기로 결정했습니다. 아직 MQL에서 사용하는 데 아무런 의미가 없습니다.
네, 제가 썼지만, 클래스에 함수를 옮기는 것 외에는 아직 이해한 바가 없습니다.
네, 이렇게 썼는데, 클래스에 함수를 옮기는 것 외에는 아직 이해한 바가 없습니다.
3(+1) OOP 원칙:
1) 캡슐화 . 저것들. 객체 자체에 변수, 유사 변수("객체 속성" 또는 간단히 "속성"이라고 함)를 저장합니다. 저것들. 클래스가 제대로 선언되면 외부에서 해당 데이터를 변경할 수 없습니다.
클래스 자체의 기능을 사용하는 경우에만 가능합니다("클래스 메소드" 또는 간단히 "메소드"라고 함). 어떤 변수에 값을 할당할 뿐만 아니라 이러한 필드를 변경하는 것과 관련하여 일부 작업을 수행하기 위해 필요합니다.
그리고 이것은 OOP를 MQL에 도입하는 주된(내 생각에) 유용성이며 기능의 이전이 아닙니다(내 거래 라이브러리의 기능은 EA 인덱스를 매개변수 중 하나로 수신하고 명령).
비뚤어진 손을 가진 사람은 당신이 만든 클래스 의 데이터에 들어갈 수 없으며(소스 코드가 없는 경우) 당신의 코드가 오류와 함께 작동하는 부패를 낳을 수 없습니다.
2) 상속 . 자손 클래스를 생성할 때 조상 클래스의 모든 필드와 메소드를 상속합니다.
여기에서 객체의 디자인 단계에서 아키텍처에 대해 명확하게 생각해야 합니다. 이 클래스가 어떻게 사용되는지, 어떤 필드를 포함할지, 자손에서 어떻게 표시되어야 하는지 등입니다.
강력한 시스템과 클래스 라이브러리에서 사용되며, 거래 작업에서는 개인적으로 볼 수 없는 수준입니다. 하지만 누군가는 필요할 것입니다. 예를 들어, 다른 후행 중지를 사용하여 하위 클래스를 만들 수 있습니다.
그렇기 때문에 메서드 내부에 상수가 없고 모든 것이 외부에서 해당 메서드를 통해(보통 .Set 으로 시작) 메서드 매개변수로 직접 설정되어야 합니다. 나는 당신의 500 에 대해 이야기하고 있습니다.
3) 다형성 . 위에 제가 쓴 글은 자손 클래스에서 재작업한 openorders() 함수가 예전 Buy() 함수 등에 의해 조용히 호출될 때입니다.
다형성의 예는 다른 그림에 대한 기하학적 그림의 면적 계산입니다.
원의 경우 한 가지 방식으로, 사각형의 경우 다른 방식으로 계산됩니다. 그러나 어떤 경우에도 - Figura.GetSquare() 를 호출하면 기본 클래스에서 상속된 특정 그림의 면적을 얻을 수 있습니다 (Square() 선언을 잊지 않은 경우).
다시 말하지만, 기본 클래스 아키텍처를 생성하려면 약간의 기술이 필요합니다. 예를 들어 Square() 를 virtual 로 선언하는 것을 잊었다면 일반적인 방식으로 Square 를 호출할 수 없게 됩니다(각 호출 전에 클래스 유형을 확인하고 정확히 Square 구현을 호출해야 함).
일부는 생성자를 제외한 모든 메서드를 가상으로 만들 것을 권장합니다(클래스를 생성할 때 이 클래스가 성장할 수 있는 범위가 보이지 않는 경우 동일한 관점을 고수합니다). 가장 중요한 것은 소멸자도 가상이어야 한다는 것입니다.
업데이트:
=================
4) 추상화 (동지들의 요청에 따라, 비록 내가 OOP를 공부할 때(1990년대에) 그것은 원칙으로 간주되지 않았지만(사실 그것은 단순히 처음 세 개에서 따랐기 때문임), 기사(아래 링크 참조)에서는 다음과 같습니다. 그것에 대해 작성되었지만 기사 제목에는 없으며 3) 만 있습니다.
실제 사용에서 이것은 "빈" 기본 클래스를 만드는 것입니다(메소드가 선언되었지만 아무 작업도 수행하지 않음). 일부 언어에서는 메서드를 abstract 로 표시할 수 있습니다. 즉, 자손 클래스에서는 재정의 해야 합니다(즉, 어떤 작업을 수행하는 메서드가 추가됨).
====================
추신: 간단히 말해서, 야생에 빠지지 않고 여기에서 읽을 수 있습니다.PPS: 누구의 기분을 상하게 하고 싶지는 않지만 Work에서 거래 라이브러리 작성을 요청했을 때 단 한 사람만이 가지고 있고 사용하고 있다고 대답했습니다.
5 MQL 프로그래머(Skype에서)는 그 안에 무엇이 들어 있어야 하는지 전혀 모르고 올빼미 중 하나에서 다른 올빼미로 필요한 기능을 복사하여 붙여넣었다고 말했습니다. 실제로는 아무 것도 변경하지 않고 몇 밀리초 이상 실행할 수 없는 코드 섹션 사이에 RefreshRates() 를 붙입니다. 그리고 다음 코드는 변경된 Ask 및 Bid 및 (아마도 변경된 주문 유형) 어떤 식으로든 의존하지 않습니다.
따라서 이전에 다른 프로그래밍 언어의 OOP로 작업한 적이 없는 MQL 프로그래머에게는 MQL의 OOP가 아무런 이점이 없습니다. 최대한 - 외부 변경으로부터 데이터를 숨깁니다(이것도 나쁘지 않음).
OOP의 3가지 원칙:
1) 캡슐화 . 저것들. 객체 자체에 변수, 유사 변수("객체 속성" 또는 간단히 "속성"이라고 함)를 저장합니다. 저것들. 클래스가 적절하게 선언되면 해당 데이터는
2) 상속 . 자손 클래스를 생성할 때 조상 클래스의 모든 필드와 메소드를 상속합니다.
3) 다형성 . 위에 제가 쓴 글은 자손 클래스에서 재작업한 openorders() 함수가 예전 Buy() 함수 등에 의해 조용히 호출될 때입니다.
다형성의 예는 다른 그림에 대한 기하학적 그림의 면적 계산입니다.
원의 경우 한 가지 방법으로, 정사각형의 경우 다른 방법으로 계산됩니다. 그러나 어떤 경우에도 - Figura.GetSquare() 를 호출하면 기본 클래스에서 상속된 특정 그림의 면적을 얻을 수 있습니다 (Square() 선언을 잊지 않은 경우).
네번째는 어디에?! 추상화는 어디에! 과분하게 잊혀진 :-(
추가하다.