예 .. 양 고추 냉이는 더 달콤하지 않습니다 :) 아이디어는 최소한의 몸 움직임으로 디버깅 및 코드 작성을 용이하게하는 적절한 프로그래밍 언어이지만 여기서는 완전히 반대 상황이 있습니다 ...
이것은 "반대 상황"이 아닙니다. 실제로 OOP에는 몇 가지 추가 단계가 필요합니다. 그러나 이것은 시스템 유지 관리 및 수정의 편의성으로 인해 상쇄되는 것 이상입니다.
여기서 다시 - 거래 프로세서로 돌아가서 - 많은 TS에서 작성되고 사용됩니다. TS에서 내부를 격리하고 가상 인터페이스를 통해서만 작동하므로 변수가 무엇인지, 변수가 무엇과 같은지 생각하지 않아도 됩니다. 오류가 감지되면 프로세서 내부에 있게 되며 차량 등급에 영향을 미치지 않으면서 실제 등급 내부에서 수정해야 합니다. 오류가 TS 자체에 있는 경우 거래 프로세서의 변수에 영향을 미치지 않습니다.
예 .. 양 고추 냉이는 더 달콤하지 않습니다 :) 아이디어는 최소한의 몸 움직임으로 디버깅 및 코드 작성을 용이하게하는 적절한 프로그래밍 언어이지만 여기서는 완전히 반대 상황이 있습니다 ...
디버깅은 각 클래스의 책임을 구분하여 정확하게 촉진됩니다. 각 클래스는 고유한 변수 집합을 담당합니다. 다른 클래스는 값을 변경할 권리가 없습니다. 결과적으로 대부분의 문제는 프로그램을 컴파일하는 단계에서 이미 잘립니다. 그리고 프로그램의 어느 곳에서나변수에 액세스하는 것은 한 배에 있는 12개의 핸들과 비교할 수 있습니다.
그래서 같은 얘기를 하는 겁니다... 필요한 변수의 값만 보는 대신에 적절한 인터페이스를 연결한 다음 다시 연결 해제하는 방법을 생각해야 합니다. :)
프로그래밍에 있어서 마조히스트들의 직업인 것 같습니다 :)
Vaughn, 더 높은 주제에 Peter는 자신의 가장 큰 구조가 아니라 하나를 게시했습니다.
쉽게 이해되시나요?
이 "마조히즘"은 첫째, 작업 코드에 들어가지 않고 망치지 않도록합니다. 둘째, 프로그램의 적절한 블록에 필요한 데이터를 제공하는 방식으로 시스템 구조를 즉시 설계 합니다.
예, 실제로 필요한 데이터를 얻는 것이 거의 불가능하다는 것이 갑자기 밝혀지는 상황이 있습니다. 여러 가상 인터페이스 뒤에 숨겨져 있습니다. 그러나 이 상황은 시스템이 원래 잘못 설계되었으며 이 데이터의 전송을 제공하지 않았음을 분명히 보여줍니다. 이 상황은 정말, 정말 나쁩니다. 추가 인터페이스의 형태로 "목발"을 급하게 조각하거나 단순히 전체 시스템을 재구성해야 합니다. 음... 프로그래머가 시스템 아키텍처에 대해 더 신중하게 생각하도록 동기를 부여합니다.
2. 내 의견으로는, 10배 정도(10배). 그러나 OOP의 주요 이점은 코드 유지 관리입니다. 이제 1년 이상 전에 작성한 코드를 매우 빠르게 이해하고 있습니다. 순전히 절차적인 방식으로 초기 ANSI C 프로그램을 어떻게 이해했는지 잘 기억하고 있습니다. 훨씬 더 어려웠습니다.
디버깅은 각 클래스의 책임을 구분하여 정확하게 촉진됩니다. 각 클래스는 고유한 변수 집합을 담당합니다. 다른 클래스는 값을 변경할 권리가 없습니다. 결과적으로 대부분의 문제는 프로그램을 컴파일하는 단계에서 이미 잘립니다. 그리고 프로그램의 어느 곳에서나 변수에 액세스하는 것은 한 배에 있는 12개의 핸들과 비교할 수 있습니다.
왜 내 작업에서 이런 것을 본 적이 없는지 이해할 수 없습니다. 하나의 큰 프로그램이 아닌 하나의 개발자에서 변수에 대한 액세스 차별화의 문제는 어디에서 발생합니까? 100명의 개발자가 있고 각 개발자는 100개의 함수를 작성합니다. 이론적으로는 그럴 수 있습니다. 그러나 실제로 프로그래밍은 거의 40년 동안 OOP로 발전했으며 수많은 코드가 작성되었으며 나는 그런 것을 들어본 적이 없습니다.
주의하십시오. 우리는 MT의 내부 변수에 대해 이야기하는 것이 아니라 디버깅하고 코드를 작성하는 동안 값을 읽을 가능성을 방지하기 위해 분리한 개체의 내부 변수에 대해 이야기하는 것입니다...
그래서 내 말은 - Expert Advisor를 디버그할 때 - 내부 MT 변수가 필요하지 않습니까?
유사하게, 이 경우 거래 프로세서 개체와 함께 - 예를 들어 TS에서 지연을 설정하는 방법을 디버깅하는 경우 - 거래 프로세서의 내부 변수에 액세스해야 하는 이유는 무엇입니까?
Andrei는 Peter 또는 Sansanych보다 훨씬 더 임상적입니다. 시간 낭비
청소년은 가르쳐야 합니다.
또한, 상대방의 말에 이성적인 부분이 있을 가능성도 있습니다. 나는 Peter's와 같은 기억을 갖고 있을 것입니다. 아마도 OOP도 신경쓰지 않을 것입니다.
유사하게, 일부 데이터가 필요한 경우 다른 위치에서 이 블록은 적절한 인터페이스를 제공해야 합니다.
그래서 같은 얘기를 하는 겁니다... 필요한 변수의 값만 보는 대신에 적절한 인터페이스를 연결한 다음 다시 연결 해제하는 방법을 생각해야 합니다. :)
프로그래밍에 있어서 마조히스트들의 직업 같네요 :)
예 .. 양 고추 냉이는 더 달콤하지 않습니다 :) 아이디어는 최소한의 몸 움직임으로 디버깅 및 코드 작성을 용이하게하는 적절한 프로그래밍 언어이지만 여기서는 완전히 반대 상황이 있습니다 ...
이것은 "반대 상황"이 아닙니다. 실제로 OOP에는 몇 가지 추가 단계가 필요합니다. 그러나 이것은 시스템 유지 관리 및 수정의 편의성으로 인해 상쇄되는 것 이상입니다.
여기서 다시 - 거래 프로세서로 돌아가서 - 많은 TS에서 작성되고 사용됩니다. TS에서 내부를 격리하고 가상 인터페이스를 통해서만 작동하므로 변수가 무엇인지, 변수가 무엇과 같은지 생각하지 않아도 됩니다. 오류가 감지되면 프로세서 내부에 있게 되며 차량 등급에 영향을 미치지 않으면서 실제 등급 내부에서 수정해야 합니다. 오류가 TS 자체에 있는 경우 거래 프로세서의 변수에 영향을 미치지 않습니다.
현실적으로 캡슐화는 매우 유용한 기술입니다.
예 .. 양 고추 냉이는 더 달콤하지 않습니다 :) 아이디어는 최소한의 몸 움직임으로 디버깅 및 코드 작성을 용이하게하는 적절한 프로그래밍 언어이지만 여기서는 완전히 반대 상황이 있습니다 ...
디버깅은 각 클래스의 책임을 구분하여 정확하게 촉진됩니다. 각 클래스는 고유한 변수 집합을 담당합니다. 다른 클래스는 값을 변경할 권리가 없습니다. 결과적으로 대부분의 문제는 프로그램을 컴파일하는 단계에서 이미 잘립니다. 그리고 프로그램의 어느 곳에서나변수에 액세스하는 것은 한 배에 있는 12개의 핸들과 비교할 수 있습니다.
청소년은 가르쳐야 합니다.
또한, 상대방의 말에 이성적인 부분이 있을 가능성도 있습니다. 나는 Peter's와 같은 기억을 갖고 있을 것입니다. 아마도 OOP도 신경쓰지 않을 것입니다.
1. OOP를 사용 하여 Expert Advisors의 수익성이 얼마나 향상되었습니까?
2. 귀하의 어드바이저가 OOP 사용을 거부하는 사이의 시간은 얼마나 감소했습니까?
그래서 같은 얘기를 하는 겁니다... 필요한 변수의 값만 보는 대신에 적절한 인터페이스를 연결한 다음 다시 연결 해제하는 방법을 생각해야 합니다. :)
프로그래밍에 있어서 마조히스트들의 직업인 것 같습니다 :)
Vaughn, 더 높은 주제에 Peter는 자신의 가장 큰 구조가 아니라 하나를 게시했습니다.
쉽게 이해되시나요?
이 "마조히즘"은 첫째, 작업 코드에 들어가지 않고 망치지 않도록합니다. 둘째, 프로그램의 적절한 블록에 필요한 데이터를 제공하는 방식으로 시스템 구조를 즉시 설계 합니다.
예, 실제로 필요한 데이터를 얻는 것이 거의 불가능하다는 것이 갑자기 밝혀지는 상황이 있습니다. 여러 가상 인터페이스 뒤에 숨겨져 있습니다. 그러나 이 상황은 시스템이 원래 잘못 설계되었으며 이 데이터의 전송을 제공하지 않았음을 분명히 보여줍니다. 이 상황은 정말, 정말 나쁩니다. 추가 인터페이스의 형태로 "목발"을 급하게 조각하거나 단순히 전체 시스템을 재구성해야 합니다. 음... 프로그래머가 시스템 아키텍처에 대해 더 신중하게 생각하도록 동기를 부여합니다.
감정과 반성이 덜하고 토론의 본질에 대한 세부 사항이 더 많았다면 가격이 없었을 것입니다. :)
이 토론은 더 이상 의미가 없습니다. 당신은 근본적으로 범람하고 어리석은 척합니다.
중재자가 일반적으로 프로그래밍 및 브랜치의 주제와 관련이 없는 것으로 마지막 몇 페이지를 문지른다면 제가 그의 행동을 지지하는 드문 경우가 있을 것입니다.
1. OOP를 사용 하여 Expert Advisors의 수익성이 얼마나 향상되었습니까?
2. 귀하의 어드바이저가 OOP 사용을 거부하는 사이의 시간은 얼마나 감소했습니까?
1. 얼마가 아닙니다. 수익성은 OOP에 의존하지 않습니다.
2. 내 의견으로는, 10배 정도(10배). 그러나 OOP의 주요 이점은 코드 유지 관리입니다. 이제 1년 이상 전에 작성한 코드를 매우 빠르게 이해하고 있습니다. 순전히 절차적인 방식으로 초기 ANSI C 프로그램을 어떻게 이해했는지 잘 기억하고 있습니다. 훨씬 더 어려웠습니다.
디버깅은 각 클래스의 책임을 구분하여 정확하게 촉진됩니다. 각 클래스는 고유한 변수 집합을 담당합니다. 다른 클래스는 값을 변경할 권리가 없습니다. 결과적으로 대부분의 문제는 프로그램을 컴파일하는 단계에서 이미 잘립니다. 그리고 프로그램의 어느 곳에서나 변수에 액세스하는 것은 한 배에 있는 12개의 핸들과 비교할 수 있습니다.
왜 내 작업에서 이런 것을 본 적이 없는지 이해할 수 없습니다. 하나의 큰 프로그램이 아닌 하나의 개발자에서 변수에 대한 액세스 차별화의 문제는 어디에서 발생합니까? 100명의 개발자가 있고 각 개발자는 100개의 함수를 작성합니다. 이론적으로는 그럴 수 있습니다. 그러나 실제로 프로그래밍은 거의 40년 동안 OOP로 발전했으며 수많은 코드가 작성되었으며 나는 그런 것을 들어본 적이 없습니다.