MQL5에 OOP가 필요합니까? - 페이지 2

 
Svinozavr >> :

프로세스 또는 최종 결과에 관심이 있습니까?)))

나 - 둘 다이지만 결과는 어떻게 든 더 많습니다. ("...OOP는 프로그램을 느리게 하는 여러 가지 방법을 제공합니다...")

OOP가 절차적 접근 방식보다 더 빠르게 작성할 수 있고 OOP의 모든 단점을 능가하는 위치를 알지 못합니다. 누가 그것을 필요로 하는지 - 이것은 분명합니다 - 다른 사람을 위해 글을 쓰는 개발자입니다.


비유를 하자면, 첫 번째 사람은 칼을 들고 선조 조각상을 잘라냈고, 두 번째 사람은 같은 칼로 자신의 손가락 절반을 잘랐습니다. 무엇을 위한 것입니까? 모든 도구는 "사탕"과 완전한 평범함을 모두 만들 수 있습니다. 그것은 모두 프로그래머에게 달려 있습니다. 그가 장인인지 아니면 재능이 있는지 여부입니다. 이것은 후퇴이지만 실제로 FOP가 당신에게 더 가깝다면 더 멀리 사용하십시오.

 

주제를 만들면서 MT를 위한 프로젝트에서 OOP를 찬성하는 주장을 보고 싶었습니다. 아마도 내 무지 때문일 것입니다 - 나는 시시덕거리고 있지 않습니다 - 나는 그들을 보지 못했습니다. 나는 지금 그것을 볼 수 없습니다.

게시물을 요약해 보겠습니다. (그런데 모두 감사합니다):

1. 프로젝트 구현의 편의성과 속도.

이 편리함을 느끼기 위해서는 프로젝트의 볼륨이 어느 정도 되어야 할까요? OOP로 하면 더 편할 4-ki용으로 만든 것을 보여주세요. 답이 없습니다.

2. 유지 보수, 현대화.

다시 - 프로젝트의 크기.

3. 5는 FSU가 프로그래밍하는 방법이기 때문에 더 빠릅니다.

글쎄요, 그것은 전혀 논쟁이 아닙니다. 댓글이 없습니다.

3. OOP를 늦추는 이유로 곡률.

응. 평소에는 손으로 프로그램을 작성하는데 OOP가 하고 싶으면 컴퓨터로 등을 돌린다. ))) 아니다. OOP는 알고리즘이 유사한 절차적 OOP보다 객관적으로 느릴 것입니다.

----------

(어깨를 으쓱하며) 이해하세요. 저는 OOP에 반대하는 것이 아닙니다. MT를 위한 작업 - 칠면조, 스크립트, 고문을 만드는 데 OOP가 무엇을 줄 수 있는지 스스로 알고 싶었습니다.

확인. 5일 도움말입니다. 누가 5-ke에서 OOP를 사용하여 작성된 MT4의 표준 전달에서 간단한 칠면조의 예를 줄 수 있습니까? 거기에 보일 것입니다. 거기에서 지연은 텍스트의 눈, 프로그램의 가독성 등으로 추정할 수 있습니다.

 
Svinozavr писал(а) >>

1. 프로젝트 구현의 편의성과 속도.

이 편리함을 느끼기 위해서는 프로젝트의 볼륨이 어느 정도 되어야 할까요? OOP로 하면 더 편할 4-ki용으로 만든 것을 보여주세요. 답이 없습니다.

2. 유지 보수, 현대화.

다시 - 프로젝트의 크기.

1. OOP - 기본 원리를 이해하는 사람들에게 매우 편리합니다. 이것은 가장 간단한 응용 프로그램에서도 느껴집니다. OOP와 함께라면 어떤 앱이든 더욱 편리하게 만들 수 있습니다.

2. 프로젝트의 규모는 이해하기 어렵지 않다면 지장이 없다. 그리고 프로그램이 객체지향이라면 이해하는 것은 어렵지 않습니다. 예를 들어 SaxoBank 터미널이 있습니다. C#으로 작성 - 객체 지향 언어. 각 dll에는 약 20,000줄의 코드가 있습니다. OOP가 없었다면 이러한 방대한 정보를 이해하는 것은 거의 불가능했고 현대화하는 것은 더욱 불가능했을 것입니다.

 
5-ke에서는 OOP에 문제가 없습니다. 일반적으로 4-ke에서 구현된 프로젝트에서 대규모 프로젝트를 구현하는 방법이 아직 명확하지 않습니다. 그래픽 개체 작업 은 "암"으로 수행됩니다. 개발자들은 개선을 약속했지만 ... 아직까지는 개선이 느껴지지 않습니다. 장난감을 프로그래밍할 수 있게 되었습니다.
 
Svinozavr писал(а) >>

이 편리함을 느끼기 위해서는 프로젝트의 볼륨이 어느 정도 되어야 할까요? OOP로 하면 더 편할 4-ki용으로 만든 것을 보여주세요. 답이 없습니다.

아마도 nen의 ZUP 이 좋은 예가 될 것입니다. 거기에 물건이 많이 있습니다. 소스의 덩어리만으로도 내용은 말할 것도 없고(368Kb v82) 존경심을 불러일으킵니다.
 
5-ke에서 절차적 프로그래밍은 취소되지 않았습니다. oop가 마음에 들지 않으면 이전 방식으로 프로그램을 작성하십시오. 그러나 그래픽 표시기로 인해 큰 문제가 발생했습니다. 그것들은 구현하기가 매우 어려울 것입니다. 그리고 프로그래머를 위해. 그리고 그래픽 표시기를 사용하여 수동으로 거래하는 사람들을 위해. 프로그래머가 아닌 단순 거래자는 다시 배워야 합니다. 그리고 모든 사람이 올바르게 할 수 있는 것은 아닙니다.
 
MQ는 자동화 로봇의 도움으로 만 거래가 있다고 믿는 것 같습니다. 그리고 5는 로봇을 위해 특별히 연마되었습니다. 그들은 수동 거래 를 클래스로 없애기로 결정했습니다.
 

그것들은 이미 비 OOP를 기반으로 합니다(절대 OOP는 실제로 편리하지 않지만). 처음에는 추상 클래스를 만들고 상속과 다형성을 사용하여 실제 개체에 도달해야 했습니다. 예를 들어 추상 메서드 및 속성이 있는 사용자 지정 표시기 의 기본 추상 클래스입니다. 간단히 말해서, 계층적 클래스 트리를 구축하십시오. 그래픽 개체, 계정 작업, 차트 및 시계열 액세스 등을 위한 고유한 트리입니다. 그리고 미리 정의된 절차와 기능은 속도가 필요한 기본 루틴만 남겨둡니다. 그런 다음 모든 추상화 수준에서 플랫폼의 기능을 확장하는 것이 가능하여 코드를 크게 줄이고 가독성을 높이고 다른 프로그래머가 쉽게 이해할 수 있습니다. 그리고 MT5에서는 절차 수준(사실, 전체 플랫폼을 사용할 준비가 된 상태)에서 상당히 복잡한 것들이 이미 구현되어 있으며 생성된 내부 구조의 설명자에 대한 포인터로 액세스할 가능성을 보지 못했습니다. 가능성을 제한하십시오 (도움으로 판단). 그리고 일반적으로 OOP의 필요성은 의심스럽습니다. 이러한 구현을 통해 구조 및 동적 배치로 제한할 수 있었습니다. OOP는 분기된 클래스 계층 구조에 의해 아래에서 지원되어야 합니다. 임하

 

프로그램이 프로그래머에 의해 쓰여지는 것이 아니라 읽는다는 것을 깨닫는 데는 1-3년의 프로그래밍이 필요합니다.

프로그램이 컴퓨터가 아니라 사람(특히, 자신)을 위해 작성되었다는 사실을 깨달으려면 1~2년이 더 필요합니다.

그런 다음 OOP와 C++가 인간형 사고의 순서와 인간 언어를 구축하는 방법과 모순된다는 것을 알아차리는 데 1-2년이 걸립니다.

다른 사람의 원자재를 연구하고 가장 신뢰할 수 있는 프로그램이 고전 Ce로 작성되었음을 깨닫는 데 1-2년이 더 필요합니다.

글쎄, 그 후에 C ++ 및 OOP가 그에게 복통을 유발한다는 사실에 대한 Dijkstra의 인터뷰를 읽는 것으로 충분합니다.

그리고 그 이후(총 4-9년) "PLO에 관한" 질문은 전혀 발생하지 않으며 그러한 토론은 겸손한 미소만 만듭니다.

 
AlexEro >> :

그리고 그 이후(총 4-9년) "PLO에 관한" 질문은 전혀 발생하지 않으며 그러한 토론은 겸손한 미소만 만듭니다.

공감합니다.