하지만 ONE 클래스와 함께 작업할 때는 OOP를 사용합니다. 하지만 이것은 넌센스입니다.
Peter, OOP에서 클래스 객체는 서로 의존하지 않을 많은 객체와 함께 작업할 수 있도록 생성됩니다. CCanvas로 작업하고 하나의 차트만 있으면 모든 것이 정상입니다. 여기서 OOP는 실제로 필요하지 않습니다. 하지만 서로 다른 영역에 여러 그래프를 표시해야 하는 경우 OOP 없이는 이미 여러 CCanvas 인스턴스를 생성하기 어렵습니다.
또는 다른 예. 나는 최근에 동시에 여러 상품을 거래할 수 있도록 절차적 EA를 조정하라는 요청을 받았습니다(동일한 차트에서 시작됨). 절차적 스타일에서 그가 동시에 다른 기호에 대해 독립적으로 거래하도록 하려면 매우 길고 어려운 트릭이 필요합니다. 방금 모든 절차 코드를 클래스에 배치하고 세 개의 인스턴스를 만들었습니다. 각각에는 작업 기호 등을 포함하여 개별 설정 세트가 제공되었습니다. 코드는 처음처럼 작동했습니다. 사용자는 행복했습니다.
당신도 핵심에서 OOP를 사용합니다. 암시 적으로 수행하지만 :
피터 코노우 :
근거 없는 말을 하지 않기 위해 마지막으로 바로 그 "핵심"의 예를 들겠습니다. 보다 정확하게는 부트 파일입니다. 여러 코어가 있습니다.
KIB 코드를 기반으로 자동으로 인쇄됨을 알려드립니다. 그런 다음 엔진에 배치됩니다. 다음으로 엔진이 작동합니다.
각 코어는 OOP 용어로 클래스의 인스턴스입니다. 그리고 무엇이라고 부르든 그것은 OOP의 요소입니다. 그러나 불행하게도, 이 수제 요소는 수천 명의 최후의 사람들이 아닌 사람들이 이미 발명하고 연마한 것보다 개념적 강도가 열등합니다.
그를 설득하지 마십시오! 게다가, 당신이 그와 같은 기억을 가지고 있다면 - 당신 자신도 놀랄 것입니다 - 모든 것이 훨씬 더 쉽게 할 수 있다면 왜 여분의 OOP 제스처를 사용합니까? 우리는 모든 변수를 전역으로 만들고 어디에서나 직접 액세스할 수 있으며 금지 및 제한이 없습니다.
이것은 어리석음 때문에 10년 전에 작성한 것을 잊어버릴 수 있는 사람들을 위한 것입니다. 컴파일러와 언어는 가능한 모든 방법으로 이를 제한해야 합니다. 그리고 이미 몇 년이 지난 코드에서 이 구성 또는 저 구성을 작성한 이유와 이유를 정확히 기억할 때 OOP는 카트의 다섯 번째 바퀴일 뿐입니다.
Peter의 문제는 "OOP 또는 절차적 접근"의 선택에 전혀 있는 것이 아니라 Peter의 문제는 대상 고객에 있습니다. 한편으로는 프로그래밍에 정통하고 다른 한편으로는 손으로 거래하는 것을 선호하는 사람들이 없을 때. 나는 그것들을 보지 못한다.
1. 정확히. 생성자는 제한된 수의 요소를 가질 수 있습니다. 따라서 동적 테이블은 제한된 수의 행으로 구성되어야 하지만 동시에 무제한이어야 합니다. 유일한 해결책은 특별한 추가된 매개변수에 대한 배열 및 테이블 셀을 통해 해당 값 스크롤.
2. 네. 생성자는 제공한 코드를 기반으로 엔진용 커널을 생성합니다. + 연결 파일을 인쇄합니다. 그런 다음 커널을 엔진(DRIVE)에 배치합니다. 그 후 엔진은 원하는 GUI를 재생할 수 있습니다. 페어링 파일은 Expert Advisor에 연결되고 상호 작용을 시작합니다.
새로운 GUI를 만들 때마다 엔진을 변경해야 합니다(적절한 GUI 코어 제공). 이것은 근본적으로 잘못된 결정이라고 생각합니다. 수백 명의 엔진 사용자가 있다고 상상해보십시오. 그러나 시장이나 다른 곳에서 호스팅되는 엔진은 단 하나뿐입니다. 이 경우 어떻게 행동하시겠습니까? 각 사용자가 자신을 위해 다운로드해야 하는 특정 엔진을 배치하려면? 그리고 엔진용 GUI 커널을 어떻게 준비할 것인가? 각 사용자에게 개별 코어를 제공하시겠습니까? - 금세 악몽이 됩니다. 솔루션이 확장되지 않은 것으로 나타났습니다.
Peter, OOP에서 클래스 객체는 서로 의존하지 않을 많은 객체와 함께 작업할 수 있도록 생성됩니다. CCanvas로 작업하고 하나의 차트만 있으면 모든 것이 정상입니다. 여기서 OOP는 실제로 필요하지 않습니다. 하지만 서로 다른 영역에 여러 그래프를 표시해야 하는 경우 OOP 없이는 이미 여러 CCanvas 인스턴스를 생성하기 어렵습니다.
또는 다른 예. 나는 최근에 동시에 여러 상품을 거래할 수 있도록 절차적 EA를 조정하라는 요청을 받았습니다(동일한 차트에서 시작됨). 절차적 스타일에서 그가 동시에 다른 기호에 대해 독립적으로 거래하도록 하려면 매우 길고 어려운 트릭이 필요합니다. 방금 모든 절차 코드를 클래스에 배치하고 세 개의 인스턴스를 만들었습니다. 각각에는 작업 기호 등을 포함하여 개별 설정 세트가 제공되었습니다. 코드는 처음처럼 작동했습니다. 사용자는 행복했습니다.
당신도 핵심에서 OOP를 사용합니다. 암시 적으로 수행하지만 :
각 코어는 OOP 용어로 클래스의 인스턴스입니다. 그리고 무엇이라고 부르든 그것은 OOP의 요소입니다. 그러나 불행하게도, 이 수제 요소는 수천 명의 최후의 사람들이 아닌 사람들이 이미 발명하고 연마한 것보다 개념적 강도가 열등합니다.
Vasily, 나는 그리기 기능이 클래스에서 프레임되는 이유를 이해합니다. 그 외에도 다른 기능 세트가 있기 때문입니다.
하지만 질문은 조금 달랐다. 특히 Nikolai가 다른 클래스를 사용하지 않는 경우 클래스를 통해 그리기 함수에 대한 호출을 사용하는 이유는 무엇입니까? 그는 그림만 그릴 뿐입니다.
그것이 질문의 요지였습니다.
나는 이 행동의 무의미함을 논리적인 관점에서 강조했고, 자신도 이를 깨닫지 못하고 있다는 점을 강조했다.
나는 OOP의 사용 이 종종 해결되는 작업의 규모에 의해 정당화되지 않는다는 점을 강조했습니다. 결국 OOP는 확산 분류가 필요한데, 만약 존재하지 않는다면 특별히 만들 가치가 있을까?
Peter, OOP에서 클래스 객체는 서로 의존하지 않을 많은 객체와 함께 작업할 수 있도록 생성됩니다. CCanvas로 작업하고 하나의 차트만 있으면 모든 것이 정상입니다. 여기서 OOP는 실제로 필요하지 않습니다. 하지만 서로 다른 영역에 여러 그래프를 표시해야 하는 경우 OOP 없이는 이미 여러 CCanvas 인스턴스를 생성하기 어렵습니다.
또는 다른 예. 나는 최근에 동시에 여러 상품을 거래할 수 있도록 절차적 EA를 조정하라는 요청을 받았습니다(동일한 차트에서 시작됨). 절차적 스타일에서 그가 동시에 다른 기호에 대해 독립적으로 거래하도록 하려면 매우 길고 어려운 트릭이 필요합니다. 방금 모든 절차 코드를 클래스에 배치하고 세 개의 인스턴스를 만들었습니다. 각각에는 작업 기호 등을 포함하여 개별 설정 세트가 제공되었습니다. 코드는 처음처럼 작동했습니다. 사용자는 행복했습니다.
당신도 핵심에서 OOP를 사용합니다. 암시 적으로 수행하지만 :
각 코어는 OOP 용어로 클래스의 인스턴스입니다. 그리고 무엇이라고 부르든 그것은 OOP의 요소입니다. 그러나 불행하게도, 이 수제 요소는 수천 명의 최후의 사람들이 아닌 사람들이 이미 발명하고 연마한 것보다 개념적 강도가 열등합니다.
여기에서 당신은 헛된 구슬을 던지고 있습니다. 첫째, Perth 고문과 당신의 모범은 코끼리 찜질과 같습니다. 그는 전문가를 쓰는 방법을 모르고, 거기에 무엇이 있고 왜 있는지 이해하지 못하며, 당신의 예시적인 예를 이해할 수 없습니다. 그의 눈은 당신에게 니콜라스와 같은 말을 하기 시작할 것입니다. 둘째, 당신은 그 자신이 자신의 양동이에서 스스로, 수천 명의 이전 마음의 도움 없이 자신이 뛰어난 솔루션으로 더 나은 초 독특한 코드를 더 잘 만들었다고 말하면서 코를 더 높이 올릴 이유를 제공합니다. 이전 솔루션보다 이것이 바로 그가 밸브가 있는 독특한 버킷을 배치하는 방법입니다 ...
추신. 내가 거칠게 말했을 수도 있지만, 나는 정말로 꿰뚫을 수 없는 어리석음을 참을 수 없다.
새로운 GUI를 만들 때마다 엔진을 변경해야 합니다(적절한 GUI 코어 제공). 이것은 근본적으로 잘못된 결정이라고 생각합니다. 수백 명의 엔진 사용자가 있다고 상상해보십시오. 그러나 시장이나 다른 곳에서 호스팅되는 엔진은 단 하나뿐입니다. 이 경우 어떻게 행동하시겠습니까? 각 사용자가 자신을 위해 다운로드해야 하는 특정 엔진을 배치하려면? 그리고 엔진용 GUI 커널을 어떻게 준비할 것인가? 각 사용자에게 개별 코어를 제공하시겠습니까? - 금세 악몽이 됩니다. 솔루션이 확장되지 않은 것으로 나타났습니다.
"PLO 지지자들의 창조적 잠재력 확장", Vereshchagin, 캔버스에 유채
유익한 게시물에 모두 감사드립니다.
오늘 우리는 리소스를 통해 EA와 엔진 간의 연결을 테스트할 것입니다. 방금 완료되었습니다. 테스터에서도 작동해야 합니다.
당신은 CCanvas 클래스로 작업하고 있습니다. 그는 당신의 발전에 혼자입니다.
클래스는 시스템의 일부입니다. 그가 하나라면 시스템이 없습니다.
그렇다면 왜 OOP 규칙에 따라 클래스 객체 를 만들고 해당 기능에 액세스해야 할까요?
실제로 한 클래스에서 작업하는 데 OOP가 필요하지 않습니다.
하지만 ONE 클래스와 함께 작업할 때는 OOP를 사용합니다. 하지만 이것은 넌센스입니다.
Peter, OOP에서 클래스 객체는 서로 의존하지 않을 많은 객체와 함께 작업할 수 있도록 생성됩니다. CCanvas로 작업하고 하나의 차트만 있으면 모든 것이 정상입니다. 여기서 OOP는 실제로 필요하지 않습니다. 하지만 서로 다른 영역에 여러 그래프를 표시해야 하는 경우 OOP 없이는 이미 여러 CCanvas 인스턴스를 생성하기 어렵습니다.
또는 다른 예. 나는 최근에 동시에 여러 상품을 거래할 수 있도록 절차적 EA를 조정하라는 요청을 받았습니다(동일한 차트에서 시작됨). 절차적 스타일에서 그가 동시에 다른 기호에 대해 독립적으로 거래하도록 하려면 매우 길고 어려운 트릭이 필요합니다. 방금 모든 절차 코드를 클래스에 배치하고 세 개의 인스턴스를 만들었습니다. 각각에는 작업 기호 등을 포함하여 개별 설정 세트가 제공되었습니다. 코드는 처음처럼 작동했습니다. 사용자는 행복했습니다.
당신도 핵심에서 OOP를 사용합니다. 암시 적으로 수행하지만 :
근거 없는 말을 하지 않기 위해 마지막으로 바로 그 "핵심"의 예를 들겠습니다. 보다 정확하게는 부트 파일입니다. 여러 코어가 있습니다.
KIB 코드를 기반으로 자동으로 인쇄됨을 알려드립니다. 그런 다음 엔진에 배치됩니다. 다음으로 엔진이 작동합니다.
각 코어는 OOP 용어로 클래스의 인스턴스입니다. 그리고 무엇이라고 부르든 그것은 OOP의 요소입니다. 그러나 불행하게도, 이 수제 요소는 수천 명의 최후의 사람들이 아닌 사람들이 이미 발명하고 연마한 것보다 개념적 강도가 열등합니다.
여러분, Peter에게 OOP의 이점을 확신시키려는 것은 무엇입니까?
그를 설득하지 마십시오! 게다가, 당신이 그와 같은 기억을 가지고 있다면 - 당신 자신도 놀랄 것입니다 - 모든 것이 훨씬 더 쉽게 할 수 있다면 왜 여분의 OOP 제스처를 사용합니까? 우리는 모든 변수를 전역으로 만들고 어디에서나 직접 액세스할 수 있으며 금지 및 제한이 없습니다.
이것은 어리석음 때문에 10년 전에 작성한 것을 잊어버릴 수 있는 사람들을 위한 것입니다. 컴파일러와 언어는 가능한 모든 방법으로 이를 제한해야 합니다. 그리고 이미 몇 년이 지난 코드에서 이 구성 또는 저 구성을 작성한 이유와 이유를 정확히 기억할 때 OOP는 카트의 다섯 번째 바퀴일 뿐입니다.
Peter의 문제는 "OOP 또는 절차적 접근"의 선택에 전혀 있는 것이 아니라 Peter의 문제는 대상 고객에 있습니다. 한편으로는 프로그래밍에 정통하고 다른 한편으로는 손으로 거래하는 것을 선호하는 사람들이 없을 때. 나는 그것들을 보지 못한다.
1. 정확히. 생성자는 제한된 수의 요소를 가질 수 있습니다. 따라서 동적 테이블은 제한된 수의 행으로 구성되어야 하지만 동시에 무제한이어야 합니다. 유일한 해결책은 특별한 추가된 매개변수에 대한 배열 및 테이블 셀을 통해 해당 값 스크롤.
2. 네. 생성자는 제공한 코드를 기반으로 엔진용 커널을 생성합니다. + 연결 파일을 인쇄합니다. 그런 다음 커널을 엔진(DRIVE)에 배치합니다. 그 후 엔진은 원하는 GUI를 재생할 수 있습니다. 페어링 파일은 Expert Advisor에 연결되고 상호 작용을 시작합니다.
새로운 GUI를 만들 때마다 엔진을 변경해야 합니다(적절한 GUI 코어 제공). 이것은 근본적으로 잘못된 결정이라고 생각합니다. 수백 명의 엔진 사용자가 있다고 상상해보십시오. 그러나 시장이나 다른 곳에서 호스팅되는 엔진은 단 하나뿐입니다. 이 경우 어떻게 행동하시겠습니까? 각 사용자가 자신을 위해 다운로드해야 하는 특정 엔진을 배치하려면? 그리고 엔진용 GUI 커널을 어떻게 준비할 것인가? 각 사용자에게 개별 코어를 제공하시겠습니까? - 금세 악몽이 됩니다. 솔루션이 확장되지 않은 것으로 나타났습니다.
Peter, OOP에서 클래스 객체는 서로 의존하지 않을 많은 객체와 함께 작업할 수 있도록 생성됩니다. CCanvas로 작업하고 하나의 차트만 있으면 모든 것이 정상입니다. 여기서 OOP는 실제로 필요하지 않습니다. 하지만 서로 다른 영역에 여러 그래프를 표시해야 하는 경우 OOP 없이는 이미 여러 CCanvas 인스턴스를 생성하기 어렵습니다.
또는 다른 예. 나는 최근에 동시에 여러 상품을 거래할 수 있도록 절차적 EA를 조정하라는 요청을 받았습니다(동일한 차트에서 시작됨). 절차적 스타일에서 그가 동시에 다른 기호에 대해 독립적으로 거래하도록 하려면 매우 길고 어려운 트릭이 필요합니다. 방금 모든 절차 코드를 클래스에 배치하고 세 개의 인스턴스를 만들었습니다. 각각에는 작업 기호 등을 포함하여 개별 설정 세트가 제공되었습니다. 코드는 처음처럼 작동했습니다. 사용자는 행복했습니다.
당신도 핵심에서 OOP를 사용합니다. 암시 적으로 수행하지만 :
각 코어는 OOP 용어로 클래스의 인스턴스입니다. 그리고 무엇이라고 부르든 그것은 OOP의 요소입니다. 그러나 불행하게도, 이 수제 요소는 수천 명의 최후의 사람들이 아닌 사람들이 이미 발명하고 연마한 것보다 개념적 강도가 열등합니다.
Vasily, 나는 그리기 기능이 클래스에서 프레임되는 이유를 이해합니다. 그 외에도 다른 기능 세트가 있기 때문입니다.
하지만 질문은 조금 달랐다. 특히 Nikolai가 다른 클래스를 사용하지 않는 경우 클래스를 통해 그리기 함수에 대한 호출을 사용하는 이유는 무엇입니까? 그는 그림만 그릴 뿐입니다.
그것이 질문의 요지였습니다.
나는 이 행동의 무의미함을 논리적인 관점에서 강조했고, 자신도 이를 깨닫지 못하고 있다는 점을 강조했다.
나는 OOP의 사용 이 종종 해결되는 작업의 규모에 의해 정당화되지 않는다는 점을 강조했습니다. 결국 OOP는 확산 분류가 필요한데, 만약 존재하지 않는다면 특별히 만들 가치가 있을까?
요점은 개발자가 도구가 아닌 메커니즘의 요구 사항에 따라 안내된다는 것입니다.
Peter, OOP에서 클래스 객체는 서로 의존하지 않을 많은 객체와 함께 작업할 수 있도록 생성됩니다. CCanvas로 작업하고 하나의 차트만 있으면 모든 것이 정상입니다. 여기서 OOP는 실제로 필요하지 않습니다. 하지만 서로 다른 영역에 여러 그래프를 표시해야 하는 경우 OOP 없이는 이미 여러 CCanvas 인스턴스를 생성하기 어렵습니다.
또는 다른 예. 나는 최근에 동시에 여러 상품을 거래할 수 있도록 절차적 EA를 조정하라는 요청을 받았습니다(동일한 차트에서 시작됨). 절차적 스타일에서 그가 동시에 다른 기호에 대해 독립적으로 거래하도록 하려면 매우 길고 어려운 트릭이 필요합니다. 방금 모든 절차 코드를 클래스에 배치하고 세 개의 인스턴스를 만들었습니다. 각각에는 작업 기호 등을 포함하여 개별 설정 세트가 제공되었습니다. 코드는 처음처럼 작동했습니다. 사용자는 행복했습니다.
당신도 핵심에서 OOP를 사용합니다. 암시 적으로 수행하지만 :
각 코어는 OOP 용어로 클래스의 인스턴스입니다. 그리고 무엇이라고 부르든 그것은 OOP의 요소입니다. 그러나 불행하게도, 이 수제 요소는 수천 명의 최후의 사람들이 아닌 사람들이 이미 발명하고 연마한 것보다 개념적 강도가 열등합니다.
여기에서 당신은 헛된 구슬을 던지고 있습니다. 첫째, Perth 고문과 당신의 모범은 코끼리 찜질과 같습니다. 그는 전문가를 쓰는 방법을 모르고, 거기에 무엇이 있고 왜 있는지 이해하지 못하며, 당신의 예시적인 예를 이해할 수 없습니다. 그의 눈은 당신에게 니콜라스와 같은 말을 하기 시작할 것입니다. 둘째, 당신은 그 자신이 자신의 양동이에서 스스로, 수천 명의 이전 마음의 도움 없이 자신이 뛰어난 솔루션으로 더 나은 초 독특한 코드를 더 잘 만들었다고 말하면서 코를 더 높이 올릴 이유를 제공합니다. 이전 솔루션보다 이것이 바로 그가 밸브가 있는 독특한 버킷을 배치하는 방법입니다 ...
추신. 내가 거칠게 말했을 수도 있지만, 나는 정말로 꿰뚫을 수 없는 어리석음을 참을 수 없다.
각 코어는 OOP 용어로 클래스의 인스턴스입니다. 그리고 무엇이라고 부르든 그것은 OOP의 요소입니다. 그러나 불행하게도, 이 수제 요소는 수천 명의 최후의 사람들이 아닌 사람들이 이미 발명하고 연마한 것보다 개념적 강도가 열등합니다.
그리고 있습니다. 그러나 그럼에도 불구하고 상당한 차이가 있습니다. 내가 이해하는 한 Peter와 함께(이 클래스의 경우) 거의 모든 것을 사용할 수 있습니다. 그리고 이것은 OOP의 캡슐화 패러다임에 맞지 않습니다. 예 및 전역 변수 도 있습니다.
그래서 여기에는 "OOP의 요소"만 있습니다.
하지만, 그리고 그 반대입니다. 사람들이 그것을 너무 좋아하지 않을까 걱정됩니다. Vasily, 내 OOP 프로젝트를 다운로드할 때 반대로 사람들은 "아무것도 할 수 없습니다. 직접 의도한 것을 제외하고는 이 인터페이스를 사용합니다." :)
새로운 GUI를 만들 때마다 엔진을 변경해야 합니다(적절한 GUI 코어 제공). 이것은 근본적으로 잘못된 결정이라고 생각합니다. 수백 명의 엔진 사용자가 있다고 상상해보십시오. 그러나 시장이나 다른 곳에서 호스팅되는 엔진은 단 하나뿐입니다. 이 경우 어떻게 행동하시겠습니까? 각 사용자가 자신을 위해 다운로드해야 하는 특정 엔진을 배치하려면? 그리고 엔진용 GUI 커널을 어떻게 준비할 것인가? 각 사용자에게 개별 코어를 제공하시겠습니까? - 금세 악몽이 됩니다. 솔루션이 확장되지 않은 것으로 나타났습니다.
아니, Vasily, 당신은 모든 것을 극화하는 경향이 있습니다.))
생성자에는 클릭 시 모든 파일을 인쇄하는 버튼이 있습니다.
그리고 엔진은 텍스트 파일에서 커널을 로드합니다. 어렵지 않습니다.
Peter, 당신은 OOP 사용과 관련하여 뭔가를 잘못 이해했습니다.
이것은 특별한 형태의 의식이며 진화를 방해하지 마십시오