현재 제 고객이 한 명 있습니다. 나는 그들에게 할당된 작업을 매우 빠르게 완료합니다. 3-4시간 후에 완전히 작동하는 새로운 창이 준비됩니다. 연결 인터페이스와 함께. 또한 신속하게 엔진 버그를 수정하고 새 버전을 푸시합니다. 며칠 만에 9개의 창 + 엔진 변경, 버그 수정, 기능 추가... 모든 것이 매우 빠릅니다.
글쎄요, 당신은 당신만으로는 충분하지 않다는 것을 이해합니다. 엔진의 대량 특성은 다른 프로그래머가 엔진을 좋아하는지 여부에 따라 달라집니다(당신만으로는 모든 고객에게 충분하지 않을 것입니다). 그리고 프로그램이 마음에 들지 않으면 ... 아아, 그리고 당신이 만든 작품의 운명은 불명예스러울 것입니다.
프로그래머는 엔진 코드에 들어갈 필요가 없습니다. 그들은 파일에서 그것에 대한 연결 인터페이스를 얻을 것입니다. 나는 이미 이것을 테스트했습니다. 모든 것이 작동합니다.
현재 제 고객이 한 명 있습니다. 나는 그들에게 할당된 작업을 매우 빠르게 완료합니다. 3-4시간 후에 완전히 작동하는 새로운 창이 준비됩니다. 연결 인터페이스와 함께. 또한 신속하게 엔진 버그를 수정하고 새 버전을 푸시합니다. 며칠 만에 9개의 창 + 엔진 변경, 버그 수정, 기능 추가... 모든 것이 매우 빠릅니다.
여기에서 올바르게, 그들은 Peter에게 장점으로 보이는 논쟁의 여지가 있는 문제와 반대자들에게 - 단점이 무엇인지 위에 말했습니다.
- 전역적으로 사용 가능한 변수의 무리, 캡슐화의 완전한 부재.
- 타입 컨트롤 부족
- 데이터 저장의 특정 구현에 대한 확고한 약속.
그리고 Peter는 OOP의 개념(적어도 내 제안에서는)이 "프로그래머의 편의에 기초하여" 단순화되어야 한다고 올바르게 말했습니다. 캡슐화, 유형 제어, 인터페이스 - 이 모든 것은 가능한 한 실수, 혼란, 오용 가능성을 제거하도록 설계되었습니다. 괜찮은.
베드로의 개념은 그 반대입니다. 모든 데이터는 어디서나 사용할 수 있으며 사용자는 코드의 모든 위치에서 모든 프로그램 개체를 완전히 제어할 수 있으며 유형 제한 없이 원하는 방식으로 개체를 인식할 수 있습니다(음, MQL 자체의 제한이 있을 수 있음).
Peter는 이러한 개념이 "최대한 개발을 달성할 수 있습니다. 편의성이 두 번째로 옵니다."라고 주장합니다.
저는 개인적으로 프로그래머로서 편의성이 2등이라는 사실을 좋아하지 않습니다. 그러나 실제로 우리가 훨씬 더 큰 발전을 얻는다면 이것은 희생 될 수 있습니다. 여기, 그것이 무엇인지보고 싶습니다. 제한 및 캡슐화를 사용하는 OOP 접근 방식은 하나의 거대한 크기 배열에 던져진 거대한 속성 배열에 대한 전체 액세스 권한이 있는 이 접근 방식과 같은 개발을 허용하지 않습니다. (나는 이 모든 것을 기억해야 할 필요성에 대해 말하는 것이 아니다).
위에서 언급한 것이 사실입니다. 접근 방식은 Pascal의 TurboVision과 유사합니다. 그러나 유형 제어 및 캡슐화 제한이 모두 이 라이브러리에 이미 설정되어 있습니다.
현재 제 고객이 한 명 있습니다. 나는 그들에게 할당된 작업을 매우 빠르게 완료합니다. 3-4시간 후에 완전히 작동하는 새로운 창이 준비됩니다. 연결 인터페이스와 함께. 또한 신속하게 엔진 버그를 수정하고 새 버전을 푸시합니다. 며칠 만에 9개의 창 + 엔진 변경, 버그 수정, 기능 추가... 모든 것이 매우 빠릅니다.
자유시간이 많이 있어야 합니다.
글쎄요, 당신은 당신만으로는 충분하지 않다는 것을 이해합니다. 엔진의 대량 특성은 다른 프로그래머가 엔진을 좋아하는지 여부에 따라 달라집니다(당신만으로는 모든 고객에게 충분하지 않을 것입니다). 그리고 프로그램이 마음에 들지 않으면 ... 아아, 그리고 당신이 만든 작품의 운명은 불명예스러울 것입니다.
프로그래머는 엔진 코드에 들어갈 필요가 없습니다. 그들은 파일에서 그것에 대한 연결 인터페이스를 얻을 것입니다. 나는 이미 이것을 테스트했습니다. 모든 것이 작동합니다.
현재 제 고객이 한 명 있습니다. 나는 그들에게 할당된 작업을 매우 빠르게 완료합니다. 3-4시간 후에 완전히 작동하는 새로운 창이 준비됩니다. 연결 인터페이스와 함께. 또한 신속하게 엔진 버그를 수정하고 새 버전을 푸시합니다. 며칠 만에 9개의 창 + 엔진 변경, 버그 수정, 기능 추가... 모든 것이 매우 빠릅니다.
거기에 제대로 쓰여있나요? 창을 만드는 데 3-4 시간 ? 분 아님?
저는 이 일을 1년 넘게 하고 있습니다. 그리고 나는 혼란스럽지 않습니다.))
비교를 위해 OOP를 사용 하여 동일하게 구현합니다. 그것을 시도, 당신은 그것을 좋아할 수 있습니다. :)
거기에 제대로 쓰여있나요? 창을 만드는 데 3-4 시간 ? 분 아님?
아니요. 다른 창의 코드를 복사하여 변경하면 몇 분 안에 할 수 있습니다. 그러나 나는 그래픽을 생각하고 스타일을 작업하면서 처음부터 만드는 것에 대해 이야기하고 있었습니다.
그건 그렇고, Peter, 몇 가지 데이터 형식(OHLC, Zigzag 등)을 지원하는 창에서만 표시기와 같은 다양한 종류의 차트를 추가하는 것을 잊지 마십시오. 이 모든 것이 프로젝트에서 쉽게 구현되기를 바랍니다.
노력하겠습니다.
노력하겠습니다.
노력하지 않겠지만 노력하겠습니다.) 창작물의 유용성을 높입니다.
거기에 제대로 쓰여있나요? 창을 만드는 데 3-4 시간 ? 분 아님?
말도 안되는 소리... MT의 표준 제공 라이브러리를 사용하여 MQL에서 3개의 창을 만들고 10분 동안 작업하고 또 다른 20-30분 동안 버튼, 편집, 레이블의 높이와 XY를 조정합니다...
Peter의 작업이 유용할 수 있는 두 가지 옵션이 있습니다.
- MQL 소스를 생성하기 위한 별도의 애플리케이션 생성, 즉 GUI 생성자이며 작동 방식에 대한 자세한 내용은 다루지 않습니다. 즉, Visual MQL++ )))
-또는: 스스로 어려움을 겪다가 성공적으로 극복한 사람들이 있습니다. © Wingston Churchill
Peter's OOP의 모든 구성원은 항상 세부 사항에 집착하는 것 같습니다.
그리고 질문의 본질은 바로 시스템의 철학과 아키텍처에 있습니다.
여기에서 올바르게, 그들은 Peter에게 장점으로 보이는 논쟁의 여지가 있는 문제와 반대자들에게 - 단점이 무엇인지 위에 말했습니다.
- 전역적으로 사용 가능한 변수의 무리, 캡슐화의 완전한 부재.
- 타입 컨트롤 부족
- 데이터 저장의 특정 구현에 대한 확고한 약속.
그리고 Peter는 OOP의 개념(적어도 내 제안에서는)이 "프로그래머의 편의에 기초하여" 단순화되어야 한다고 올바르게 말했습니다. 캡슐화, 유형 제어, 인터페이스 - 이 모든 것은 가능한 한 실수, 혼란, 오용 가능성을 제거하도록 설계되었습니다. 괜찮은.
베드로의 개념은 그 반대입니다. 모든 데이터는 어디서나 사용할 수 있으며 사용자는 코드의 모든 위치에서 모든 프로그램 개체를 완전히 제어할 수 있으며 유형 제한 없이 원하는 방식으로 개체를 인식할 수 있습니다(음, MQL 자체의 제한이 있을 수 있음).
Peter는 이러한 개념이 "최대한 개발을 달성할 수 있습니다. 편의성이 두 번째로 옵니다."라고 주장합니다.
저는 개인적으로 프로그래머로서 편의성이 2등이라는 사실을 좋아하지 않습니다. 그러나 실제로 우리가 훨씬 더 큰 발전을 얻는다면 이것은 희생 될 수 있습니다. 여기, 그것이 무엇인지보고 싶습니다. 제한 및 캡슐화를 사용하는 OOP 접근 방식은 하나의 거대한 크기 배열에 던져진 거대한 속성 배열에 대한 전체 액세스 권한이 있는 이 접근 방식과 같은 개발을 허용하지 않습니다. (나는 이 모든 것을 기억해야 할 필요성에 대해 말하는 것이 아니다).
위에서 언급한 것이 사실입니다. 접근 방식은 Pascal의 TurboVision과 유사합니다. 그러나 유형 제어 및 캡슐화 제한이 모두 이 라이브러리에 이미 설정되어 있습니다.