왜 3D인가? 먼저 과제를 내놓으십시오. 3D 그래픽? 의심스러운 것. 3d는 무엇을 위한 것입니까?
시장은 컴퓨터가 등장하기 전부터 존재해 왔습니다. 타임머신을 타고 미국의 20대로 이동했다고 상상해보십시오. 현대 전자 및 프로그래밍을 알고 컴퓨터를 만들고 플랫폼을 작성하고 모든 사람에게 거래 로봇을 판매하기로 결정했습니다.
당신이 만들고 싶은 것에 대한 설명을 가지고 거래자들에게 접근한다면 당신은 미친 사람으로 간주될 것입니다. 아무도 당신이 말하는 것을 이해하지 못할 것입니다. 한 마디도 하지 않습니다. 당시에는 그런 개념이 없었기 때문입니다. 아무에게도 설명할 수 없을 것입니다. 대략 40대 중반까지. 그런 다음 Alan Turing의 컴퓨터가 와서 그의 계획에 대해 이야기하면 약간의 이해를 얻을 수 있을 것입니다. 80년대에 가까울수록 이해가 더 잘 될텐데...
시장에서 얻는 이익은 허구라는 것을 이해해야 합니다. 진정한 이익은 새로운 영역을 정복하는 것입니다. 이 경우 영역 은 MQL 기술입니다. 더 많은 기술을 만들수록 더 많은 영역을 정복할 것입니다. 그리고 이 영역에서 금맥을 찾을 수 있습니다....
여러분, 진심으로 존중하는 마음으로 프로그램을 짜십시오. 나는 내 방식대로 프로그래밍할 것이다.
OOP는 한 사람의 힘을 넘어서는 프로젝트를 수행하는 프로그래머 팀에게 필요합니다.
간단한 애니메이션에는 OOP가 필요하지 않습니다. 또한, 토끼를 사냥할 때 바주카포를 가지고 다닐 필요가 없습니다.))
틀렸어, 피터.
OOP는 어리석음으로 인해 수천 개의 개체의 목적과 연결을 기억할 수 없는 모든 프로그래머에게 필요합니다.
이 모든 것을 쉽게 기억에 남길 수 있습니다. 그렇기 때문에 OOP가 필요하지 않습니다. 추가 제스처만 있으면 이해할 수 있습니다.
그러나 그러한 모든 기억의 거물은 아닙니다. 내가 며칠 전에 쓴 것의 미묘함을 기억하지 못한다고 가정해 봅시다. 그리고 6개월 전에 쓰여진 것 - 필요한 경우 처음부터 이해해야 합니다. 이것이 나에게 캡슐화, 구현 숨기기, 전면적인 액세스 차단, 최소한 의 전역 변수 가 유익한 이유입니다. 이 모든 것이 내가 하지 말아야 할 곳을 "등산"하지 못하게 합니다. 그러나이 모든 것은 전적으로 내 기억력이 좋지 않기 때문입니다. 수천 개의 작은 것을 기억할 수 없습니다.
MetaTrader의 3차원 차트 와 3차원 표면의 형태로 결과를 표시하는 Expert Advisor는 즉시 훨씬 더 수익성이 높아집니다!
따라서 Peter가 새로운 거래자를 형성하는 것을 막지 마십시오. 실제로 프로그래밍 방법을 알고 있지만 동시에 손으로 거래하는 것을 선호하는 사람들에게 Peter의 모든 개발은 매우 흥미 롭습니다. 사실, 나는 어떻게 든 그런 사람들을 보지 못했지만 Peter는 그들이 교육을 받고 창조 될 수 있다고 주장합니다. 분명히 - 그러한 수동 거래의 이점을 보여줍니다.
이 장점을 보여주는 일만 남았습니다. Peter의 시각적 컨트롤을 보았고 그것이 무엇인지 상상할 수 있다면 수동 거래의 이점을 어떻게 든 눈치 채지 못했습니다.
이 애니메이션은 CCanvas로 구현할 수 없습니다. 하나의 캔버스를 다른 리소스에 연결하는 메커니즘은 없습니다. 그리고 그것 없이는 각 애니메이션 전환에서 캔버스의 원래 내용을 다시 그려야 합니다. 그렇지 않으면 죽은 이미지를 얻게 됩니다.
다시 그릴 때 시간이 걸리고 모든 것이 느려지기 시작합니다. 캔버스를 두 개의 리소스에 차례로 다시 연결하는 자체 메커니즘을 구현해야 했고 그 결과 때때로 애니메이션을 가속화했습니다.
또한 CCanvas 클래스는 하나의 캔버스에서만 작동하도록 설계되었습니다. 그리고 동시에 다른 그림을 그릴 수 있습니다.
그것이 바로 OOP의 목적입니다!
함수 클래스에서 "제거"할 필요는 없습니다. 찢어진 기능이 아무 것도 "끌어 당기지"않은 것은 운이 좋습니다. 그건 그렇고, 캡슐화 덕분에 전역 변수 가 없습니다. 이 클래스가 OOP가 아닌 스타일로 작성되었다면 이 코드를 그렇게 쉽게 "제거"할 수 없었을 것입니다.
그러나 중요한 것은 그것조차 아닙니다. 여러 캔버스를 구성해야 하는 경우 개체의 여러 인스턴스를 만듭니다. 개체의 "내부"로 작업해야 하는 경우 개체에서 상속하여 작업합니다.
아니요, 당신이하는 것과 똑같이 할 수 있습니다. 그러나 동시에 오류가 발생할 위험은 훨씬 높습니다. 결국 클래스 자체를 작성하지 않았으며 작업의 모든 미묘함을 알지 못합니다. 클래스에서 코드를 추출하는 것은 매우 위험한 행위입니다. 내가 당신의 라이브러리에서 몇 가지 기능을 가져온다고 상상해보십시오. 내가 뭔가를 얻을 것이라고 생각합니까? 매우 가능성이 낮습니다. 함수를 사용하면 많은 전역 변수를 "끌어다"야 하기 때문입니다. 그리고 내부 개체 간의 연결은 내가 모두 고려한다는 사실이 아닙니다. 메모리가 부족합니다.
이익이 더 크고 일반적으로 거래의 수익성이 높도록)!
그러면 3D 세계가 열립니다. 물론 기술에 대해 수수께끼를 내야하지만 나는 할 것입니다. 체적 3차원 형태가 회전합니다.
표트르, 당신은 다시 알 수 없는 거리로 옮겨졌습니다. 현재 기능에 집중하십시오. 그렇지 않으면 엔진이 출시되지 않습니다. 기본 기능을 구현한 다음 3d, 4d, 6d, Power Surround 등의 새로운 아이디어를 구현합니다.
시장은 컴퓨터가 등장하기 전부터 존재해 왔습니다. 타임머신을 타고 미국의 20대로 이동했다고 상상해보십시오. 현대 전자 및 프로그래밍을 알고 컴퓨터를 만들고 플랫폼을 작성하고 모든 사람에게 거래 로봇을 판매하기로 결정했습니다.
당신이 만들고 싶은 것에 대한 설명을 가지고 거래자들에게 접근한다면 당신은 미친 사람으로 간주될 것입니다. 아무도 당신이 말하는 것을 이해하지 못할 것입니다. 한 마디도 하지 않습니다. 당시에는 그런 개념이 없었기 때문입니다. 아무에게도 설명할 수 없을 것입니다. 대략 40대 중반까지. 그런 다음 Alan Turing의 컴퓨터가 와서 그의 계획에 대해 이야기하면 약간의 이해를 얻을 수 있을 것입니다. 80년대에 가까울수록 이해가 더 잘 될텐데...
시장에서 얻는 이익은 허구라는 것을 이해해야 합니다. 진정한 이익은 새로운 영역을 정복하는 것입니다. 이 경우 영역 은 MQL 기술입니다. 더 많은 기술을 만들수록 더 많은 영역을 정복할 것입니다. 그리고 이 영역에서 금맥을 찾을 수 있습니다....
그래서 최대한 하려고 노력합니다.
표트르, 당신은 다시 알 수 없는 거리로 옮겨졌습니다. 현재 기능에 집중하십시오. 그렇지 않으면 엔진이 출시되지 않습니다. 기본 기능을 구현한 다음 3d, 4d, 6d, Power Surround 등의 새로운 아이디어를 구현합니다.
릴리스를 시작하려면 대체로 한 가지 작업을 구현해야 합니다. 바로 엔진과 어드바이저 간의 새로운 통신 메커니즘입니다.
나머지는 몇 달 안에 완료할 수 있습니다. 버그 수정, 기능 추가...
릴리스를 시작하려면 대체로 한 가지 작업을 구현해야 합니다. 바로 엔진과 어드바이저 간의 새로운 통신 메커니즘입니다.
나머지는 몇 달 안에 완료할 수 있습니다. 버그 수정, 기능 추가...
따라서 어드바이저와 엔진의 연결에 집중하십시오. 3d, 4d, 6d와 같은 다른 작업은 나중을 위해 남겨둡니다. 이제 목표는 릴리스입니다. 다른 모든 것은 나중에.
따라서 어드바이저와 엔진의 연결에 집중하십시오. 3d, 4d, 6d와 같은 다른 작업은 나중을 위해 남겨둡니다. 이제 목표는 릴리스입니다. 다른 모든 것은 나중에.
라고 하시면 그대로입니다. 첫 번째 목표는 대중의 관심을 끄는 것입니다. 그러기 위해서는 흥미롭고 특이한 일을 많이 해야 했습니다. 대중이 이미 관심을 갖고 있다면 두 번째 목표인 출시 및 배포로 넘어가야 합니다.
그래서 최대한 하려고 노력합니다.
이상한 접근).
여러분, 진심으로 존중하는 마음으로 프로그램을 짜십시오. 나는 내 방식대로 프로그래밍할 것이다.
OOP는 한 사람의 힘을 넘어서는 프로젝트를 수행하는 프로그래머 팀에게 필요합니다.
간단한 애니메이션에는 OOP가 필요하지 않습니다. 또한, 토끼를 사냥할 때 바주카포를 가지고 다닐 필요가 없습니다.))
틀렸어, 피터.
OOP는 어리석음으로 인해 수천 개의 개체의 목적과 연결을 기억할 수 없는 모든 프로그래머에게 필요합니다.
이 모든 것을 쉽게 기억에 남길 수 있습니다. 그렇기 때문에 OOP가 필요하지 않습니다. 추가 제스처만 있으면 이해할 수 있습니다.
그러나 그러한 모든 기억의 거물은 아닙니다. 내가 며칠 전에 쓴 것의 미묘함을 기억하지 못한다고 가정해 봅시다. 그리고 6개월 전에 쓰여진 것 - 필요한 경우 처음부터 이해해야 합니다. 이것이 나에게 캡슐화, 구현 숨기기, 전면적인 액세스 차단, 최소한 의 전역 변수 가 유익한 이유입니다. 이 모든 것이 내가 하지 말아야 할 곳을 "등산"하지 못하게 합니다. 그러나이 모든 것은 전적으로 내 기억력이 좋지 않기 때문입니다. 수천 개의 작은 것을 기억할 수 없습니다.
이익이 더 크고 일반적으로 거래의 수익성이 높도록)!
정확히 !
MetaTrader의 3차원 차트 와 3차원 표면의 형태로 결과를 표시하는 Expert Advisor는 즉시 훨씬 더 수익성이 높아집니다!
따라서 Peter가 새로운 거래자를 형성하는 것을 막지 마십시오. 실제로 프로그래밍 방법을 알고 있지만 동시에 손으로 거래하는 것을 선호하는 사람들에게 Peter의 모든 개발은 매우 흥미 롭습니다. 사실, 나는 어떻게 든 그런 사람들을 보지 못했지만 Peter는 그들이 교육을 받고 창조 될 수 있다고 주장합니다. 분명히 - 그러한 수동 거래의 이점을 보여줍니다.
이 장점을 보여주는 일만 남았습니다. Peter의 시각적 컨트롤을 보았고 그것이 무엇인지 상상할 수 있다면 수동 거래의 이점을 어떻게 든 눈치 채지 못했습니다.
음... 우리는 기다리고 있습니다!
이 애니메이션은 CCanvas로 구현할 수 없습니다. 하나의 캔버스를 다른 리소스에 연결하는 메커니즘은 없습니다. 그리고 그것 없이는 각 애니메이션 전환에서 캔버스의 원래 내용을 다시 그려야 합니다. 그렇지 않으면 죽은 이미지를 얻게 됩니다.
다시 그릴 때 시간이 걸리고 모든 것이 느려지기 시작합니다. 캔버스를 두 개의 리소스에 차례로 다시 연결하는 자체 메커니즘을 구현해야 했고 그 결과 때때로 애니메이션을 가속화했습니다.
또한 CCanvas 클래스는 하나의 캔버스에서만 작동하도록 설계되었습니다. 그리고 동시에 다른 그림을 그릴 수 있습니다.
그것이 바로 OOP의 목적입니다!
함수 클래스에서 "제거"할 필요는 없습니다. 찢어진 기능이 아무 것도 "끌어 당기지"않은 것은 운이 좋습니다. 그건 그렇고, 캡슐화 덕분에 전역 변수 가 없습니다. 이 클래스가 OOP가 아닌 스타일로 작성되었다면 이 코드를 그렇게 쉽게 "제거"할 수 없었을 것입니다.
그러나 중요한 것은 그것조차 아닙니다. 여러 캔버스를 구성해야 하는 경우 개체의 여러 인스턴스를 만듭니다. 개체의 "내부"로 작업해야 하는 경우 개체에서 상속하여 작업합니다.
아니요, 당신이하는 것과 똑같이 할 수 있습니다. 그러나 동시에 오류가 발생할 위험은 훨씬 높습니다. 결국 클래스 자체를 작성하지 않았으며 작업의 모든 미묘함을 알지 못합니다. 클래스에서 코드를 추출하는 것은 매우 위험한 행위입니다. 내가 당신의 라이브러리에서 몇 가지 기능을 가져온다고 상상해보십시오. 내가 뭔가를 얻을 것이라고 생각합니까? 매우 가능성이 낮습니다. 함수를 사용하면 많은 전역 변수를 "끌어다"야 하기 때문입니다. 그리고 내부 개체 간의 연결은 내가 모두 고려한다는 사실이 아닙니다. 메모리가 부족합니다.
하지만, 당신은 여기에서 운이 좋습니다. 당신의 기억력은 훌륭합니다. 나는 네가 부러워.