조지, 그것은 단지 기억에 관한 것이 아닙니다. 나는 모국어와 영어를 사용하여 나 자신에게 편안한 개발 환경을 만들었습니다. 이중 언어 코드는 단일 언어 코드보다 훨씬 더 잘 기억됩니다. 특히 표준어에 집착하지 않고 원하는 대로 변수를 호출할 때. 확인했습니다. 나는 프로그래밍의 전문성에 대해 신경 쓰지 않고 편리하게 쓰기 시작했습니다. 그 결과 코드를 빠르게 탐색하기 시작했고 코드를 읽고 기억하고 개발하기가 쉬웠습니다. 다음은 아시죠...
도움이 될 수 없다고 생각합니다. 나에게 모든 언어의 변수 이름은 거의 즉시 기억에서 사라지고 컴퓨터에서 일어났고 이미 일반 원칙 만 기억하고 어떤 변수가 여기 저기에 도입되었는지 말할 수 없습니다.
그건 그렇고, 이것이 내가 항상 mqh-mq5 파일 쌍을 사용하고 완전히 mqh 파일에 클래스를 작성하지 않는 이유입니다. 헤더 파일을 살펴봐야 하는 경우가 종종 있습니다. 탭에 필요한 mqh 헤더가 열려 있고 이 정보를 다시 새로 고쳐야 할 때 탭으로 전환합니다. 전체 클래스(특히 여러 개)가 하나의 mqh 파일에 설명되어 있으면 책갈피를 사용하더라도 이 파일을 "점프"하는 것이 더 스트레스가 됩니다.
내 기억에 전체 구조를 유지할 수는 없지만, 어린 시절에는 이미 말했듯이 어셈블러로 글을 쓰기도 했지만 다른 옵션은 없습니다. 메모리 주소만 있고 매크로 어셈블러가 허용하는 최대값만 있습니다. 매크로 대체를 사용하여 특정 영역의 이름을 만드는 것입니다. 그것도 가능합니다. 그러나 나는 오류의 수가 훨씬 더 많고 그러한 코드를 디버깅하는 것이 훨씬 더 어렵다는 것을 오랫동안 확신해 왔습니다.
위에 예가 이미 나와 있습니다. 어떤 이유로 변수가 잘못 수정되어 오류가 발생했습니다. 그리고 변수는 프로그램의 여러 위치에서 액세스할 수 있습니다. 오류가 있는 곳을 잡는 방법은 무엇입니까? OOP 캡슐화를 사용하면 모든 것이 매우 간단합니다. 변수를 수정하는 인터페이스 함수 에 중단점을 설정하고 잘못된 수정이 발생하는 즉시 중지하고 호출 계층 구조에 따라 즉시 잘못된 수정이 있었던 위치를 봅니다. 에서 만들어진. 그리고 Peter, 당신의 접근 방식으로 우리는 전체 코드를 샅샅이 뒤져 이 변수가 액세스되는 모든 위치를 살펴보고 모든 곳에 중단점을 배치하고 잘못된 액세스뿐만 아니라 모든 액세스를 분석해야 합니다.
이것은 그가 좋은 프로그래머가 아니라는 것을 의미합니다. 복잡한 OOP 구성에서는 없는 경우보다 더 혼란스러울 수 있습니다.
다른 조건의 paribus ? 나는 그것을 매우 의심한다. 디자인의 복잡성이 동일하면 OOP를 처리하는 것이 훨씬 쉽습니다.
그러나 이것은 "대포에서 참새로"규칙을 변경하지 않으며 작업이 매우 간단하고 컴팩트 한 큰 OOP 종소리와 휘파람을 사용하는 것은 의미가 없습니다.
위에서 이미 언급했듯이 OOP를 사용하면 많은 프로젝트에서 사용되는 클래스 라이브러리를 입력할 수 있습니다.
동일한 배열 클래스, 파일 클래스를 가정해 보겠습니다. OOP를 사용하지 않고 매우 간단한 표시기를 작성할 때도 파일 작업을 위한 표준 함수를 사용하는 것보다 필요한 경우 CFile 클래스를 선언하고 해당 함수를 사용하는 것이 훨씬 쉽습니다. CFile을 보다 구체적인 것으로 쉽게 대체하는 기능에 대해 말하는 것이 아닙니다. 예를 들어 CLogFile 클래스가 있습니다. 시간과 일부 추가 데이터를 줄(로그 파일의 경우)에 자동으로 삽입하거나 데이터를 표준 초기 파일로 구성한 다음 필요에 따라 읽고 사용합니다.
위에 예가 이미 나와 있습니다. 어떤 이유로 변수가 잘못 수정되어 오류가 발생했습니다. 그리고 변수는 프로그램의 여러 위치에서 액세스할 수 있습니다. 오류가 있는 곳을 잡는 방법은 무엇입니까? OOP 캡슐화를 사용하면 모든 것이 매우 간단합니다. 변수를 수정하는 인터페이스 함수에 중단점을 설정하고 잘못된 수정이 발생하는 즉시 중지하고 호출 계층 구조에 따라 즉시 잘못된 수정이 있었던 위치를 봅니다. 에서 만들어진. Peter, 당신의 접근 방식으로 우리는 전체 코드를 샅샅이 뒤져 이 변수가 액세스되는 모든 위치를 살펴보고 모든 곳에 중단점을 배치하고 잘못된 액세스뿐만 아니라 모든 액세스를 분석해야 합니다.
예, 프로그램의 모든 부분에서 내 커널이 수정되고 오류가 발생하지만 중단점 없이 수행합니다. 마음속으로 계산하고 값을 확인하기 위해 여러 곳에 경고를 한다. 내가 그것을 찾는 방법입니다. 나는 내 프로그램을 아주 잘 알고 있음을 강조하겠습니다.
그러나 장점은 그러한 지식, 구문 장애 및 모국어가 없기 때문에 빠른 개발을 위한 큰 기회가 있다는 것입니다. 그래서 저는 결정에 있어 OOP에 반대합니다.
코드 분할, 낯선 단일 언어 사용, 새로운 구문, 추가 규칙 - 이 모든 것이 프로그램 개발 속도를 늦춥니다. 나는 더 많은 힘을 잃고 더 적은 결과를 얻을 것이다. 나는 그것을 확실히 알고 있다.
내 작업이 기성 코드 조각에서 프로그램을 어셈블하고 디버그하는 것이라면 OOP와 라이브러리만 가능합니다. 새로운 솔루션을 왜곡하고 개발하는 것은 별개의 문제입니다. 많은 사람들이 다른 사람의 코드를 사용하고 노력을 절약하기를 원하기 때문에 OOP를 옹호합니다. 저는 독점 기술을 사용하여 솔루션을 만들고 OOP에 대한 요구 사항과 관점이 다릅니다.
예, 프로그램의 모든 부분에서 내 커널이 수정되고 오류가 발생하지만 중단점 없이 수행합니다. 마음속으로 계산하고 값을 확인하기 위해 여러 곳에 경고를 한다. 내가 그것을 찾는 방법입니다. 나는 내 프로그램을 아주 잘 알고 있음을 강조하겠습니다.
그러나 장점은 그러한 지식, 구문 장애 및 모국어가 없기 때문에 빠른 개발을 위한 큰 기회가 있다는 것입니다. 그래서 저는 결정에 있어 OOP에 반대합니다.
코드 분할, 낯선 단일 언어 사용, 새로운 구문, 추가 규칙 - 이 모든 것이 프로그램 개발 속도를 늦춥니다. 나는 더 많은 힘을 잃고 더 적은 결과를 얻을 것이다. 나는 그것을 확실히 알고 있다.
내 작업이 기성 코드 조각에서 프로그램을 어셈블하고 디버그하는 것이라면 OOP와 라이브러리만 가능합니다. 새로운 솔루션을 왜곡하고 개발하는 것은 별개의 문제입니다. 많은 사람들이 다른 사람의 코드를 사용하고 노력을 절약하기를 원하기 때문에 OOP를 옹호합니다. 저는 독점 기술을 사용하여 솔루션을 만들고 OOP에 대한 요구 사항과 관점이 다릅니다.
VC ++에서 대화 상자 템플릿을 한 번 이상 사용하고, MFC에서 CDialog를 기반으로 응용 프로그램을 만들고, 시각적 모드에서 모든 종류의 컨트롤을 설치하고, 기성 기능을 사용 하여 OOP의 전체 기능을 이해하는 것이 좋습니다.
그리고 Borland C ++에서는 Oracle과 함께 작업하기 위해 매우 편리한 클래스가 생성된다는 점을 추가하겠습니다. 2012년까지 그와 함께 일했는데, 지금은 어떻게 되는지 모르겠다.
VC ++에서 대화 상자 템플릿을 한 번 이상 사용하고, MFC에서 CDialog를 기반으로 응용 프로그램을 만들고, 시각적 모드에서 모든 종류의 컨트롤을 설치하고, 기성 기능을 사용 하여 OOP의 전체 기능을 이해하는 것이 좋습니다.
그리고 Borland C ++에서는 Oracle과 함께 작업하기 위해 매우 편리한 클래스가 생성된다는 점을 추가하겠습니다. 2012년까지 그와 함께 일했는데, 지금은 어떻게 되는지 모르겠다.
이 논의에서 권력 이란 다른 것을 의미합니다. 당신에게 힘은 이미 엄청나게 많은 라이브러리에서 기성품 코드 조각을 빠르고 쉽게 조립하는 것으로 표현됩니다. 쉬운 조립도 Power입니다. 하지만, 다른. 나는 새로운 솔루션을 개발하는 힘에 대해 이야기하고 있습니다. 기스로부터. 미리 만들어진 코드 조각 없이 개발 환경에서 프로그램 성장의 힘에 대해 . 결국 C++ 그래픽 라이브러리 는 MQL로 이식되지 않습니다. 같은 수준의 자체 솔루션을 개발해야 했습니다. 그리고 여기서 전력은 조립 속도가 아니라 프로그램 개발 속도에 의해 테스트됩니다. 2년 반 동안 저는 처음부터 저만의 마크업 언어 를 만들었습니다. API. MQL 그래픽 라이브러리 이상입니다. 시각적 생성자를 생성하는 단계에 이르렀습니다. 그리고 이것은 접근 방식의 힘을 나타내는 지표입니다. 여기 아무도 필요하지 않다는 것이 유감입니다 ...
프로그래머가 외환의 세계에 들어가면 전문가가 될 필요가 없고 OOP를 알 필요가 없습니다.
시장의 복잡성을 연구하고 수익성 있는 거래 전략을 개발하는 것이 좋습니다. OOP를 사용 하는지 여부는 중요하지 않습니다. 이는 EA의 수익성에 영향을 미치지 않습니다.
에너지를 낭비할 필요가 없습니다.
조지, 그것은 단지 기억에 관한 것이 아닙니다. 나는 모국어와 영어를 사용하여 나 자신에게 편안한 개발 환경을 만들었습니다. 이중 언어 코드는 단일 언어 코드보다 훨씬 더 잘 기억됩니다. 특히 표준어에 집착하지 않고 원하는 대로 변수를 호출할 때. 확인했습니다. 나는 프로그래밍의 전문성에 대해 신경 쓰지 않고 편리하게 쓰기 시작했습니다. 그 결과 코드를 빠르게 탐색하기 시작했고 코드를 읽고 기억하고 개발하기가 쉬웠습니다. 다음은 아시죠...
도움이 될 수 없다고 생각합니다. 나에게 모든 언어의 변수 이름은 거의 즉시 기억에서 사라지고 컴퓨터에서 일어났고 이미 일반 원칙 만 기억하고 어떤 변수가 여기 저기에 도입되었는지 말할 수 없습니다.
그건 그렇고, 이것이 내가 항상 mqh-mq5 파일 쌍을 사용하고 완전히 mqh 파일에 클래스를 작성하지 않는 이유입니다. 헤더 파일을 살펴봐야 하는 경우가 종종 있습니다. 탭에 필요한 mqh 헤더가 열려 있고 이 정보를 다시 새로 고쳐야 할 때 탭으로 전환합니다. 전체 클래스(특히 여러 개)가 하나의 mqh 파일에 설명되어 있으면 책갈피를 사용하더라도 이 파일을 "점프"하는 것이 더 스트레스가 됩니다.
내 기억에 전체 구조를 유지할 수는 없지만, 어린 시절에는 이미 말했듯이 어셈블러로 글을 쓰기도 했지만 다른 옵션은 없습니다. 메모리 주소만 있고 매크로 어셈블러가 허용하는 최대값만 있습니다. 매크로 대체를 사용하여 특정 영역의 이름을 만드는 것입니다. 그것도 가능합니다. 그러나 나는 오류의 수가 훨씬 더 많고 그러한 코드를 디버깅하는 것이 훨씬 더 어렵다는 것을 오랫동안 확신해 왔습니다.
위에 예가 이미 나와 있습니다. 어떤 이유로 변수가 잘못 수정되어 오류가 발생했습니다. 그리고 변수는 프로그램의 여러 위치에서 액세스할 수 있습니다. 오류가 있는 곳을 잡는 방법은 무엇입니까? OOP 캡슐화를 사용하면 모든 것이 매우 간단합니다. 변수를 수정하는 인터페이스 함수 에 중단점을 설정하고 잘못된 수정이 발생하는 즉시 중지하고 호출 계층 구조에 따라 즉시 잘못된 수정이 있었던 위치를 봅니다. 에서 만들어진. 그리고 Peter, 당신의 접근 방식으로 우리는 전체 코드를 샅샅이 뒤져 이 변수가 액세스되는 모든 위치를 살펴보고 모든 곳에 중단점을 배치하고 잘못된 액세스뿐만 아니라 모든 액세스를 분석해야 합니다.
그것이 바로 요점이며 고통을 줄 수 있습니다. 친구는 코드 오류로 인해 보증금의 일부를 잃어버렸고 OOP는 오류 가능성을 줄였습니다.
이것은 그가 좋은 프로그래머가 아니라는 것을 의미합니다. 복잡한 OOP 구성에서는 없는 경우보다 더 혼란스러울 수 있습니다.
필요한 경우 클래스를 적용해야 합니다. 그래서 나는 일부 프로그래머가 일종의 매니아를 가지고 있으며 필요하지 않은 모든 곳에서 많은 기능을 사용한다는 것을 알았습니다. 이것은 수업도 마찬가지입니다.
OOP 없이 간결하고 짧은 프로그램을 작성하는 대신 일부 프로그래머는 클래스, 많은 기능을 사용하기 시작하고 간단한 솔루션은 1km 길이의 텍스트로 바뀝니다.
이것은 그가 좋은 프로그래머가 아니라는 것을 의미합니다. 복잡한 OOP 구성에서는 없는 경우보다 더 혼란스러울 수 있습니다.
다른 조건의 paribus ? 나는 그것을 매우 의심한다. 디자인의 복잡성이 동일하면 OOP를 처리하는 것이 훨씬 쉽습니다.
그러나 이것은 "대포에서 참새로"규칙을 변경하지 않으며 작업이 매우 간단하고 컴팩트 한 큰 OOP 종소리와 휘파람을 사용하는 것은 의미가 없습니다.
위에서 이미 언급했듯이 OOP를 사용하면 많은 프로젝트에서 사용되는 클래스 라이브러리를 입력할 수 있습니다.
동일한 배열 클래스, 파일 클래스를 가정해 보겠습니다. OOP를 사용하지 않고 매우 간단한 표시기를 작성할 때도 파일 작업을 위한 표준 함수를 사용하는 것보다 필요한 경우 CFile 클래스를 선언하고 해당 함수를 사용하는 것이 훨씬 쉽습니다. CFile을 보다 구체적인 것으로 쉽게 대체하는 기능에 대해 말하는 것이 아닙니다. 예를 들어 CLogFile 클래스가 있습니다. 시간과 일부 추가 데이터를 줄(로그 파일의 경우)에 자동으로 삽입하거나 데이터를 표준 초기 파일로 구성한 다음 필요에 따라 읽고 사용합니다.
이것은 그가 좋은 프로그래머가 아니라는 것을 의미합니다. 복잡한 OOP 구성에서는 없는 경우보다 더 혼란스러울 수 있습니다.
필요한 경우 클래스를 적용해야 합니다. 그래서 나는 일부 프로그래머가 일종의 매니아를 가지고 있으며 필요하지 않은 모든 곳에서 많은 기능을 사용한다는 것을 알았습니다. 이것은 수업도 마찬가지입니다.
OOP 없이 간결하고 짧은 프로그램을 작성하는 대신 일부 프로그래머는 클래스, 많은 기능을 사용하기 시작하고 간단한 솔루션은 1km 길이의 텍스트로 바뀝니다.
실제 작업은 백 줄이고 나머지 몇 천 줄은 오래전에 작성하고 디버그한 라이브러리면 될까요? )))
프로그래머가 프로그램에서 CTrade, CAccountInfo , CPositionInfo와 같은 기성 클래스를 사용하는 경우 이것이 그의 프로그램이 OOP를 기반으로 한다는 것을 의미하지는 않습니다.
프로그래머 자신이 그러한 클래스를 생성하는지, 아니면 이러한 클래스의 내부(소스 코드 수준에서)를 모른 채 단순히 사용하는지에 달려 있습니다.
....
위에 예가 이미 나와 있습니다. 어떤 이유로 변수가 잘못 수정되어 오류가 발생했습니다. 그리고 변수는 프로그램의 여러 위치에서 액세스할 수 있습니다. 오류가 있는 곳을 잡는 방법은 무엇입니까? OOP 캡슐화를 사용하면 모든 것이 매우 간단합니다. 변수를 수정하는 인터페이스 함수에 중단점을 설정하고 잘못된 수정이 발생하는 즉시 중지하고 호출 계층 구조에 따라 즉시 잘못된 수정이 있었던 위치를 봅니다. 에서 만들어진. Peter, 당신의 접근 방식으로 우리는 전체 코드를 샅샅이 뒤져 이 변수가 액세스되는 모든 위치를 살펴보고 모든 곳에 중단점을 배치하고 잘못된 액세스뿐만 아니라 모든 액세스를 분석해야 합니다.
예, 프로그램의 모든 부분에서 내 커널이 수정되고 오류가 발생하지만 중단점 없이 수행합니다. 마음속으로 계산하고 값을 확인하기 위해 여러 곳에 경고를 한다. 내가 그것을 찾는 방법입니다. 나는 내 프로그램을 아주 잘 알고 있음을 강조하겠습니다.
그러나 장점은 그러한 지식, 구문 장애 및 모국어가 없기 때문에 빠른 개발을 위한 큰 기회가 있다는 것입니다. 그래서 저는 결정에 있어 OOP에 반대합니다.
코드 분할, 낯선 단일 언어 사용, 새로운 구문, 추가 규칙 - 이 모든 것이 프로그램 개발 속도를 늦춥니다. 나는 더 많은 힘을 잃고 더 적은 결과를 얻을 것이다. 나는 그것을 확실히 알고 있다.
내 작업이 기성 코드 조각에서 프로그램을 어셈블하고 디버그하는 것이라면 OOP와 라이브러리만 가능합니다. 새로운 솔루션을 왜곡하고 개발하는 것은 별개의 문제입니다. 많은 사람들이 다른 사람의 코드를 사용하고 노력을 절약하기를 원하기 때문에 OOP를 옹호합니다. 저는 독점 기술을 사용하여 솔루션을 만들고 OOP에 대한 요구 사항과 관점이 다릅니다.
예, 프로그램의 모든 부분에서 내 커널이 수정되고 오류가 발생하지만 중단점 없이 수행합니다. 마음속으로 계산하고 값을 확인하기 위해 여러 곳에 경고를 한다. 내가 그것을 찾는 방법입니다. 나는 내 프로그램을 아주 잘 알고 있음을 강조하겠습니다.
그러나 장점은 그러한 지식, 구문 장애 및 모국어가 없기 때문에 빠른 개발을 위한 큰 기회가 있다는 것입니다. 그래서 저는 결정에 있어 OOP에 반대합니다.
코드 분할, 낯선 단일 언어 사용, 새로운 구문, 추가 규칙 - 이 모든 것이 프로그램 개발 속도를 늦춥니다. 나는 더 많은 힘을 잃고 더 적은 결과를 얻을 것이다. 나는 그것을 확실히 알고 있다.
내 작업이 기성 코드 조각에서 프로그램을 어셈블하고 디버그하는 것이라면 OOP와 라이브러리만 가능합니다. 새로운 솔루션을 왜곡하고 개발하는 것은 별개의 문제입니다. 많은 사람들이 다른 사람의 코드를 사용하고 노력을 절약하기를 원하기 때문에 OOP를 옹호합니다. 저는 독점 기술을 사용하여 솔루션을 만들고 OOP에 대한 요구 사항과 관점이 다릅니다.
VC ++에서 대화 상자 템플릿을 한 번 이상 사용하고, MFC에서 CDialog를 기반으로 응용 프로그램을 만들고, 시각적 모드에서 모든 종류의 컨트롤을 설치하고, 기성 기능을 사용 하여 OOP의 전체 기능을 이해하는 것이 좋습니다.
그리고 Borland C ++에서는 Oracle과 함께 작업하기 위해 매우 편리한 클래스가 생성된다는 점을 추가하겠습니다. 2012년까지 그와 함께 일했는데, 지금은 어떻게 되는지 모르겠다.
VC ++에서 대화 상자 템플릿을 한 번 이상 사용하고, MFC에서 CDialog를 기반으로 응용 프로그램을 만들고, 시각적 모드에서 모든 종류의 컨트롤을 설치하고, 기성 기능을 사용 하여 OOP의 전체 기능을 이해하는 것이 좋습니다.
그리고 Borland C ++에서는 Oracle과 함께 작업하기 위해 매우 편리한 클래스가 생성된다는 점을 추가하겠습니다. 2012년까지 그와 함께 일했는데, 지금은 어떻게 되는지 모르겠다.
마당에서 2019년 하반기 .... 하지만 20일과 25일 그리고 .... 그들도 OOP를 사용할 필요성에 대해 이야기할까요?
))))
우리는 그것을 좋아한다, 우리는 그것을 좋아하지 않는다-글쎄, 오늘 당신의 발을 서지 마십시오, 나는 일어났습니다, 우리는 그것을 사용하지 않습니다
이전에 작성된 작은 서브루틴을 사용하여 프로그램을 작성하는 데 사용 - 쓰기, 잘못된 발을 딛고 ... 글쎄, 이 모든 서브루틴을 소스 코드로 대체하고 코드의 큰 발판을 얻으십시오.
사람들에게 PL에 대한 좋은 기회를 주었지만 여전히 동일하지 않습니다. 기능을 순수 C로 줄이십시오. 다시는 그렇지 않을 것입니다.))))
추신: 어쨌든 개발자 중 한 명이 포럼을 읽는 것 같습니다... 제 생각에 이 스레드는 확실히 기분을 고조시킵니다! ))))