아마도 사용자와의 인터페이스를 구성하기 위해? 그것은 OOP에 대한 많은 옵션이 쌓여있는 곳이며 Delphi 시각적 구성 요소의 라이브러리 하나는 가치가 있습니다. 따라서 고문과 스크립트는 컴퓨터에서 사람을 대체하도록 설계되었으며이 인터페이스는 목적과 직접적으로 모순되며 필요하지 않습니다. 즉, 방해합니다. 주머니칼에 추가 품목처럼. 또는 범용 망치의 강철 손잡이 끝에 있는 못 풀러 - 긁힘뿐만 아니라 무게 중심을 스트라이커에서 손잡이로 이동시킵니다.
나는 이 특정한 점에 대해 당신과 동의하지 않습니다.
그래픽 인터페이스 는 오늘날 완전 자동화된 어드바이저가 반자동 어드바이저보다 훨씬 덜 효과적이라는 것을 이해하는 알고리즘 거래자에게 필요할 수 있습니다. 자동 거래와 수동 거래를 결합하면 거래 측면에서 더 전문적이고 수익성이 있을 수 있습니다. 사람들이 이것을 이해하면 로봇은 확실히 인터페이스가 필요합니다.
1. Chart_id는 m_chart_id보다 러시아어를 사용하는 사람이 더 빨리 읽습니다.
2. 프로그램에 수백 개의 변수가 있는 경우 러시아어는 필수 지원을 제공합니다.
이 모든 것은 실험적으로 확인할 수 있습니다.
모국어로 된 코드를 읽고 이해하는 속도는 항상 더 빨라지고 암기는 더 좋아질 것입니다.
러시아어로 변수 이름 지정 규칙을 개발하기만 하면 됩니다. "variable_to_store_the_total_profit_of_position" 대신 간단히 Total_profit.
프로그램에 수백 개의 변수가 있는 경우 대부분은 확실히 구조와 결합될 수 있습니다. 또한 기능을 사용하는 것을 잊지 마십시오. 많은 변수는 의미론적 부하를 전혀 전달하지 않습니다. 카운터는 중간 데이터의 임시 저장소이며 많은 대괄호 뒤에 사용됩니다. 그리고 가장 좋은 점은 모든 대괄호 뒤에 동일한 변수를 다시 사용할 수 있지만 대괄호 {....}에서 다시 사용할 수 있다는 것입니다.
그의 OOP 거부의 본질은 여기에 있다고 생각한다. 물론 내가 틀릴 수도 있지만 나는 보통 사람을 느낀다.
내 생각에 PLO를 받아들이지 않는 대다수의 문제는 '법적 권리의 제한'에 대한 내부 저항이다.
구식 프로그래머는 언제든지 모든 데이터, 모든 블록, 프로그램의 모든 본질에 대한 전체 액세스 권한이 있다는 사실에 익숙합니다. 그리고 OOP 접근 방식은 반대를 의미합니다. 권한의 최대 제한은 사용자가 프로그램의 데이터와 작업의 아주 작은 부분에 액세스할 수 있을 때입니다.
내가 기억하는 한 나는 그것을 정말로 좋아하지 않았다. Windows를 시작할 때만 메모리에 대한 보호된 액세스에 대해 얼마나 격분했는지 기억합니다. 어때요, 제가 좋아하는 주소에 액세스할 기회가 없습니다. 그래서 그것이 시스템에 있다면 어떻게 될까요? 핵심? 프로그램에서 읽거나 변경하고 싶을 수도 있습니다! 시스템 제한을 우회하여 "금지된" 영역에서 "허용된 영역"으로 데이터를 보내는 직접 메모리 액세스 컨트롤러를 프로그래밍한 시점에 이르렀습니다.
그러나 시간이 지남에 따라 이러한 모든 제한 사항에 감사하게 되었습니다. "불필요한" 액세스는 항상 오류를 초래할 수 있습니다. 따라서 접근 제어 작업을 컴파일러에 이전하는 것이 매우 합리적입니다. 여기서 의 접근 제한은 "귀하의 권리 침해"가 아니라 "바보로부터의 보호"가 됩니다. 당신이 가지고 있지 않은 액세스가 필요한 경우 - 그것은 단지 잘못된 시스템 설계를 의미합니다 - 그것이 필요하기 때문에 그러한 액세스의 가능성을 제공하는 것이 필요했습니다.
그리고 지금은 반대로 항상 액세스를 최대로 제한합니다. 어느 시점에서든 필요한 엔터티에만 액세스할 수 있어야 합니다. 다른 모든 개체 - 액세스할 수 없어야 합니다. 이렇게 하면 액세스하지 말아야 할 위치에 액세스할 때 실수를 방지할 수 있으며, 각 작업이 한 곳에서 수행되고 다른 위치에 영향을 주지 않는 특정 시스템 개발 순서도 알려줍니다.
오늘날 완전 자동화된 어드바이저가 반자동 어드바이저보다 훨씬 덜 효율적이라는 것을 이해하는 알고리즘 거래자는 그래픽 인터페이스가 필요할 수 있습니다. 자동 거래와 수동 거래를 결합하면 거래 측면에서 더 전문적이고 수익성이 있을 수 있습니다. 사람들이 이것을 이해하면 로봇은 확실히 인터페이스가 필요합니다.
mql은 서버 접근 기능만 있어야 하고 나머지는 모두 제3자 개발 도구로 목발로 프로그래밍해야 한다고 말하는 사람을 전적으로 지지합니다. 파티 라인에서 벗어나지 마십시오. 일관성을 유지하십시오. 모든 개발을 mql에서 실행하고 다리를 만드십시오. 예를 들어 스튜디오에 연결하거나 그곳에서 캔버스를 칠할 장소로 이동하십시오. 그런 다음 공장을 상대로 한 다음 승리에 대해 보고하십시오.
내 생각에 PLO를 받아들이지 않는 대다수의 문제는 '법적 권리의 제한'에 대한 내부 저항이다.
구식 프로그래머는 언제든지 모든 데이터, 모든 블록, 프로그램의 모든 본질에 대한 전체 액세스 권한이 있다는 사실에 익숙합니다. 그리고 OOP 접근 방식은 반대를 의미합니다. 권한의 최대 제한은 사용자가 프로그램의 데이터와 작업의 아주 작은 부분에 액세스할 수 있을 때입니다.
내가 기억하는 한 나는 그것을 정말로 좋아하지 않았다. Windows를 시작할 때만 메모리에 대한 보호된 액세스에 대해 얼마나 격분했는지 기억합니다. 어때요, 제가 좋아하는 주소에 액세스할 기회가 없습니다. 그래서 그것이 시스템에 있다면 어떻게 될까요? 핵심? 프로그램에서 읽거나 변경하고 싶을 수도 있습니다! 시스템 제한을 우회하여 "금지된" 영역에서 "허용된 영역"으로 데이터를 보내는 직접 메모리 액세스 컨트롤러를 프로그래밍한 시점에 이르렀습니다.
그러나 시간이 지남에 따라 이러한 모든 제한 사항에 감사하게 되었습니다. "불필요한" 액세스는 항상 오류를 초래할 수 있습니다. 따라서 접근 제어 작업을 컴파일러에 이전하는 것이 매우 합리적입니다. 여기서 의 접근 제한은 "귀하의 권리 침해"가 아니라 "바보로부터의 보호"가 됩니다. 당신이 가지고 있지 않은 액세스가 필요한 경우 - 그것은 단지 잘못된 시스템 설계를 의미합니다 - 그것이 필요하기 때문에 그러한 액세스의 가능성을 제공하는 것이 필요했습니다.
그리고 지금은 반대로 항상 액세스를 최대로 제한합니다. 어느 시점에서든 필요한 엔터티에만 액세스할 수 있어야 합니다. 다른 모든 개체 - 액세스할 수 없어야 합니다. 이렇게 하면 액세스하지 말아야 할 위치에 액세스할 때 실수를 방지할 수 있으며, 각 작업이 한 곳에서 수행되고 다른 위치에 영향을 주지 않는 특정 시스템 개발 순서도 알려줍니다.
당신은 OOP가 거부할 수 있는 것에 대한 좋은 예를 들었습니다.
제 경우에는 조금 달랐습니다. 과감하게 OOP 연구를 시작했지만 어느 단계에서 OOP 사용의 실질적인 이점을 보지 못했습니다. 지금까지 이것은 변경되지 않았습니다. 모든 것은 내가 접근 방식을 형성했기 때문에 OOP가 내 연습에서 제외되었습니다.
다음은 액세스 제한이 오류로부터 보호하는 필수 보호라는 진술입니다. 저는 어떤 식으로든 이해할 수 없습니다. 프로그램의 다른 부분에서 변수 이름이 일치하므로 의심할 여지 없이 그렇습니다. 그러나 하나의 배열에 모든 주요 전역 변수에 대한 공통 전역 메모리가 있다면 제한이 필요하지 않으며 혼란도 없을 것입니다.
Vladimir :
아마도 사용자와의 인터페이스를 구성하기 위해? 그것은 OOP에 대한 많은 옵션이 쌓여있는 곳이며 Delphi 시각적 구성 요소의 라이브러리 하나는 가치가 있습니다. 따라서 고문과 스크립트는 컴퓨터에서 사람을 대체하도록 설계되었으며이 인터페이스는 목적과 직접적으로 모순되며 필요하지 않습니다. 즉, 방해합니다. 주머니칼에 추가 품목처럼. 또는 범용 망치의 강철 손잡이 끝에 있는 못 풀러 - 긁힘뿐만 아니라 무게 중심을 스트라이커에서 손잡이로 이동시킵니다.
나는 이 특정한 점에 대해 당신과 동의하지 않습니다.
그래픽 인터페이스 는 오늘날 완전 자동화된 어드바이저가 반자동 어드바이저보다 훨씬 덜 효과적이라는 것을 이해하는 알고리즘 거래자에게 필요할 수 있습니다. 자동 거래와 수동 거래를 결합하면 거래 측면에서 더 전문적이고 수익성이 있을 수 있습니다. 사람들이 이것을 이해하면 로봇은 확실히 인터페이스가 필요합니다.
1. Chart_id는 m_chart_id보다 러시아어를 사용하는 사람이 더 빨리 읽습니다.
2. 프로그램에 수백 개의 변수가 있는 경우 러시아어는 필수 지원을 제공합니다.
이 모든 것은 실험적으로 확인할 수 있습니다.
모국어로 된 코드를 읽고 이해하는 속도는 항상 더 빨라지고 암기는 더 좋아질 것입니다.
러시아어로 변수 이름 지정 규칙을 개발하기만 하면 됩니다. "variable_to_store_the_total_profit_of_position" 대신 간단히 Total_profit.
프로그램에 수백 개의 변수가 있는 경우 대부분은 확실히 구조와 결합될 수 있습니다. 또한 기능을 사용하는 것을 잊지 마십시오.
많은 변수는 의미론적 부하를 전혀 전달하지 않습니다. 카운터는 중간 데이터의 임시 저장소이며 많은 대괄호 뒤에 사용됩니다. 그리고 가장 좋은 점은 모든 대괄호 뒤에 동일한 변수를 다시 사용할 수 있지만 대괄호 {....}에서 다시 사용할 수 있다는 것입니다.
또는 처음에는 OOP로 작성하십시오.
그의 OOP 거부의 본질은 여기에 있다고 생각한다. 물론 내가 틀릴 수도 있지만 나는 보통 사람을 느낀다.
내 생각에 PLO를 받아들이지 않는 대다수의 문제는 '법적 권리의 제한'에 대한 내부 저항이다.
구식 프로그래머는 언제든지 모든 데이터, 모든 블록, 프로그램의 모든 본질에 대한 전체 액세스 권한이 있다는 사실에 익숙합니다. 그리고 OOP 접근 방식은 반대를 의미합니다. 권한의 최대 제한은 사용자가 프로그램의 데이터와 작업의 아주 작은 부분에 액세스할 수 있을 때입니다.
내가 기억하는 한 나는 그것을 정말로 좋아하지 않았다. Windows를 시작할 때만 메모리에 대한 보호된 액세스에 대해 얼마나 격분했는지 기억합니다. 어때요, 제가 좋아하는 주소에 액세스할 기회가 없습니다. 그래서 그것이 시스템에 있다면 어떻게 될까요? 핵심? 프로그램에서 읽거나 변경하고 싶을 수도 있습니다! 시스템 제한을 우회하여 "금지된" 영역에서 "허용된 영역"으로 데이터를 보내는 직접 메모리 액세스 컨트롤러를 프로그래밍한 시점에 이르렀습니다.
그러나 시간이 지남에 따라 이러한 모든 제한 사항에 감사하게 되었습니다. "불필요한" 액세스는 항상 오류를 초래할 수 있습니다. 따라서 접근 제어 작업을 컴파일러에 이전하는 것이 매우 합리적입니다. 여기서 의 접근 제한은 "귀하의 권리 침해"가 아니라 "바보로부터의 보호"가 됩니다. 당신이 가지고 있지 않은 액세스가 필요한 경우 - 그것은 단지 잘못된 시스템 설계를 의미합니다 - 그것이 필요하기 때문에 그러한 액세스의 가능성을 제공하는 것이 필요했습니다.
그리고 지금은 반대로 항상 액세스를 최대로 제한합니다. 어느 시점에서든 필요한 엔터티에만 액세스할 수 있어야 합니다. 다른 모든 개체 - 액세스할 수 없어야 합니다. 이렇게 하면 액세스하지 말아야 할 위치에 액세스할 때 실수를 방지할 수 있으며, 각 작업이 한 곳에서 수행되고 다른 위치에 영향을 주지 않는 특정 시스템 개발 순서도 알려줍니다.
예를 들어, 나는 라이브러리 형태의 포함을 참을 수 없습니다. 어리석게도 거기에 무엇이 채워져 있고 그것이 나에게 어떻게 도움이 될지 모르기 때문에 12개 이상의 함수를 작성하는 것이 더 쉽습니다.
Peter Konow와 유추하여.
그리고 왜 ?
많은 곳에서 동일한 기능이 필요합니다. 라이브러리에 모든 것을 포함할 수 있고 불필요한 블록으로 기본 코드를 어지럽히지 않을 때 기능을 복사하여 붙여넣는 이유는 무엇입니까?
그리고 왜 ?
많은 곳에서 동일한 기능이 필요합니다. 라이브러리에 모든 것을 포함할 수 있고 불필요한 블록으로 기본 코드를 어지럽히지 않을 때 기능을 복사하여 붙여넣는 이유는 무엇입니까?
Nikolay가 주장을 찾는 방법을 알고 있습니다.)
할머니도 문제없이 모든 것을 배울 수 있습니다. 그녀는 무의식적으로 자신의 안정된 마음을 불필요한 정보의 순환으로 끌어들이는 장신구를 원하지 않습니다. 그는 그것을 올바르게 한다.)
피터, 당신은 할머니입니다.
여보세요
어쩌면 그들은 여기에서 나를 도울 수 있습니다. MT4 개발자에게 질문이 있습니다. 어디에서 목소리를 낼 수 있습니까? 이 포럼에 있다면 어떤 스레드에 있습니까? 아니면 다른 곳에서? 아시는 분은 알려주세요.
나는 이 특정한 점에 대해 당신과 동의하지 않습니다.
오늘날 완전 자동화된 어드바이저가 반자동 어드바이저보다 훨씬 덜 효율적이라는 것을 이해하는 알고리즘 거래자는 그래픽 인터페이스가 필요할 수 있습니다. 자동 거래와 수동 거래를 결합하면 거래 측면에서 더 전문적이고 수익성이 있을 수 있습니다. 사람들이 이것을 이해하면 로봇은 확실히 인터페이스가 필요합니다.
mql은 서버 접근 기능만 있어야 하고 나머지는 모두 제3자 개발 도구로 목발로 프로그래밍해야 한다고 말하는 사람을 전적으로 지지합니다. 파티 라인에서 벗어나지 마십시오. 일관성을 유지하십시오. 모든 개발을 mql에서 실행하고 다리를 만드십시오. 예를 들어 스튜디오에 연결하거나 그곳에서 캔버스를 칠할 장소로 이동하십시오. 그런 다음 공장을 상대로 한 다음 승리에 대해 보고하십시오.
예를 들어, 나는 라이브러리 형태의 포함을 참을 수 없습니다. 어리석게도 거기에 무엇이 채워져 있고 그것이 나에게 어떻게 도움이 될지 모르기 때문에 12개 이상의 함수를 작성하는 것이 더 쉽습니다.
Peter Konow와 유추하여.
글쎄요, 에너지 보존 법칙: 라이브러리 없이 모든 것이 작동한다면 왜 라이브러리를 디컴파일하고 이해합니까?
Z.Y
무스에 관한 내 상의가 만났습니까?
코드가 10, 20, 30, ..., 100,000줄을 넘기 시작하면 돌아와서 그러한 볼륨에 코드를 복사하여 붙여넣는 방법을 알려주십시오.
내 생각에 PLO를 받아들이지 않는 대다수의 문제는 '법적 권리의 제한'에 대한 내부 저항이다.
구식 프로그래머는 언제든지 모든 데이터, 모든 블록, 프로그램의 모든 본질에 대한 전체 액세스 권한이 있다는 사실에 익숙합니다. 그리고 OOP 접근 방식은 반대를 의미합니다. 권한의 최대 제한은 사용자가 프로그램의 데이터와 작업의 아주 작은 부분에 액세스할 수 있을 때입니다.
내가 기억하는 한 나는 그것을 정말로 좋아하지 않았다. Windows를 시작할 때만 메모리에 대한 보호된 액세스에 대해 얼마나 격분했는지 기억합니다. 어때요, 제가 좋아하는 주소에 액세스할 기회가 없습니다. 그래서 그것이 시스템에 있다면 어떻게 될까요? 핵심? 프로그램에서 읽거나 변경하고 싶을 수도 있습니다! 시스템 제한을 우회하여 "금지된" 영역에서 "허용된 영역"으로 데이터를 보내는 직접 메모리 액세스 컨트롤러를 프로그래밍한 시점에 이르렀습니다.
그러나 시간이 지남에 따라 이러한 모든 제한 사항에 감사하게 되었습니다. "불필요한" 액세스는 항상 오류를 초래할 수 있습니다. 따라서 접근 제어 작업을 컴파일러에 이전하는 것이 매우 합리적입니다. 여기서 의 접근 제한은 "귀하의 권리 침해"가 아니라 "바보로부터의 보호"가 됩니다. 당신이 가지고 있지 않은 액세스가 필요한 경우 - 그것은 단지 잘못된 시스템 설계를 의미합니다 - 그것이 필요하기 때문에 그러한 액세스의 가능성을 제공하는 것이 필요했습니다.
그리고 지금은 반대로 항상 액세스를 최대로 제한합니다. 어느 시점에서든 필요한 엔터티에만 액세스할 수 있어야 합니다. 다른 모든 개체 - 액세스할 수 없어야 합니다. 이렇게 하면 액세스하지 말아야 할 위치에 액세스할 때 실수를 방지할 수 있으며, 각 작업이 한 곳에서 수행되고 다른 위치에 영향을 주지 않는 특정 시스템 개발 순서도 알려줍니다.
당신은 OOP가 거부할 수 있는 것에 대한 좋은 예를 들었습니다.
제 경우에는 조금 달랐습니다. 과감하게 OOP 연구를 시작했지만 어느 단계에서 OOP 사용의 실질적인 이점을 보지 못했습니다. 지금까지 이것은 변경되지 않았습니다. 모든 것은 내가 접근 방식을 형성했기 때문에 OOP가 내 연습에서 제외되었습니다.
다음은 액세스 제한이 오류로부터 보호하는 필수 보호라는 진술입니다. 저는 어떤 식으로든 이해할 수 없습니다. 프로그램의 다른 부분에서 변수 이름이 일치하므로 의심할 여지 없이 그렇습니다. 그러나 하나의 배열에 모든 주요 전역 변수에 대한 공통 전역 메모리가 있다면 제한이 필요하지 않으며 혼란도 없을 것입니다.