그리고 그들이 누구이며 무엇을 배우지 않았 는지 명확히 할 수 있습니까? 중재자는 청소하는 법이나 다른 것을 배우지 않았습니다)
추신: 그건 그렇고, 전체 지점에서 나는 항상 그렇듯이 일반적인 말다툼과 같은 주제를 다루려는 단일 희망을 보지 못했습니다. 그래서 OOP 장치에서 처음부터 YouTube에 비디오를 녹화하기로 결정했습니다. 적어도 약간의 이점이 있을 것입니다. 어쨌든, 잠시 후 분기는 branch_sump에 있을 것입니다.
나는 분명히 합니다. 그들은 OOP를 배우지 않았습니다.
Alexey, 나는 OOP를 가지고 그렇게 배울 수 없다는 것을 스스로 완벽하게 이해하고 있다고 생각합니다. OOP에 대한 형식적인 지식이 있습니다: 상속 , 캡슐화 , 다형성 - 이 모든 만트라는 종종 반복되지만 누군가가 MM 모듈에서 전문가 클래스를 상속하는 것처럼 맹렬하고 부적절하게 암기하고 적용한다는 사실입니다(안녕 SB 개발자 :) 득보다 실이 더 많습니다.
MQL의 경우 OOP의 관점에서 볼 때 매우 약한 언어입니다 . 유형 제어가 완전히 부재하고(적어도 안전한 캐스트를 수행함) 리플렉션이 초기 단계에 있고 매우 제한적이며 인터페이스가 전혀 없습니다. . 질문이 생깁니다. MQL에서 어떤 종류의 OOP를 가르칠 수 있습니까? 개발자들이 표준 라이브러리 에서 이러한 꼽추를 조각하여 때로는 무섭게 만든다면 뭐라고 말할 수 있습니까?
Alexey, 나는 OOP를 가지고 그렇게 배울 수 없다는 것을 스스로 완벽하게 이해하고 있다고 생각합니다. OOP에 대한 형식적인 지식이 있습니다: 상속 , 캡슐화 , 다형성 - 이 모든 만트라는 종종 반복되지만 누군가가 MM 모듈에서 전문가 클래스를 상속하는 것처럼 맹렬하고 부적절하게 암기하고 적용한다는 사실입니다(안녕 SB 개발자 :) 득보다 실이 더 많습니다.
MQL의 경우 OOP의 관점에서 볼 때 매우 약한 언어입니다 . 유형 제어가 완전히 부재하고(적어도 안전한 캐스트를 수행함) 리플렉션이 초기 단계에 있고 매우 제한적이며 인터페이스가 전혀 없습니다. . 질문이 생깁니다. MQL에서 어떤 종류의 OOP를 가르칠 수 있습니까? 개발자들이 표준 라이브러리 에서 이러한 꼽추를 조각하여 때로는 무섭게 만든다면 뭐라고 말할 수 있습니까?
예, 약하지만 중간 정도의 심각도 프로젝트는 여전히 수행할 수 있습니다. SB는 다양한 수준의 교육을 받은 다양한 사람들이 수행했습니다. 그리고 그것은 필수품을 가지고 있지 않습니다. 나는 여전히 당신의 CDictionary를 사용하고 있습니다.
그럼 이제 누워서 죽을까? )) 결국 dll로 갈 수 있습니다.
하지만 여전히 OOP를 배울 수 있다고 생각합니다. 독학 했어요 또는 혼자 배웠습니다. 그리고 다른 사람들도.
하지만 여전히 OOP를 배울 수 있다고 생각합니다. 독학 했어요 또는 혼자 배웠습니다. 그리고 다른 사람들도.
따라서 올바른 예에서 배워야 합니다. 그러나 그들은 SB에 존재하지 않습니다. 동일한 CObject를 사용합니다. 유형 제어를 제공하지 않고 인터페이스 수준에서 개체에 대한 작업을 제공하지 않지만 실제로 재정의되지 않는 Save() 및 Load()와 같은 의미 없는 메서드가 포함되어 있습니다. m_prev 및 m_next 포인터는 단일 CList 클래스 에서 사용되지만 모든 하위 클래스에 대한 안정기로 존재합니다. 가장 유용한 것은 Comparer() 메서드입니다. 실제로 가장 자주 재정의됩니다. 그러나 좋은 방법으로 Comparer()는 인터페이스이므로 CObject가 아닌 별도의 클래스로 정의하는 것이 더 정확합니다.
OOP의 경우 (전혀 추상적이지 않은) 실제 적용이 넓은 다음 기능이 절차 적 스타일에서 어떻게 보일지 매우 흥미 롭습니다.
분명히 모든 OOP는 절차적 스타일로 다시 작성할 수 있습니다. 하지만 저는 연습에 관심이 있습니다. 따라서 OOP를 최소한으로 사용하는 위의 작은 코드를 사용했습니다.
그렇다면 이 예에서 절차적 스타일은 OOP에 비해 얼마나 더 예쁘고/더 편리하고/더 읽기 쉽고/더 정확할까요? 글쎄, 몇 페이지를 입증하지 않기 위해서가 아니라 단순히 짧은 소스 코드를 절차적 대 OOP를 비교하기 위함입니다. OOP의 반대자들에게 마스터 클래스를 보여달라고 요청합니다. 이것은 끔찍한 MT5가 아니라 좋은 오래된 MT4입니다.
같은 방식으로 프로그래밍하는 방법을 배울 수 있는 패턴은 무엇입니까? :) 아주 좋은 모습
아니면 생각을 바꿔야 할 수도 있습니다.
예를 들어, 구조체가 생성자와 함께 클래스와 거의 같은 방식으로 사용될 수 있다는 것을 몰랐습니다.
따라서 올바른 예에서 배워야 합니다. 그러나 그들은 SB에 존재하지 않습니다. 동일한 CObject를 사용합니다. 유형 제어를 제공하지 않고 인터페이스 수준에서 개체에 대한 작업을 제공하지 않지만 실제로 재정의되지 않는 Save() 및 Load()와 같은 의미 없는 메서드가 포함되어 있습니다. m_prev 및 m_next 포인터는 단일 CList 클래스 에서 사용되지만 모든 하위 클래스에 대한 안정기로 존재합니다. 가장 유용한 것은 Comparer() 메서드입니다. 실제로 가장 자주 재정의됩니다. 그러나 좋은 방법으로 Comparer()는 인터페이스이므로 CObject가 아닌 별도의 클래스로 정의하는 것이 더 정확합니다.
많은 동지들이 하는 MQL 지식의 깊이에 항상 놀랐습니다. 보고, 실제로 CExpert를 적용해 보기도 하고, 침을 뱉기도 하고, 나만의 수업을 만들기 시작했습니다. 나는 CObject와 CExpert와 같은 높이까지 올라갈 수 없습니다.
추신: 그건 그렇고, 전체 지점에서 나는 항상 그렇듯이 일반적인 말다툼과 같은 주제를 다루려는 단일 희망을 보지 못했습니다.
초기 예의 선택으로 판단하면 조명 품질에 대해 상당히 합리적인 의심이 있습니다.
그리고 그들이 누구이며 무엇을 배우지 않았 는지 명확히 할 수 있습니까? 중재자는 청소하는 법이나 다른 것을 배우지 않았습니다)
추신: 그건 그렇고, 전체 지점에서 나는 항상 그렇듯이 일반적인 말다툼과 같은 주제를 다루려는 단일 희망을 보지 못했습니다. 그래서 OOP 장치에서 처음부터 YouTube에 비디오를 녹화하기로 결정했습니다. 적어도 약간의 이점이 있을 것입니다. 어쨌든, 잠시 후 분기는 branch_sump에 있을 것입니다.
나는 분명히 합니다. 그들은 OOP를 배우지 않았습니다.
Alexey, 나는 OOP를 가지고 그렇게 배울 수 없다는 것을 스스로 완벽하게 이해하고 있다고 생각합니다. OOP에 대한 형식적인 지식이 있습니다: 상속 , 캡슐화 , 다형성 - 이 모든 만트라는 종종 반복되지만 누군가가 MM 모듈에서 전문가 클래스를 상속하는 것처럼 맹렬하고 부적절하게 암기하고 적용한다는 사실입니다(안녕 SB 개발자 :) 득보다 실이 더 많습니다.
MQL의 경우 OOP의 관점에서 볼 때 매우 약한 언어입니다 . 유형 제어가 완전히 부재하고(적어도 안전한 캐스트를 수행함) 리플렉션이 초기 단계에 있고 매우 제한적이며 인터페이스가 전혀 없습니다. . 질문이 생깁니다. MQL에서 어떤 종류의 OOP를 가르칠 수 있습니까? 개발자들이 표준 라이브러리 에서 이러한 꼽추를 조각하여 때로는 무섭게 만든다면 뭐라고 말할 수 있습니까?
나는 분명히 합니다. 그들은 OOP를 배우지 않았습니다.
Alexey, 나는 OOP를 가지고 그렇게 배울 수 없다는 것을 스스로 완벽하게 이해하고 있다고 생각합니다. OOP에 대한 형식적인 지식이 있습니다: 상속 , 캡슐화 , 다형성 - 이 모든 만트라는 종종 반복되지만 누군가가 MM 모듈에서 전문가 클래스를 상속하는 것처럼 맹렬하고 부적절하게 암기하고 적용한다는 사실입니다(안녕 SB 개발자 :) 득보다 실이 더 많습니다.
MQL의 경우 OOP의 관점에서 볼 때 매우 약한 언어입니다 . 유형 제어가 완전히 부재하고(적어도 안전한 캐스트를 수행함) 리플렉션이 초기 단계에 있고 매우 제한적이며 인터페이스가 전혀 없습니다. . 질문이 생깁니다. MQL에서 어떤 종류의 OOP를 가르칠 수 있습니까? 개발자들이 표준 라이브러리 에서 이러한 꼽추를 조각하여 때로는 무섭게 만든다면 뭐라고 말할 수 있습니까?
예, 약하지만 중간 정도의 심각도 프로젝트는 여전히 수행할 수 있습니다. SB는 다양한 수준의 교육을 받은 다양한 사람들이 수행했습니다. 그리고 그것은 필수품을 가지고 있지 않습니다. 나는 여전히 당신의 CDictionary를 사용하고 있습니다.
그럼 이제 누워서 죽을까? )) 결국 dll로 갈 수 있습니다.
하지만 여전히 OOP를 배울 수 있다고 생각합니다. 독학 했어요 또는 혼자 배웠습니다. 그리고 다른 사람들도.
하지만 여전히 OOP를 배울 수 있다고 생각합니다. 독학 했어요 또는 혼자 배웠습니다. 그리고 다른 사람들도.
따라서 올바른 예에서 배워야 합니다. 그러나 그들은 SB에 존재하지 않습니다. 동일한 CObject를 사용합니다. 유형 제어를 제공하지 않고 인터페이스 수준에서 개체에 대한 작업을 제공하지 않지만 실제로 재정의되지 않는 Save() 및 Load()와 같은 의미 없는 메서드가 포함되어 있습니다. m_prev 및 m_next 포인터는 단일 CList 클래스 에서 사용되지만 모든 하위 클래스에 대한 안정기로 존재합니다. 가장 유용한 것은 Comparer() 메서드입니다. 실제로 가장 자주 재정의됩니다. 그러나 좋은 방법으로 Comparer()는 인터페이스이므로 CObject가 아닌 별도의 클래스로 정의하는 것이 더 정확합니다.
분명히 static 및 const(이것은 OOP가 아님)가 필요하지 않습니다.
OOP의 경우 (전혀 추상적이지 않은) 실제 적용이 넓은 다음 기능이 절차 적 스타일에서 어떻게 보일지 매우 흥미 롭습니다.
분명히 모든 OOP는 절차적 스타일로 다시 작성할 수 있습니다. 하지만 저는 연습에 관심이 있습니다. 따라서 OOP를 최소한으로 사용하는 위의 작은 코드를 사용했습니다.
그렇다면 이 예에서 절차적 스타일은 OOP에 비해 얼마나 더 예쁘고/더 편리하고/더 읽기 쉽고/더 정확할까요? 글쎄, 몇 페이지를 입증하지 않기 위해서가 아니라 단순히 짧은 소스 코드를 절차적 대 OOP를 비교하기 위함입니다. OOP의 반대자들에게 마스터 클래스를 보여달라고 요청합니다. 이것은 끔찍한 MT5가 아니라 좋은 오래된 MT4입니다.
같은 방식으로 프로그래밍하는 방법을 배울 수 있는 패턴은 무엇입니까? :) 아주 좋은 모습
아니면 생각을 바꿔야 할 수도 있습니다.
예를 들어, 구조체가 생성자와 함께 클래스와 거의 같은 방식으로 사용될 수 있다는 것을 몰랐습니다.
예를 들어, 구조체가 생성자와 함께 클래스와 거의 같은 방식으로 사용될 수 있다는 것을 몰랐습니다.
같은 방식으로 프로그래밍하는 방법을 배울 수 있는 패턴은 무엇입니까? :) 아주 좋은 모습
아니면 생각을 바꿔야 할 수도 있습니다.
예를 들어, 구조체가 생성자와 함께 클래스와 거의 같은 방식으로 사용될 수 있다는 것을 몰랐습니다.
그리고 당신은 fxsaber의 코드에서 어떤 독창적인 것을 볼 수 있는지 물을 수 있습니다. 당신을 매료시킨 것은 IsChange의 부작용입니까, 아니면 시스템 상태가 사용자 수준에서 복제되어야 한다는 아이디어입니까?
그리고 당신은 fxsaber의 코드에서 어떤 독창적인 것을 볼 수 있는지 물을 수 있습니다. 당신을 매료시킨 것은 IsChange의 부작용입니까, 아니면 시스템 상태가 사용자 수준에서 복제되어야 한다는 아이디어입니까?
아마도이 코드를 거의 이해하지 못하기 때문일 것입니다. :)
죄송합니다, 아마추어 프로그래머 .. 기본 수준에서 OOP에만 익숙합니다.
C++에서 클래스와 구조체는 동일하지만 일부 기본값만 다릅니다.
쿨, 몰랐어.. 그냥 플러스를 더 잘 공부해야 할 것 같아
따라서 올바른 예에서 배워야 합니다. 그러나 그들은 SB에 존재하지 않습니다. 동일한 CObject를 사용합니다. 유형 제어를 제공하지 않고 인터페이스 수준에서 개체에 대한 작업을 제공하지 않지만 실제로 재정의되지 않는 Save() 및 Load()와 같은 의미 없는 메서드가 포함되어 있습니다. m_prev 및 m_next 포인터는 단일 CList 클래스 에서 사용되지만 모든 하위 클래스에 대한 안정기로 존재합니다. 가장 유용한 것은 Comparer() 메서드입니다. 실제로 가장 자주 재정의됩니다. 그러나 좋은 방법으로 Comparer()는 인터페이스이므로 CObject가 아닌 별도의 클래스로 정의하는 것이 더 정확합니다.