Nikolai Semko : 클래스 객체를 생성할 때 클래스의 모든 속성(변수)에 대한 메모리 할당 외에도 생성자 중 하나가 시작됩니다(둘 이상이 있을 수 있음). 생성자는 매개변수가 없거나(기본적으로) 매개변수(클래스의 인스턴스를 생성할 때 일부 매개변수가 지정되는 경우) 또는 클래스의 다른 인스턴스가 클래스 인스턴스의 매개변수로 지정된 경우 복사 생성자가 될 수 있습니다.
나는 이미 이 문제를 공개적으로 해결했습니다. 결론은 모든 기호와 모든 시간대에 대한 테이블이 생성되고 이를 통해 루프에서 새 막대의 이벤트가 기록된다는 것입니다. 이 이벤트의 기능에 대한 첫 번째 요청 후 해당 플래그는 테이블에서 지워집니다. OOP보다 얼마나 더 어려운지 - 판단하지 않습니다. 그러나 실제로는 상당히 간단하고 편리한 솔루션입니다.
위에 쓰신 것처럼 모든 것이 상대적입니다 .... 클립의 마지막 장면을 사용합니다 ...
MT가 나왔을 때 의 표준 라이브러리 를 보셨나요? 모든 것이 OOP 스타일로 되어 있으며 2가지 옵션이 있습니다. 또는 Metaquot 프로그래머는 전문가이고 이해할 수 있는 스타일을 사용하거나 ... 귀하의 옵션입니다.)
MT가 나왔을 때 의 표준 라이브러리 를 보셨나요? 모든 것이 OOP 스타일로 되어 있으며 2가지 옵션이 있습니다. 또는 Metaquot 프로그래머는 전문가이고 이해할 수 있는 스타일을 사용하거나 ... 귀하의 옵션입니다.)
저는 아직 OOP에 대해 잘 모릅니다. 그들은 목록에 대해 나에게 말하지만, 나는 그들이 무엇을 "먹는지" 모릅니다. 선언 방법, 액세스 방법, 변경 방법 등 ... 나에게 목록은 추가 요소가 없는 동적 배열일 뿐입니다. 통사론. 객체는 배열의 속성 집합입니다. OOP에서 Object는 전체 클래스입니다. 상속 - 객체의 연결. 명명된 참조를 통해 개체 속성에 액세스합니다. 뿐만 아니라 그의 방법. 일반적으로 모든 것이 훨씬 간단하므로 가능성과 효과를 비교하는 것은 여전히 어렵습니다. 더 깊이 파고들 필요가 있습니다.
하지만 한 가지는 이해했습니다. OOP 전체를 이해하지 않고 OOP로 완전히 전환하지 않고 OOP의 개념에서 하나의 본질을 이해하고 사용하는 것은 불가능합니다. OOP 또는 원하는 모든 것. 편리한 메커니즘 중 하나를 사용하는 것만으로는 작동하지 않을 수 있습니다.
OOP의 절차적 스타일과 문제 없이 공존하지만 함수는 완전히 분리되고 독립적인 코드 블록이 실행되어야 합니다. 함수가 사용하는 모든 것이 그 안에 있거나 매개변수로 전달되어야 합니다.
일반적으로 Wiki에서 작성하는 것처럼 OOP는 절차 스타일의 연속입니다.
피터 코노우 :
하지만 한 가지는 이해했습니다. OOP 전체를 이해하지 않고 OOP로 완전히 전환하지 않고 OOP의 개념에서 하나의 본질을 이해하고 사용하는 것은 불가능합니다.
당신은 할 수 있습니다. 예를 들었고 포럼에서 OOP 스타일의 소스 중 90%는 절차적 스타일을 둘러싼 래퍼입니다. 상속, 추상화, ..... 아무것도, 그냥 캡슐화, 하지만 여전히 가장 덜 편리합니다. 다른 작업에 완전히 이식 가능한 코드를 갖는 것이 편리합니다. 결국 모든 것이 클래스 안에 있습니까? ;)
OOP의 절차적 스타일과 문제 없이 공존하지만 함수는 완전히 분리되고 독립적인 코드 블록이 실행되어야 합니다. 함수가 사용하는 모든 것이 그 안에 있거나 매개변수로 전달되어야 합니다.
일반적으로 Wiki에서 작성하는 것처럼 OOP는 절차 스타일의 연속입니다.
당신은 할 수 있습니다. 예를 들었고 포럼에서 OOP 스타일 소스의 90%는 절차적 스타일을 둘러싼 래퍼입니다. 상속, 추상화, ..... 아무것도, 캡슐화만 가능하지만 여전히 적어도 편리합니다. - 완전히 이식 가능한 코드 조각을 다른 작업에 두는 것이 편리합니다. 결국 모든 것이 클래스 안에 있습니까? ;)
예, 코드 이식성은 OOP의 큰 장점입니다. 제 경우에는 개별 기능만 이식 가능하지만(드문 경우에는) 큰 메커니즘을 구축하면 더 이상 이식 가능한 것이 없습니다. 인간의 장기가 얼마나 견딜 수 없는지(전문적인 개입 없이). 내 메커니즘은 각각 많은 작업을 수행하는 큰 블록으로 나누어져 있다는 점에서 "유기체"와 비슷합니다. 따라서 이식성은 거의 존재하지 않습니다. 그러나 반면에 이러한 블록은 기능을 매우 쉽게 증가시킵니다. 그것은 단지 몇 줄과 짜잔에서 "증가"됩니다! - 블록은 새로운 작업의 전체 계층을 수행하므로 많은 개별 기능을 작성해야 합니다. 일반적으로 플러스가 있습니다. 글쎄요, 글로벌 스코프는 엄청나게 강력한 도구입니다. 블록이 작동하는 재료는 절대적으로 사용할 수 있으며 아무 것도 전송할 필요가 없습니다. 작업에 필요한 모든 것이 이미 있습니다. 일반적으로 접근 방식은 다르며 각각 고유한 장점이 있습니다.
저는 아직 OOP에 대해 잘 모릅니다. 그들은 목록에 대해 나에게 말하지만, 나는 그들이 무엇을 "먹는지" 모릅니다. 선언 방법, 액세스 방법, 변경 방법 등 ... 나에게 목록은 추가 요소가 없는 동적 배열일 뿐입니다. 통사론. 객체는 배열의 속성 집합입니다. OOP에서 Object는 전체 클래스입니다. 상속 - 객체의 연결. 명명된 참조를 통해 개체 속성에 액세스합니다. 뿐만 아니라 그의 방법. 일반적으로 모든 것이 훨씬 간단하므로 가능성과 효과를 비교하는 것은 여전히 어렵습니다. 더 깊이 파고들 필요가 있습니다.
하지만 한 가지는 이해했습니다. OOP 전체를 이해하고 완전히 전환하지 않고는 OOP의 개념에서 하나의 본질을 이해하고 사용하는 것은 불가능합니다. OOP 또는 원하는 모든 것. 편리한 메커니즘 중 하나를 사용하는 것만으로는 작동하지 않을 수 있습니다.
피터, 시도만 하면 돼. 그리고 상속, 캡슐화 및 다형성의 세 방향 모두에서 OOP의 모든 이점을 볼 수 있기 때문에 목록 구조에서 시도하는 것이 좋습니다.
상속으로 인해 목록 내부의 개체 작업을 위한 단일 인터페이스( 가상 기능 세트)가 있습니다. 개체는 기본 개체에서 상속된 단순하거나 복잡할 수 있습니다.
다형성으로 인해 이 단일 인터페이스를 사용하여 근본적으로 다른 객체로 작업할 수 있습니다.
캡슐화로 인해 이 인터페이스만 있고 구현의 미묘함에 액세스할 수 없으므로 아무 것도 망칠 수 없습니다. 또한 현재 존재하는 객체가 어떻게 작동하는지 뿐만 아니라 아직 작성되지 않은 객체가 코드와 상호 작용하는 방식도 확실히 알고 있습니다.
Реter Konow : 그리고 이 목록은 OOP 내부의 무언가에 첨부되어 있습니까? 즉, 그들은 어떤 종류의 "하중"을 당깁니까? 클래스, 생성자, 인터페이스...? 수업 환경에 통합되어 있지 않습니까?
사실, 목록은 배열에 매우 가깝습니다. 목록 유형 변수로 선언하거나 new 연산자를 사용하여 새 변수를 생성할 수 있습니다. 그러나 new의 경우 목록은 터미널 서브시스템에 의해 제어되지 않으며 작업이 끝나면 삭제해야 합니다. 그러나 그러한 목록이 다른 목록에 개체로 추가되면 추적할 필요가 없습니다.
글쎄요, 글로벌 스코프는 엄청나게 강력한 도구입니다. 블록이 작동하는 재료는 절대적으로 사용할 수 있으며 아무 것도 전송할 필요가 없습니다. 작업을 완료하는 데 필요한 모든 것이 이미 있습니다.
함수 또는 코드 섹션의 매개변수로 사용하기 위한 변수의 전역 범위에 대해 이야기하는 경우 .... IMHO 이것은 불가능한 숨겨진 버그를 얻을 수 있는 기능으로 이식성이 없는 코드를 얻는 가장 좋은 방법입니다. 미래에 감지
추신: 저는 MT4에서 이러한 어드바이저의 코드를 여러 번 수정했습니다. 처음에는 전역적으로 선언된 변수의 이름을 변경했습니다. 그런 다음 컴파일러 오류가 변경된 위치를 확인하고 마지막으로 스패팅을 하고 원래대로 수행했습니다. - 함수에 새 매개변수를 추가했습니다. 서명을 한 다음 전역 설명 변수를 제거했습니다. 그렇게 시작했기 때문입니다. 그런 산 코드를 한 번 수정하고 두 번째 호출을 기다렸다가 다시 반복하면 어떻게 될까요? -아아, 나는 게으르지만 합리적으로 게으르다)))))
함수 또는 코드 섹션의 매개변수로 사용하기 위한 변수의 전역 범위에 대해 이야기하는 경우 .... IMHO 이것은 불가능한 숨겨진 버그를 얻을 수 있는 기능으로 이식성이 없는 코드를 얻는 가장 좋은 방법입니다. 미래에 감지
추신: 저는 MT4에서 이러한 어드바이저의 코드를 여러 번 수정했습니다. 처음에는 전역적으로 선언된 변수의 이름을 변경했습니다. 그런 다음 컴파일러 오류가 변경된 위치를 확인하고 마지막으로 스패팅을 하고 원래대로 수행했습니다. - 함수에 새 매개변수를 추가했습니다. 서명을 한 다음 전역 설명 변수를 제거했습니다. 그렇게 시작했기 때문입니다. 그런 산 코드를 한 번 수정하고 두 번째 호출을 기다렸다가 다시 반복하면 어떻게 될까요? -아아, 나는 게으르지만 합리적으로 게으르다)))))
코드는 이식 가능하지 않으므로 이것이 그 기능입니다. 휴대하기 위한 것이 아닙니다. 다른 목적이 있습니다. 글쎄요, 변수의 전역 범위는 복잡한 메커니즘의 작동을 위한 강력한 도구입니다. 사용법만 알면 됩니다. 그리고 그들이 숨겨진 오류와 버그에 대해 나에게 말할 때 나는 길을 잃습니다. 변수의 전역 가시성과 관련된 버그가 없었습니다. 단어에서 전혀.
모든 목록에는 이미 이진 검색이 제공됩니다. 그리고 이것은 순차적인 열거가 아니라 원하는 속성으로 필터링하는 것을 의미합니다. 결과적으로 원하는 요소의 인덱스를 얻습니다.
클래스 객체를 생성할 때 클래스의 모든 속성(변수)에 대한 메모리 할당 외에도 생성자 중 하나가 시작됩니다(둘 이상이 있을 수 있음). 생성자는 매개변수가 없거나(기본적으로) 매개변수(클래스의 인스턴스를 생성할 때 일부 매개변수가 지정되는 경우) 또는 클래스의 다른 인스턴스가 클래스 인스턴스의 매개변수로 지정된 경우 복사 생성자가 될 수 있습니다.
나는 이미 이 문제를 공개적으로 해결했습니다. 결론은 모든 기호와 모든 시간대에 대한 테이블이 생성되고 이를 통해 루프에서 새 막대의 이벤트가 기록된다는 것입니다. 이 이벤트의 기능에 대한 첫 번째 요청 후 해당 플래그는 테이블에서 지워집니다. OOP보다 얼마나 더 어려운지 - 판단하지 않습니다. 그러나 실제로는 상당히 간단하고 편리한 솔루션입니다.
위에 쓰신 것처럼 모든 것이 상대적입니다 .... 클립의 마지막 장면을 사용합니다 ...
MT가 나왔을 때 의 표준 라이브러리 를 보셨나요? 모든 것이 OOP 스타일로 되어 있으며 2가지 옵션이 있습니다. 또는 Metaquot 프로그래머는 전문가이고 이해할 수 있는 스타일을 사용하거나 ... 귀하의 옵션입니다.)
위에 쓰신 것처럼 모든 것이 상대적입니다 .... 클립의 마지막 장면을 사용합니다 ...
MT가 나왔을 때 의 표준 라이브러리 를 보셨나요? 모든 것이 OOP 스타일로 되어 있으며 2가지 옵션이 있습니다. 또는 Metaquot 프로그래머는 전문가이고 이해할 수 있는 스타일을 사용하거나 ... 귀하의 옵션입니다.)
저는 아직 OOP에 대해 잘 모릅니다. 그들은 목록에 대해 나에게 말하지만, 나는 그들이 무엇을 "먹는지" 모릅니다. 선언 방법, 액세스 방법, 변경 방법 등 ... 나에게 목록은 추가 요소가 없는 동적 배열일 뿐입니다. 통사론. 객체는 배열의 속성 집합입니다. OOP에서 Object는 전체 클래스입니다. 상속 - 객체의 연결. 명명된 참조를 통해 개체 속성에 액세스합니다. 뿐만 아니라 그의 방법. 일반적으로 모든 것이 훨씬 간단하므로 가능성과 효과를 비교하는 것은 여전히 어렵습니다. 더 깊이 파고들 필요가 있습니다.
하지만 한 가지는 이해했습니다. OOP 전체를 이해하지 않고 OOP로 완전히 전환하지 않고 OOP의 개념에서 하나의 본질을 이해하고 사용하는 것은 불가능합니다. OOP 또는 원하는 모든 것. 편리한 메커니즘 중 하나를 사용하는 것만으로는 작동하지 않을 수 있습니다.
편리한 메커니즘 중 하나를 사용하는 것만으로는 작동하지 않을 수 있습니다.
OOP의 절차적 스타일과 문제 없이 공존하지만 함수는 완전히 분리되고 독립적인 코드 블록이 실행되어야 합니다. 함수가 사용하는 모든 것이 그 안에 있거나 매개변수로 전달되어야 합니다.
일반적으로 Wiki에서 작성하는 것처럼 OOP는 절차 스타일의 연속입니다.
하지만 한 가지는 이해했습니다. OOP 전체를 이해하지 않고 OOP로 완전히 전환하지 않고 OOP의 개념에서 하나의 본질을 이해하고 사용하는 것은 불가능합니다.
당신은 할 수 있습니다. 예를 들었고 포럼에서 OOP 스타일의 소스 중 90%는 절차적 스타일을 둘러싼 래퍼입니다. 상속, 추상화, ..... 아무것도, 그냥 캡슐화, 하지만 여전히 가장 덜 편리합니다. 다른 작업에 완전히 이식 가능한 코드를 갖는 것이 편리합니다. 결국 모든 것이 클래스 안에 있습니까? ;)
OOP의 절차적 스타일과 문제 없이 공존하지만 함수는 완전히 분리되고 독립적인 코드 블록이 실행되어야 합니다. 함수가 사용하는 모든 것이 그 안에 있거나 매개변수로 전달되어야 합니다.
일반적으로 Wiki에서 작성하는 것처럼 OOP는 절차 스타일의 연속입니다.
당신은 할 수 있습니다. 예를 들었고 포럼에서 OOP 스타일 소스의 90%는 절차적 스타일을 둘러싼 래퍼입니다. 상속, 추상화, ..... 아무것도, 캡슐화만 가능하지만 여전히 적어도 편리합니다. - 완전히 이식 가능한 코드 조각을 다른 작업에 두는 것이 편리합니다. 결국 모든 것이 클래스 안에 있습니까? ;)
예, 코드 이식성은 OOP의 큰 장점입니다. 제 경우에는 개별 기능만 이식 가능하지만(드문 경우에는) 큰 메커니즘을 구축하면 더 이상 이식 가능한 것이 없습니다. 인간의 장기가 얼마나 견딜 수 없는지(전문적인 개입 없이). 내 메커니즘은 각각 많은 작업을 수행하는 큰 블록으로 나누어져 있다는 점에서 "유기체"와 비슷합니다. 따라서 이식성은 거의 존재하지 않습니다. 그러나 반면에 이러한 블록은 기능을 매우 쉽게 증가시킵니다. 그것은 단지 몇 줄과 짜잔에서 "증가"됩니다! - 블록은 새로운 작업의 전체 계층을 수행하므로 많은 개별 기능을 작성해야 합니다. 일반적으로 플러스가 있습니다. 글쎄요, 글로벌 스코프는 엄청나게 강력한 도구입니다. 블록이 작동하는 재료는 절대적으로 사용할 수 있으며 아무 것도 전송할 필요가 없습니다. 작업에 필요한 모든 것이 이미 있습니다. 일반적으로 접근 방식은 다르며 각각 고유한 장점이 있습니다.
저는 아직 OOP에 대해 잘 모릅니다. 그들은 목록에 대해 나에게 말하지만, 나는 그들이 무엇을 "먹는지" 모릅니다. 선언 방법, 액세스 방법, 변경 방법 등 ... 나에게 목록은 추가 요소가 없는 동적 배열일 뿐입니다. 통사론. 객체는 배열의 속성 집합입니다. OOP에서 Object는 전체 클래스입니다. 상속 - 객체의 연결. 명명된 참조를 통해 개체 속성에 액세스합니다. 뿐만 아니라 그의 방법. 일반적으로 모든 것이 훨씬 간단하므로 가능성과 효과를 비교하는 것은 여전히 어렵습니다. 더 깊이 파고들 필요가 있습니다.
하지만 한 가지는 이해했습니다. OOP 전체를 이해하고 완전히 전환하지 않고는 OOP의 개념에서 하나의 본질을 이해하고 사용하는 것은 불가능합니다. OOP 또는 원하는 모든 것. 편리한 메커니즘 중 하나를 사용하는 것만으로는 작동하지 않을 수 있습니다.
피터, 시도만 하면 돼. 그리고 상속, 캡슐화 및 다형성의 세 방향 모두에서 OOP의 모든 이점을 볼 수 있기 때문에 목록 구조에서 시도하는 것이 좋습니다.
상속으로 인해 목록 내부의 개체 작업을 위한 단일 인터페이스( 가상 기능 세트)가 있습니다. 개체는 기본 개체에서 상속된 단순하거나 복잡할 수 있습니다.
다형성으로 인해 이 단일 인터페이스를 사용하여 근본적으로 다른 객체로 작업할 수 있습니다.
캡슐화로 인해 이 인터페이스만 있고 구현의 미묘함에 액세스할 수 없으므로 아무 것도 망칠 수 없습니다. 또한 현재 존재하는 객체가 어떻게 작동하는지 뿐만 아니라 아직 작성되지 않은 객체가 코드와 상호 작용하는 방식도 확실히 알고 있습니다.
그리고 이 목록은 OOP 내부의 무언가에 첨부되어 있습니까? 즉, 그들은 어떤 종류의 "하중"을 당깁니까? 클래스, 생성자, 인터페이스...? 수업 환경에 통합되어 있지 않습니까?
글쎄요, 글로벌 스코프는 엄청나게 강력한 도구입니다. 블록이 작동하는 재료는 절대적으로 사용할 수 있으며 아무 것도 전송할 필요가 없습니다. 작업을 완료하는 데 필요한 모든 것이 이미 있습니다.
함수 또는 코드 섹션의 매개변수로 사용하기 위한 변수의 전역 범위에 대해 이야기하는 경우 .... IMHO 이것은 불가능한 숨겨진 버그를 얻을 수 있는 기능으로 이식성이 없는 코드를 얻는 가장 좋은 방법입니다. 미래에 감지
추신: 저는 MT4에서 이러한 어드바이저의 코드를 여러 번 수정했습니다. 처음에는 전역적으로 선언된 변수의 이름을 변경했습니다. 그런 다음 컴파일러 오류가 변경된 위치를 확인하고 마지막으로 스패팅을 하고 원래대로 수행했습니다. - 함수에 새 매개변수를 추가했습니다. 서명을 한 다음 전역 설명 변수를 제거했습니다. 그렇게 시작했기 때문입니다. 그런 산 코드를 한 번 수정하고 두 번째 호출을 기다렸다가 다시 반복하면 어떻게 될까요? -아아, 나는 게으르지만 합리적으로 게으르다)))))
함수 또는 코드 섹션의 매개변수로 사용하기 위한 변수의 전역 범위에 대해 이야기하는 경우 .... IMHO 이것은 불가능한 숨겨진 버그를 얻을 수 있는 기능으로 이식성이 없는 코드를 얻는 가장 좋은 방법입니다. 미래에 감지
추신: 저는 MT4에서 이러한 어드바이저의 코드를 여러 번 수정했습니다. 처음에는 전역적으로 선언된 변수의 이름을 변경했습니다. 그런 다음 컴파일러 오류가 변경된 위치를 확인하고 마지막으로 스패팅을 하고 원래대로 수행했습니다. - 함수에 새 매개변수를 추가했습니다. 서명을 한 다음 전역 설명 변수를 제거했습니다. 그렇게 시작했기 때문입니다. 그런 산 코드를 한 번 수정하고 두 번째 호출을 기다렸다가 다시 반복하면 어떻게 될까요? -아아, 나는 게으르지만 합리적으로 게으르다)))))
코드는 이식 가능하지 않으므로 이것이 그 기능입니다. 휴대하기 위한 것이 아닙니다. 다른 목적이 있습니다. 글쎄요, 변수의 전역 범위는 복잡한 메커니즘의 작동을 위한 강력한 도구입니다. 사용법만 알면 됩니다. 그리고 그들이 숨겨진 오류와 버그에 대해 나에게 말할 때 나는 길을 잃습니다. 변수의 전역 가시성과 관련된 버그가 없었습니다. 단어에서 전혀.