일반적으로이 모든 것이 클래스 작업을 어렵게 만들지 않고 사용하지 말고 모든 것을 공개적으로 작성하십시오. , 그러면 파악하기가 더 쉬울 것입니다.
추신: OOP에 대한 많은 아름다운 문구, 캡슐화, 상속 ... 다 좋지만 다른 프로그래밍 스타일에 비해 OOP의 가장 중요한 장점은 모든 데이터(클래스 필드) 및 이 데이터 작업을 위한 함수의 저장입니다. (클래스 메소드) 한 곳에서 (클래스) - 책에 따르면 이것은 캡슐화입니다. 또한 OOP의 사용은 작업에 따라 다릅니다. 작업에서 클래스를 확장할 수 있는 경우 계층 구조가 필요하고 기본 클래스와 상속인이 있습니다. 사용 여부는 사용자에 따라 다릅니다.
배열은 개체의 모든 속성을 "캡슐화"할 수도 있습니다. 같은 장소에서 구체적인 속성 포인터를 통해 객체 간의 통신을 등록하는 것이 가능합니다. 각 속성이 인덱싱되고 해당 값이 특정 셀에 저장되기 때문에 순서가 있습니다. 객체 자체는 커널에 캡슐화됩니다. 가장 쉬운 액세스는 개체 번호와 속성 번호를 사용하는 것입니다. 포인터 속성을 통해 동일한 컨트롤의 개체 간 전환.
Реter Konow : 배열은 또한 개체의 모든 속성을 "캡슐화"할 수 있습니다. 같은 장소에서 구체적인 속성 포인터를 통해 객체 간의 통신을 등록하는 것이 가능합니다. 각 속성이 인덱싱되고 해당 값이 특정 셀에 저장되기 때문에 순서가 있습니다. 객체 자체는 커널에 캡슐화됩니다. 가장 쉬운 액세스는 개체 번호와 속성 번호를 사용하는 것입니다. 포인터 속성을 통해 동일한 컨트롤의 개체 간 전환.
그것은 처음부터 편리하지 않습니다!
또한 위에서 이미 코드의 가독성에 대해 썼습니다(위에서 언급했듯이 속도 - 실행 속도는 프로그래밍 스타일이 아닌 다른 것에 달려 있음)
여기, 일반적으로 다른 곳과 마찬가지로 - 시도하지 않으면 알 수 없습니다. OOP 스타일로 쓰기 시작하면 특정 작업과 특정 질문이 나타납니다 . 예는 이미 이 주제에 있습니다.
AI에 대해 이야기하는 경우 여기에서 작업과 데이터를 분리해야 합니다. OOP를 사용하면 이 작업을 수행하는 것이 더 쉬울 것입니다.
추신: 더 나은 OOP는 예를 들면: 다양한 유형의 데이터가 있고 MQL의 전문가 설정이 되도록 하고 이러한 설정이 블록 단위로 반복되도록 하고 하나의 설정 블록을 사용하여 클래스 필드를 설명합니다. 이러한 설정을 클래스로 전송하는 가장 쉬운 방법은 매개변수가 있는 생성자를 만든 다음 이러한 전문가 설정과 함께 작동하는 메서드를 작성하는 것입니다. 이 작업을 마치면 우리는 모두 클래스 인스턴스의 배열을 만들거나 일반적으로 여러 클래스 인스턴스("클래스 유형의 변수")만 생성하면 됩니다. 이 작업은 여러 배열을 생성하지 않고 하나의 클래스를 작성하여 해결됩니다. 각 배열을 식별하는 방법을 만들고, 배열에서 데이터를 변경하기 위해, 그리고 가장 중요한 것은 이 호출 중에 처리되어서는 안 되는 데이터를 망치지 않도록 하기 위한 함수 그룹을 생성할 뿐만 아니라 ....
ZYZY: IMHO, OOP는 그냥 편리합니다. 상속이 없으면 OOP를 사용하지 않는다는 특정 전설이 있습니다 ... 댓글을 알고 있습니다. 나 없이는 입에 거품이 일고 논쟁이 될 것입니다.
또한 위에서 이미 코드의 가독성에 대해 썼습니다(위에서 언급했듯이 속도 - 실행 속도는 프로그래밍 스타일이 아닌 다른 것에 달려 있음)
여기, 일반적으로 다른 곳과 마찬가지로 - 시도하지 않으면 알 수 없습니다. OOP 스타일로 쓰기 시작하면 특정 작업과 특정 질문이 나타납니다 . 예는 이미 이 주제에 있습니다.
AI에 대해 이야기하는 경우 여기에서 작업과 데이터를 분리해야 합니다. OOP를 사용하면 이 작업을 수행하는 것이 더 쉬울 것입니다.
추신: 더 나은 OOP는 예를 들면: 다양한 유형의 데이터가 있고 MQL의 전문가 설정이 되도록 하고 이러한 설정이 블록 단위로 반복되도록 하고 하나의 설정 블록을 사용하여 클래스 필드를 설명합니다. 이러한 설정을 클래스로 전송하는 가장 쉬운 방법은 매개변수가 있는 생성자를 만든 다음 이러한 전문가 설정과 함께 작동하는 메서드를 작성하는 것입니다. 이 작업을 마치면 우리는 모두 클래스 인스턴스의 배열을 만들거나 일반적으로 여러 클래스 인스턴스("클래스 유형의 변수")만 생성하면 됩니다. 이 작업은 여러 배열을 생성하지 않고 하나의 클래스를 작성하여 해결됩니다. 각 배열을 식별하는 방법을 만들고, 배열에서 데이터를 변경하기 위해, 그리고 가장 중요한 것은 이 호출 중에 처리되어서는 안 되는 데이터를 망치지 않도록 하기 위한 함수 그룹을 생성할 뿐만 아니라 ....
ZYZY: IMHO, OOP는 그냥 편리합니다. 상속이 없으면 OOP를 사용하지 않는다는 특정 전설이 있습니다 ... 댓글을 알고 있습니다. 나 없이는 입에 거품이 일고 논쟁이 될 것입니다.
편리한지 아닌지, 주관적인 질문입니다. 나는 데이터의 표 형식 레이아웃에 더 가깝습니다. 기타 - 포도 한 송이 또는 나무 형태. 세 번째 - 그런 것 ... 하지만, 나는 당신의 말에 대해 진지하게 생각하고 OOP에서 데이터 작업의 기본 원칙을 배우려고 노력할 것입니다.
Реter Konow : 편리한지 아닌지, 주관적인 질문입니다. 나는 데이터의 표 형식 레이아웃에 더 가깝습니다. 기타 - 포도 한 송이 또는 나무 형태. 세 번째 - 그런 것 ... 하지만, 나는 당신의 말에 대해 진지하게 생각하고 OOP에서 데이터 작업의 기본 원칙을 배우려고 노력할 것입니다.
포인터 배열에 대한 포인터 배열이 2차원 테이블이라고 말한 적이 있습니다. 하나의 목록 - 행, 첫 번째 열에 있는 목록. 그들만의 목록이 있을 수 있습니다. 그리고 일몰까지 계속됩니다. 이것은 당신이 찾고 있는 계층 구조입니다. 그리고 그것은 하나의 클래스에 의해 수행됩니다.
OOP에서 "객체"는 해당 필드(속성)가 선언된 클래스에 대한 참조입니다. 개체는 각각 배열의 셀인 번호가 지정된 속성 집합을 의미합니다. 이것이 차이점입니다.
Peter, 클래스 자체를 정의할 때 클래스 내부에 다른 클래스의 인스턴스가 속성으로 있어도 메모리가 할당되지 않는다는 점을 분명히 이해해야 합니다. 따라서 클래스에 대한 참조는 있을 수 없으며 클래스 개체만 참조할 수 있습니다. 메모리 할당 은 클래스의 인스턴스(객체)가 선언(생성)될 때 발생합니다.
추신 즉. 프로그램에 클래스가 있지만 인스턴스가 없는 경우 컴파일러는 이 클래스를 무시합니다(알지 못함).
ZYY 한 가지 예외가 있습니다. 정적 메서드 및 매개변수(있는 경우)에 대한 클래스를 정의할 때 메모리를 할당할 수 있습니다.
Artyom Trishkin : 포인터 배열에 대한 포인터 배열이 2차원 테이블이라고 말한 적이 있습니다. 하나의 목록 - 행, 첫 번째 열에 있는 목록. 그들만의 목록이 있을 수 있습니다. 해가 질 때까지 계속됩니다. 이것은 당신이 찾고 있는 계층 구조입니다. 그리고 그것은 하나의 클래스에 의해 수행됩니다.
이론상 그렇습니다. 그러나 계층 구조의 링크(조건부 - 귀납 및 연역, 즉 특정에서 일반으로 또는 그 반대로) 간의 전환이 체인을 따라 수행되도록 모든 것이 구성되어야 합니다. 즉, 포인터의 순서는 루프에서 불필요한 "회전" 및 "점프" 없이 모든 (올바른) 방향으로 이동할 수 있도록 특별한 방식으로 구성되어야 합니다. 따라서 포인터의 간단한 표 형식 레이아웃은 작동하지 않을 수 있습니다.
좋아요, 이것은 작동하는 코드입니다. 하지만 2개의 시간 프레임에 새 막대를 정의해야 하는 경우 어떻게 해야 합니까? 터미널에서 모든 TF를 사용하려면?
OOP에서는 다음과 같을 것입니다.
이제 CNewbar 클래스의 여러 인스턴스를 선언하기만 하면 됩니다. 어떻게? 최소한 배열에서는 최소한 몇 개의 변수가 있지만 OOP를 사용하여 우발적인 변경으로부터 데이터를 즉시 보호했습니다.
나는 이미 이 문제를 공개적으로 해결했습니다. 결론은 모든 기호와 모든 시간대에 대한 테이블이 생성되고 이를 통해 루프에서 새 막대의 이벤트가 기록된다는 것입니다. 이 이벤트의 기능에 대한 첫 번째 요청 후 해당 플래그는 테이블에서 지워집니다. OOP보다 얼마나 더 어려운지 - 판단하지 않습니다. 그러나 실제로는 상당히 간단하고 편리한 솔루션입니다.
Nikolai Semko : Peter, 클래스 자체를 정의할 때 클래스 내부에 다른 클래스의 인스턴스가 속성으로 있어도 메모리가 할당되지 않는다는 점을 분명히 이해해야 합니다. 따라서 클래스에 대한 참조는 있을 수 없으며 클래스 개체만 참조할 수 있습니다. 메모리 할당 은 클래스의 인스턴스(객체)가 선언(생성)될 때 발생합니다.
추신 즉. 프로그램에 클래스가 있지만 인스턴스가 없는 경우 컴파일러는 이 클래스를 무시합니다(알지 못함).
몰랐다. 흥미로운. 문제는 OOP를 사용하면 계층 구조의 모든 데이터를 주기로 작업하는 것이 얼마나 쉬워질 것인가 하는 것입니다. 사이클은 모든 엔진의 주요 메커니즘입니다. 주기가 더 잘 작동할수록 더 많은 데이터를 삽질하고 더 많은 작업을 수행할 수 있습니다.
클래스 객체를 생성할 때 클래스의 모든 속성(변수)에 대한 메모리 할당 외에도 생성자 중 하나가 시작됩니다(둘 이상이 있을 수 있음). 생성자는 매개변수가 없거나(기본적으로) 매개변수(클래스의 인스턴스를 생성할 때 일부 매개변수가 지정되는 경우) 또는 클래스의 다른 인스턴스가 클래스 인스턴스의 매개변수로 지정된 경우 복사 생성자가 될 수 있습니다.
Реter Konow : 이론적으로 그렇습니다. 그러나 계층 구조의 링크(조건부 - 귀납 및 연역, 즉 특정에서 일반으로 또는 그 반대로) 간의 전환이 체인을 따라 수행되도록 모든 것이 구성되어야 합니다. 즉, 포인터의 순서는 루프에서 불필요한 "회전" 및 "점프" 없이 모든 (올바른) 방향으로 이동할 수 있도록 특별한 방식으로 구성되어야 합니다. 따라서 포인터의 간단한 표 형식 레이아웃은 작동하지 않을 수 있습니다.
모든 목록에는 이미 이진 검색 이 부여되어 있습니다. 그리고 이것은 순차적인 열거가 아니라 원하는 속성으로 필터링하는 것을 의미합니다. 결과적으로 원하는 요소의 인덱스를 얻습니다.
액세스 수정자를 사용하면 컴파일 시간에 오류를 감지할 수 있습니다.
일반적으로이 모든 것이 클래스 작업을 어렵게 만들지 않고 사용하지 말고 모든 것을 공개적으로 작성하십시오. , 그러면 파악하기가 더 쉬울 것입니다.
추신: OOP에 대한 많은 아름다운 문구, 캡슐화, 상속 ... 다 좋지만 다른 프로그래밍 스타일에 비해 OOP의 가장 중요한 장점은 모든 데이터(클래스 필드) 및 이 데이터 작업을 위한 함수의 저장입니다. (클래스 메소드) 한 곳에서 (클래스) - 책에 따르면 이것은 캡슐화입니다. 또한 OOP의 사용은 작업에 따라 다릅니다. 작업에서 클래스를 확장할 수 있는 경우 계층 구조가 필요하고 기본 클래스와 상속인이 있습니다. 사용 여부는 사용자에 따라 다릅니다.
배열은 또한 개체의 모든 속성을 "캡슐화"할 수 있습니다. 같은 장소에서 구체적인 속성 포인터를 통해 객체 간의 통신을 등록하는 것이 가능합니다. 각 속성이 인덱싱되고 해당 값이 특정 셀에 저장되기 때문에 순서가 있습니다. 객체 자체는 커널에 캡슐화됩니다. 가장 쉬운 액세스는 개체 번호와 속성 번호를 사용하는 것입니다. 포인터 속성을 통해 동일한 컨트롤의 개체 간 전환.
그것은 처음부터 편리하지 않습니다!
또한 위에서 이미 코드의 가독성에 대해 썼습니다(위에서 언급했듯이 속도 - 실행 속도는 프로그래밍 스타일이 아닌 다른 것에 달려 있음)
여기, 일반적으로 다른 곳과 마찬가지로 - 시도하지 않으면 알 수 없습니다. OOP 스타일로 쓰기 시작하면 특정 작업과 특정 질문이 나타납니다 . 예는 이미 이 주제에 있습니다.
AI에 대해 이야기하는 경우 여기에서 작업과 데이터를 분리해야 합니다. OOP를 사용하면 이 작업을 수행하는 것이 더 쉬울 것입니다.
추신: 더 나은 OOP는 예를 들면: 다양한 유형의 데이터가 있고 MQL의 전문가 설정이 되도록 하고 이러한 설정이 블록 단위로 반복되도록 하고 하나의 설정 블록을 사용하여 클래스 필드를 설명합니다. 이러한 설정을 클래스로 전송하는 가장 쉬운 방법은 매개변수가 있는 생성자를 만든 다음 이러한 전문가 설정과 함께 작동하는 메서드를 작성하는 것입니다. 이 작업을 마치면 우리는 모두 클래스 인스턴스의 배열을 만들거나 일반적으로 여러 클래스 인스턴스("클래스 유형의 변수")만 생성하면 됩니다. 이 작업은 여러 배열을 생성하지 않고 하나의 클래스를 작성하여 해결됩니다. 각 배열을 식별하는 방법을 만들고, 배열에서 데이터를 변경하기 위해, 그리고 가장 중요한 것은 이 호출 중에 처리되어서는 안 되는 데이터를 망치지 않도록 하기 위한 함수 그룹을 생성할 뿐만 아니라 ....
ZYZY: IMHO, OOP는 그냥 편리합니다. 상속이 없으면 OOP를 사용하지 않는다는 특정 전설이 있습니다 ... 댓글을 알고 있습니다. 나 없이는 입에 거품이 일고 논쟁이 될 것입니다.
그것은 처음부터 편리하지 않습니다!
또한 위에서 이미 코드의 가독성에 대해 썼습니다(위에서 언급했듯이 속도 - 실행 속도는 프로그래밍 스타일이 아닌 다른 것에 달려 있음)
여기, 일반적으로 다른 곳과 마찬가지로 - 시도하지 않으면 알 수 없습니다. OOP 스타일로 쓰기 시작하면 특정 작업과 특정 질문이 나타납니다 . 예는 이미 이 주제에 있습니다.
AI에 대해 이야기하는 경우 여기에서 작업과 데이터를 분리해야 합니다. OOP를 사용하면 이 작업을 수행하는 것이 더 쉬울 것입니다.
추신: 더 나은 OOP는 예를 들면: 다양한 유형의 데이터가 있고 MQL의 전문가 설정이 되도록 하고 이러한 설정이 블록 단위로 반복되도록 하고 하나의 설정 블록을 사용하여 클래스 필드를 설명합니다. 이러한 설정을 클래스로 전송하는 가장 쉬운 방법은 매개변수가 있는 생성자를 만든 다음 이러한 전문가 설정과 함께 작동하는 메서드를 작성하는 것입니다. 이 작업을 마치면 우리는 모두 클래스 인스턴스의 배열을 만들거나 일반적으로 여러 클래스 인스턴스("클래스 유형의 변수")만 생성하면 됩니다. 이 작업은 여러 배열을 생성하지 않고 하나의 클래스를 작성하여 해결됩니다. 각 배열을 식별하는 방법을 만들고, 배열에서 데이터를 변경하기 위해, 그리고 가장 중요한 것은 이 호출 중에 처리되어서는 안 되는 데이터를 망치지 않도록 하기 위한 함수 그룹을 생성할 뿐만 아니라 ....
ZYZY: IMHO, OOP는 그냥 편리합니다. 상속이 없으면 OOP를 사용하지 않는다는 특정 전설이 있습니다 ... 댓글을 알고 있습니다. 나 없이는 입에 거품이 일고 논쟁이 될 것입니다.
편리한지 아닌지, 주관적인 질문입니다. 나는 데이터의 표 형식 레이아웃에 더 가깝습니다. 기타 - 포도 한 송이 또는 나무 형태. 세 번째 - 그런 것 ... 하지만, 나는 당신의 말에 대해 진지하게 생각하고 OOP에서 데이터 작업의 기본 원칙을 배우려고 노력할 것입니다.
OOP에서 "객체"는 해당 필드(속성)가 선언된 클래스에 대한 참조입니다. 개체는 각각 배열의 셀인 번호가 지정된 속성 집합을 의미합니다. 이것이 차이점입니다.
추신 즉. 프로그램에 클래스가 있지만 인스턴스가 없는 경우 컴파일러는 이 클래스를 무시합니다(알지 못함).
포인터 배열에 대한 포인터 배열이 2차원 테이블이라고 말한 적이 있습니다. 하나의 목록 - 행, 첫 번째 열에 있는 목록. 그들만의 목록이 있을 수 있습니다. 해가 질 때까지 계속됩니다. 이것은 당신이 찾고 있는 계층 구조입니다. 그리고 그것은 하나의 클래스에 의해 수행됩니다.
이론상 그렇습니다. 그러나 계층 구조의 링크(조건부 - 귀납 및 연역, 즉 특정에서 일반으로 또는 그 반대로) 간의 전환이 체인을 따라 수행되도록 모든 것이 구성되어야 합니다. 즉, 포인터의 순서는 루프에서 불필요한 "회전" 및 "점프" 없이 모든 (올바른) 방향으로 이동할 수 있도록 특별한 방식으로 구성되어야 합니다. 따라서 포인터의 간단한 표 형식 레이아웃은 작동하지 않을 수 있습니다.
추가됨:
하지만 맞을 수도 있습니다. 나는 아직 모른다.
이러한 질문은 실용적인 평면으로 번역되어야 합니다. 그렇지 않으면 무엇이 편리하고 무엇이 불편해 보이는지 명확하지 않을 것입니다))))
다음은 MQL에서 수백 번 사용되는 진부한 예입니다 - 새 막대의 정의:
좋아요, 이것은 작동하는 코드입니다. 하지만 2개의 시간 프레임에 새 막대를 정의해야 하는 경우 어떻게 해야 합니까? 터미널에서 모든 TF를 사용하려면?
OOP에서는 다음과 같을 것입니다.
이제 CNewbar 클래스의 여러 인스턴스를 선언하기만 하면 됩니다. 어떻게? 최소한 배열에서는 최소한 몇 개의 변수가 있지만 OOP를 사용하여 우발적인 변경으로부터 데이터를 즉시 보호했습니다.
나는 이미 이 문제를 공개적으로 해결했습니다. 결론은 모든 기호와 모든 시간대에 대한 테이블이 생성되고 이를 통해 루프에서 새 막대의 이벤트가 기록된다는 것입니다. 이 이벤트의 기능에 대한 첫 번째 요청 후 해당 플래그는 테이블에서 지워집니다. OOP보다 얼마나 더 어려운지 - 판단하지 않습니다. 그러나 실제로는 상당히 간단하고 편리한 솔루션입니다.
Peter, 클래스 자체를 정의할 때 클래스 내부에 다른 클래스의 인스턴스가 속성으로 있어도 메모리가 할당되지 않는다는 점을 분명히 이해해야 합니다. 따라서 클래스에 대한 참조는 있을 수 없으며 클래스 개체만 참조할 수 있습니다. 메모리 할당 은 클래스의 인스턴스(객체)가 선언(생성)될 때 발생합니다.
이론적으로 그렇습니다. 그러나 계층 구조의 링크(조건부 - 귀납 및 연역, 즉 특정에서 일반으로 또는 그 반대로) 간의 전환이 체인을 따라 수행되도록 모든 것이 구성되어야 합니다. 즉, 포인터의 순서는 루프에서 불필요한 "회전" 및 "점프" 없이 모든 (올바른) 방향으로 이동할 수 있도록 특별한 방식으로 구성되어야 합니다. 따라서 포인터의 간단한 표 형식 레이아웃은 작동하지 않을 수 있습니다.