조르주, 오늘 나는 한 소녀와 함께 산책을 하고 수줍은 남자에 대해 조금 기억하고 수다를 떨었습니다. 솔직히 농담이 아닙니다. 사람마다 성격이 다르고 성장 과정이 다릅니다.
에서 ... 그리고 Lyokha - 밥을 위해 ... 그리고 이것이 맞습니다. OOP보다 훨씬 더 흥미롭습니다.
그래서 내 문제는 수줍음이 아니다. 제가 자랑할 수 있는 것은 "잘 매달린 혀"뿐입니다. 내 문제는 빈곤과 질 중심주의입니다. 나는 사생활과 섹스를 너무 높게 평가합니다. 당신 자신이 위에 썼습니다. 그들은 "... 아름다운 여성이 앞설 때 남자가 어떻게 쟁기질을 할 수 있는지 확신했습니다." 여기, 나는 그들 중 하나입니다. 여기 여성만이 있습니다. 당신이 젊고 강하고 부자일 때 그들은 당신을 필요로 합니다. 그리고 여성이 던질 기회가 있다면 조만간 던질 것입니다. 젊고 강하고 부자일지라도. 그리고 나는 집이 없는 가난한 노인 장애인입니다. 그래서 내 가능성은 제로 ... 나는 내 아내가 떠난 것에 놀라지 않습니다. 당신만 이혼에 대해 신경쓰지 않는 것 같습니다. 하지만 아내가 떠날 수 없는 상황에서 그런 여건을 만들지 못해서 너무 속상하다.
Peter Konow 와 같은 기억이 있다면 아마도 OOP가 필요하지 않다는 데 동의할 것입니다. 이러한 모든 인터페이스, 클래스, 개체, 상속 시스템 및 가상 기능을 차단하는 요점이 무엇입니까?
Aleksey는 올바르게 말했습니다. 프로세서는 개체에 대해 아무것도 모릅니다... 그는 기능에 대해서도 전혀 모릅니다. 이는 OOP 없이는 물론 기능 없이도 단순히 반환 주소를 기억하고 IP 레지스터(또는 최신 프로세서에 있는 명령 포인터)를 통해 제어 전송을 수행함으로써 모든 작업을 해결할 수 있음을 증명합니다.
나는 Peter Konow 가 그의 코드를 보여줄 때까지 그의 입장을 이해하지 못했습니다. 이제 - 모든 것이 명확하고 나는 그의 말에 동의할 수도 있습니다. 이 모든 것을 기억에 남길 수 있다면 오래도록 신경쓰지 않아도 됩니다. 그렇다면 나는 그가 쓰는 방식으로 쓰는 것이 더 합리적이라고 생각합니다. 더욱이 - 이 경우 OOP는 실제로 "장바구니의 다섯 번째 바퀴"가 됩니다.
그러나 개인적으로 작업의 대부분의 복잡성이 내 기억에서 사라진다는 문제가 있습니다. G_CORE 다차원 배열의 각 인덱스가 무엇을 담당하는지 계속 잊고 있다고 가정해 보겠습니다. 위 단편의 각 조건에서 - 나는 매번 그것에 대해 진지하게 생각할 것입니다 - 그것이 무엇을 결정하는지. 긴 조건을 파싱하는 것은 나에게도 스트레스가 될 것입니다.
더군다나 가끔은 스스로 이해하기 힘든 코드를 직접 작성하기도 합니다. 다음은 같은 방식으로 익사할 MY " 잘못된 " 코드의 일부입니다(위에서 인용했습니다).
이것은 주어진 구성 요소가 손익분기점에 있는지 여부를 결정하는 무역 구성 요소 인터페이스 CTradePosComponentI의 기능입니다.
이 코드의 "잘못"은 여기에서 간결함과 가시성을 위해 가독성이 희생된다는 것입니다. 인터페이스에 기능이 포함되어 있기 때문에 가능한 한 전체 인터페이스를 한 화면에서 볼 수 있고 볼 수 있어야 했습니다. 제공하는 기회를 기억하지 않기 위해 이러한 모든 기회를 즉시 볼 수 있습니다. 내가 모든 것을 기억한다면 함수를 문자열로 "끌어올" 필요가 없을 것입니다. 글쎄요, 기능은 수십 줄에 걸쳐 늘어서 있습니다 - 좋아요 ... 그러나 모든 기능이 인터페이스에 나란히 들어가고 모든 사람이 볼 수 있다는 것이 중요했습니다. 따라서 인터페이스를 한 번만 보면 인터페이스가 제공하는 기능 집합을 즉시 이해할 수 있습니다. 이런 이유로 - 하나의 긴 줄에 기능을 쓸 필요가 있었습니다. 그러나 그것을 이해하는 것은 완전히 비현실적입니다.
처음에 코드를 작성할 때 - 처음에는 완전히 다른 방식으로 이 함수를 작성했습니다. 분명히, 그리고 코멘트와 함께. 그것을 알아낼 수 있도록.
예를 들어 OO는 메시지 디스패칭을 통해 구현 가능합니다(클래스/템플릿 MQL에 없는 일부 "좋은" 포함).
나는 당신의 코드를 보지 않았고 그것을 읽을 수 없을 것 같지만 GUI 라이브러리가 있기 때문에 자체 (최소한 하나의) 대기열이 있고 많은 것들이 뒤틀려 있다고 확신합니다. 이벤트/전송/상태 처리를 통해. 그리고 이 "비틀림"은 결국 상속/다형성입니다.
글쎄, 나는 "A"라고 말했기 때문에 "B"라고 말해야합니다.) 내 기술을 더 구체적으로 설명하겠습니다.
특정 유형의 문제를 해결하는 데 작동하는 기능을 큰 블록으로 결합하여 기능 간에 구축해야 하는 관계의 수를 줄입니다. 이것은 장단점이 있습니다.
먼저 장점에 대해:
OOP에서 많은 기능으로 쪼개진 메커니즘은 클래스와 구조 간의 통신을 위해 많은 객체를 생성해야 합니다. 동시에, 각 함수의 프로토타입은 함수가 주변 코드와 연관되는 수많은 형식 매개변수로 가득 차 있습니다. 이 메커니즘을 개발하는 과정에서 메커니즘의 각 부분 간의 연결이 증가하기 때문에 코드의 내부 구조가 정확히 더 복잡해집니다.
내 기술에서는 모든 곳에 내려 놓는 전역 변수를 사용하여 기능과 블록 간의 통신을 완전히 단순화합니다. 함수는 전역 수준에서 즉시 보기 때문에 매개변수를 전달할 필요가 없습니다.
전역 변수의 값은 커서를 "따라가는" "개체 초점" 블록에 의해 설정됩니다. 커서의 현재 좌표에 따라 블록은 마우스가 있는 개체를 결정하고 모든 요소, 개체 및 창의 모든 속성이 기록된 코어(G_CORE)에 액세스합니다. 코어에서 블록은 커서 아래에 있는 개체의 모든 주요 속성의 현재 값을 가져와 전역 변수에 배치합니다. 커서가 개체 위로 이동하면 이 블록에서 전역 변수가 재정의되고 항상 포커스가 있는 개체에 해당합니다.
다음으로 OnChartEvent() 함수는 커서 아래에 있는 요소의 상태를 변경해야 하는 차트 이벤트를 캡처합니다. 이러한 이벤트에서 상태 제어 블록(OnChartEvent() 자체에 통합됨)은 포커스가 있는 창, 요소 및 개체와 해당 속성을 즉시 확인합니다. 필요한 모든 것이 이미 전역 변수에 초점이 맞춰져 있기 때문에 이 블록에 아무 것도 전달할 필요가 없습니다. 그 작업은 G_CORE 코어의 개체 속성 값을 변경하고 요소를 다시 그리는 것입니다. 값을 변경하고 Draw 블록을 호출합니다.
창, 캔버스 및 요소의 세 가지 매개변수만 도면 블록에 전달하면 됩니다. 요소를 다시 그려 현재 상태에 적절한 모양을 제공합니다. 모든 그리기 블록 도우미 함수는 포커스에 전역 변수도 사용합니다. 예를 들어 위의 "Detail Color()" 함수는 "WINDOW", "OBJECT", "OBJECT_CATEGORY" 등을 사용합니다. 이 모든 것이 매우 편리합니다.
이제 단점:
의심할 여지 없이 큰 블록과 개체 포커스는 코드 부분 간의 통신을 더 쉽게 만들지만 블록이 크기 때문에 작업하기 어려워집니다. 여기서 러시아어와 구문의 전체 단순화는 OOP를 사용하지 않기 때문에 저에게 도움이 됩니다.
시간이 지남에 따라 블록은 더 이상 변경할 필요가 없고 성장을 멈출 조건에 도달합니다. 점차적으로, 그들의 구조는 완전히 기억되고 그들과의 작업은 최대로 단순화됩니다.
물론 블록 자체를 연마하는 것은 다소 길고 지루한 일이지만 이것은 모든 메커니즘의 디버깅입니다.
Peter Konow 와 같은 기억이 있다면 아마도 OOP가 필요하지 않다는 데 동의할 것입니다. 이러한 모든 인터페이스, 클래스, 개체, 상속 시스템 및 가상 기능을 차단하는 요점이 무엇입니까?
Aleksey는 올바르게 말했습니다. 프로세서는 개체에 대해 아무것도 모릅니다... 그는 기능에 대해서도 전혀 모릅니다. 이는 OOP 없이는 물론 기능 없이도 단순히 반환 주소를 기억하고 IP 레지스터(또는 최신 프로세서에 있는 명령 포인터)를 통해 제어 전송을 수행함으로써 모든 작업을 해결할 수 있음을 증명합니다.
나는 Peter Konow 가 그의 코드를 보여줄 때까지 그의 입장을 이해하지 못했습니다. 이제 - 모든 것이 명확하고 나는 그의 말에 동의할 수도 있습니다. 이 모든 것을 기억에 남길 수 있다면 오래도록 신경쓰지 않아도 됩니다. 그렇다면 나는 그가 쓰는 방식으로 쓰는 것이 더 합리적이라고 생각합니다. 더욱이 - 이 경우 OOP는 실제로 "장바구니의 다섯 번째 바퀴"가 됩니다.
하지만 개인적으로 작업의 복잡한 부분이 대부분 기억에서 사라져 버리는 문제가 있습니다. G_CORE 다차원 배열의 각 인덱스가 무엇을 담당하는지 계속 잊고 있다고 가정해 보겠습니다. 위 스니펫의 각 조건에서 - 나는 매번 그것에 대해 진지하게 생각할 것입니다 - 그것이 무엇을 정의하는지. 긴 조건을 파싱하는 것은 나에게도 스트레스가 될 것입니다.
더군다나 가끔은 스스로 이해하기 힘든 코드를 직접 작성하기도 합니다. 다음은 같은 방식으로 익사할 MY " 잘못된 " 코드의 일부입니다(위에서 인용했습니다).
이것은 주어진 구성 요소가 손익분기점에 있는지 여부를 결정하는 무역 구성 요소 인터페이스 CTradePosComponentI의 기능입니다.
이 코드의 "잘못"은 여기에서 간결함과 가시성을 위해 가독성이 희생된다는 것입니다. 인터페이스에 기능이 포함되어 있기 때문에 가능한 한 전체 인터페이스를 한 화면에서 볼 수 있고 볼 수 있어야 했습니다. 제공하는 기회를 기억하지 않기 위해 이러한 모든 기회를 즉시 볼 수 있습니다. 내가 모든 것을 기억한다면 함수를 문자열로 "끌어올" 필요가 없을 것입니다. 글쎄요, 기능은 수십 줄에 걸쳐 늘어서 있습니다 - 좋아요 ... 그러나 모든 기능이 인터페이스에 나란히 들어가고 모든 사람이 볼 수 있다는 것이 중요했습니다. 따라서 인터페이스를 한 번만 보면 인터페이스가 제공하는 기능 집합을 즉시 이해할 수 있습니다. 이런 이유로 - 하나의 긴 줄에 기능을 쓸 필요가 있었습니다. 그러나 그것을 이해하는 것은 완전히 비현실적입니다.
처음에 코드를 작성할 때 - 처음에는 완전히 다른 방식으로 이 함수를 작성했습니다. 분명히, 그리고 코멘트와 함께. 그것을 알아낼 수 있도록.
이와 같이:
그리고 이 모든 것을 확인하고 디버깅한 후에야 코드가 주석에서 지워지고 "한 줄로 늘어납니다".
그러나 이것은 예외입니다. 나는 "가시성"이 중요한 특별한 경우에 극히 드물게 이 작업을 수행합니다. 다른 모든 경우에 저는 코드를 "광범위하게" 그리고 들여쓰기로 작성하고 "무엇이 있습니까?"라는 질문에 약간의 문제가 발생할 수 있는 모든 위치에 주석으로 작성합니다.
그것은 단지 다릅니다 - 나는 그것이 어디에, 무엇을 제공하는지 매우 빨리 잊어 버립니다.
우리의 임무는 매우 다르기 때문에 귀하의 결정에 대해 말씀드리기가 어렵습니다. 제 기억만 그런지는 모르겠지만 뭔가 다른게 있을 수도 있겠네요. 자신의 코드의 의미는 의심할 여지 없이 코드의 암기를 향상시킵니다. 귀하의 코드가 덜 의미가 있다고 말하는 것이 아닙니다. 나는 당신의 문제를 해결하기 위해 어떻게 접근해야 할지 모르겠습니다. 아마도 당신의 접근 방식이 옳을 것입니다. 판단할 생각은 없습니다. 개인적으로 이런 스타일의 코드를 받아들이는 것이 매우 어렵다고 생각합니다.
우리의 임무는 매우 다르기 때문에 귀하의 결정에 대해 말씀드리기가 어렵습니다. 제 기억만 그런지는 모르겠지만 뭔가 다른게 있을 수도 있겠네요. 자신의 코드의 의미는 의심할 여지 없이 암기를 향상시킵니다. 귀하의 코드가 덜 의미가 있다고 말하는 것이 아닙니다. 나는 당신의 문제를 해결하기 위해 어떻게 접근해야 할지 모르겠습니다. 아마도 당신의 접근 방식이 옳을 것입니다. 판단할 생각은 없습니다. 개인적으로 이런 스타일의 코드를 받아들이는 것이 매우 어렵다고 생각합니다.
아마도 습관의 문제일 것입니다.))
완전히 의미 없는 대화: 코드를 "좋음" 또는 "나쁨"으로 분류하는 기준이 없습니다 . 이것이 OOP에 대해 명확하지 않은 이유입니다.
나에게 그러한 기준은 코드의 가시성이며, 이는 작성자 또는 제3자가 오랜 시간 후에 코드를 읽고 수정, 검색에 사용할 수 있다는 사실에서 나타납니다. 버그 .....
위에서 Fedoseev가 OOP 스위치를 교체했습니다. 나에게 성공하지 못할 수도 있는 이 특정 예는 OOP의 사악함의 증거입니다. 100개 위치의 스위치가 있는 설명 코드가 한 줄로 대체됩니다. 이 선을 이해하려면 어딘가로 올라가야 합니다. 저에게는 이것이 용납되지 않습니다.
George Merts 위의 두 번째 예
디버깅 후 설명 코드가 비설명 코드로 대체된 경우. 내 기준에 따르면 고품질 코드(읽기 쉬운)가 잘못된 코드로 대체되었습니다.
따라서 OOP의 모든 지지자에게 질문이 있습니다. OOP를 사용할 때 프로그램이 더 시각적 으로 표시되고 스위치에서 Fedoseev가 제공한 예가 실패하거나 그 반대의 경우도 마찬가지입니다. Fedoseev의 예는 OOP를 매우 정확하게 특성화하고 OOP는 거의 항상 다음으로 이어집니다. 가시성 상실?
1. 완전히 무의미한 대화: 코드를 "좋음" 또는 "나쁨"으로 분류하는 기준이 없습니다 . 이것이 OOP에 대해 명확하지 않은 이유입니다.
나에게 그러한 기준은 코드의 가시성이며, 이는 작성자 또는 제3자가 오랜 시간 후에 코드를 읽고 수정, 검색에 사용할 수 있다는 사실에서 나타납니다. 버그 .....
2. 위에서 Fedoseev가 OOP 스위치를 교체했습니다. 나에게 성공하지 못할 수도 있는 이 특정 예는 OOP의 사악함의 증거입니다. 100개 위치의 스위치가 있는 설명 코드가 한 줄로 대체됩니다. 이 선을 이해하려면 어딘가로 올라가야 합니다. 저에게는 이것이 용납되지 않습니다.
George Merts 위의 두 번째 예
디버깅 후 설명 코드가 비설명 코드로 대체된 경우. 내 기준에 따르면 고품질 코드(읽기 쉬운)가 잘못된 코드로 대체되었습니다.
3. 따라서 OOP의 모든 지지자에게 질문이 있습니다. OOP를 사용할 때 프로그램이 더 시각적 으로 표시되고 스위치에서 Fedoseev가 제공한 예제가 실패하거나 그 반대의 경우도 마찬가지입니다. Fedoseev의 예제는 거의 항상 OOP와 OOP를 매우 정확하게 특성화합니다 가시성을 잃게 합니까?
1. 기준이 있습니다. 주요 기준은 작업 속도입니다.
코드의 시각화는 잘못된 기준입니다. 코드는 보기 위한 것이 아니라 작동하도록 작성되었습니다.
2. 일부는 아직 기능을 사용하여 코드를 구성하는 데 익숙하지 않은 것으로 나타났습니다. 따라서 주제에 들어가지 않고 "한 시트의 코드 대 기능으로 구성된 코드"라는 주제로 들어가야 합니다.
또한, 예제는 구조화 및 가시성/비가시성에 관한 것이 아니라 밸러스트 코드 섹션을 제거하는 것에 관한 것이었습니다.
3. 당신은 이것을 할 수 있습니까 ... 엔지니어링 그래픽? 또는 기술 기하학. 모든 것이 명확합니다.
코드의 시각화는 잘못된 기준입니다. 코드는 보기 위한 것이 아니라 작동하도록 작성되었습니다.
글쎄, 나는 동의하지 않는다.
시각적 코드는 유지 관리 및 수정이 훨씬 쉽기 때문에 시각적 코드는 매우 중요합니다.
모든 것이 올바르게 말해지고 있습니다. 저는 부드러운 기능을 작성한 다음 실제로 "난독화"하여 사랑스럽고 이해할 수 없게 만들었습니다. 강제적인 결정이었다. 이 경우 전체 수업의 가시성이 나에게 더 중요했습니다. 하나의 아주 사소한 기능의 가시성 - 나는 희생했습니다. 물론 이 함수의 본문을 .mq5 파일로 옮기는 것도 가능하지만 인터페이스를 두 개의 파일로 분할해서는 안 되며 .mqh 헤더 파일에 완전히 설명해야 한다고 생각합니다.
속도도 염두에 둬야 할 부분이지만, '어떤 대가를 치르더라도 속도'를 목표로 해서는 안 된다고 생각한다. 합리적으로 충분해야 합니다.
시트로 뻗어 있습니다 :-) 나는 그들이 holivars를 놓친 것을 보았고 중재자가 불꽃 테마를 짜내었습니다 ... 그리고 갑자기 OOP 대 비 OOP
그런데 @Peter Konow 가 OOP를 사용하는 99%, 그 사람만 그것에 대해 알지 못합니다 :-) OOP는 반드시 "클래스 및 템플릿"이 아닙니다.
그런데 그 반대도 마찬가지입니다. 프로그램에 개체와 클래스가 있다고 해서 OOP가 표시되지는 않습니다.
이것은 매우 흥미로운 아이디어입니다. 그럴 수도 있지만 의심하지 않습니다. ))
그리고 어떻게 알 수 있습니까?
이것은 매우 흥미로운 아이디어입니다. 그럴 수도 있지만 의심하지 않습니다. ))
그리고 어떻게 알 수 있습니까?
예를 들어, OO는 메시지 디스패치(클래스/템플릿 MQL에 없는 일부 "좋은" 포함)를 통해 상당히 구현 가능합니다.
나는 당신의 코드를 보지 않았고 그것을 읽을 수 없을 것 같지만 GUI 라이브러리가 있기 때문에 자체 (최소한 하나의) 대기열이 있고 많은 것들이 뒤틀려 있다고 확신합니다. 이벤트/전송/상태 처리를 통해. 그리고 이 "비틀림"은 결국 상속/다형성입니다.
고슴도치 정보:
공터에 고슴도치가 있습니다, 포즈를 취하고, 팔뚝을 긴장시킵니다. - 나는 강하고, 용감하고, 기민하고, 강하고, 용감하고, 기민하다 ...
곰 한 마리가 지나가고 있었습니다. 발로 차면 고슴도치가 나무 뒤로 날아가 일어나서 몸을 닦습니다.
- 나는 강하고, 나는 용감하고, 나는 민첩하지만...
내 소꿉친구가 말했듯이 고슴도치는 자랑스러운 새, 발로 차지 않고 날지 않는다))
조르주, 오늘 나는 한 소녀와 함께 산책을 하고 수줍은 남자에 대해 조금 기억하고 수다를 떨었습니다. 솔직히 농담이 아닙니다. 사람마다 성격이 다르고 성장 과정이 다릅니다.
에서 ... 그리고 Lyokha - 밥을 위해 ... 그리고 이것이 맞습니다. OOP보다 훨씬 더 흥미롭습니다.
그래서 내 문제는 수줍음이 아니다. 제가 자랑할 수 있는 것은 "잘 매달린 혀"뿐입니다. 내 문제는 빈곤과 질 중심주의입니다. 나는 사생활과 섹스를 너무 높게 평가합니다. 당신 자신이 위에 썼습니다. 그들은 "... 아름다운 여성이 앞설 때 남자가 어떻게 쟁기질을 할 수 있는지 확신했습니다." 여기, 나는 그들 중 하나입니다. 여기 여성만이 있습니다. 당신이 젊고 강하고 부자일 때 그들은 당신을 필요로 합니다. 그리고 여성이 던질 기회가 있다면 조만간 던질 것입니다. 젊고 강하고 부자일지라도. 그리고 나는 집이 없는 가난한 노인 장애인입니다. 그래서 내 가능성은 제로 ... 나는 내 아내가 떠난 것에 놀라지 않습니다. 당신만 이혼에 대해 신경쓰지 않는 것 같습니다. 하지만 아내가 떠날 수 없는 상황에서 그런 여건을 만들지 못해서 너무 속상하다.
OOP의 경우...
Peter Konow 와 같은 기억이 있다면 아마도 OOP가 필요하지 않다는 데 동의할 것입니다. 이러한 모든 인터페이스, 클래스, 개체, 상속 시스템 및 가상 기능을 차단하는 요점이 무엇입니까?
Aleksey는 올바르게 말했습니다. 프로세서는 개체에 대해 아무것도 모릅니다... 그는 기능에 대해서도 전혀 모릅니다. 이는 OOP 없이는 물론 기능 없이도 단순히 반환 주소를 기억하고 IP 레지스터(또는 최신 프로세서에 있는 명령 포인터)를 통해 제어 전송을 수행함으로써 모든 작업을 해결할 수 있음을 증명합니다.
나는 Peter Konow 가 그의 코드를 보여줄 때까지 그의 입장을 이해하지 못했습니다. 이제 - 모든 것이 명확하고 나는 그의 말에 동의할 수도 있습니다. 이 모든 것을 기억에 남길 수 있다면 오래도록 신경쓰지 않아도 됩니다. 그렇다면 나는 그가 쓰는 방식으로 쓰는 것이 더 합리적이라고 생각합니다. 더욱이 - 이 경우 OOP는 실제로 "장바구니의 다섯 번째 바퀴"가 됩니다.
그러나 개인적으로 작업의 대부분의 복잡성이 내 기억에서 사라진다는 문제가 있습니다. G_CORE 다차원 배열의 각 인덱스가 무엇을 담당하는지 계속 잊고 있다고 가정해 보겠습니다. 위 단편의 각 조건에서 - 나는 매번 그것에 대해 진지하게 생각할 것입니다 - 그것이 무엇을 결정하는지. 긴 조건을 파싱하는 것은 나에게도 스트레스가 될 것입니다.
더군다나 가끔은 스스로 이해하기 힘든 코드를 직접 작성하기도 합니다. 다음은 같은 방식으로 익사할 MY " 잘못된 " 코드의 일부입니다(위에서 인용했습니다).
이것은 주어진 구성 요소가 손익분기점에 있는지 여부를 결정하는 무역 구성 요소 인터페이스 CTradePosComponentI의 기능입니다.
이 코드의 "잘못"은 여기에서 간결함과 가시성을 위해 가독성이 희생된다는 것입니다. 인터페이스에 기능이 포함되어 있기 때문에 가능한 한 전체 인터페이스를 한 화면에서 볼 수 있고 볼 수 있어야 했습니다. 제공하는 기회를 기억하지 않기 위해 이러한 모든 기회를 즉시 볼 수 있습니다. 내가 모든 것을 기억한다면 함수를 문자열로 "끌어올" 필요가 없을 것입니다. 글쎄요, 기능은 수십 줄에 걸쳐 늘어서 있습니다 - 좋아요 ... 그러나 모든 기능이 인터페이스에 나란히 들어가고 모든 사람이 볼 수 있다는 것이 중요했습니다. 따라서 인터페이스를 한 번만 보면 인터페이스가 제공하는 기능 집합을 즉시 이해할 수 있습니다. 이런 이유로 - 하나의 긴 줄에 기능을 쓸 필요가 있었습니다. 그러나 그것을 이해하는 것은 완전히 비현실적입니다.
처음에 코드를 작성할 때 - 처음에는 완전히 다른 방식으로 이 함수를 작성했습니다. 분명히, 그리고 코멘트와 함께. 그것을 알아낼 수 있도록.
이와 같이:
그리고 이 모든 것을 확인하고 디버깅한 후에야 코드가 주석에서 지워지고 "한 줄로 늘어납니다".
그러나 이것은 예외입니다. 나는 "가시성"이 중요한 특별한 경우에 극히 드물게 이 작업을 수행합니다. 다른 모든 경우에 저는 코드를 "광범위하게" 그리고 들여쓰기로 작성하고 "무엇이 있습니까?"라는 질문에 약간의 문제가 발생할 수 있는 모든 위치에 주석으로 작성합니다.
그것은 단지 다릅니다 - 나는 그것이 어디에, 무엇을 제공하는지 매우 빨리 잊어 버립니다.
예를 들어 OO는 메시지 디스패칭을 통해 구현 가능합니다(클래스/템플릿 MQL에 없는 일부 "좋은" 포함).
나는 당신의 코드를 보지 않았고 그것을 읽을 수 없을 것 같지만 GUI 라이브러리가 있기 때문에 자체 (최소한 하나의) 대기열이 있고 많은 것들이 뒤틀려 있다고 확신합니다. 이벤트/전송/상태 처리를 통해. 그리고 이 "비틀림"은 결국 상속/다형성입니다.
글쎄, 나는 "A"라고 말했기 때문에 "B"라고 말해야합니다.) 내 기술을 더 구체적으로 설명하겠습니다.
특정 유형의 문제를 해결하는 데 작동하는 기능을 큰 블록으로 결합하여 기능 간에 구축해야 하는 관계의 수를 줄입니다. 이것은 장단점이 있습니다.
먼저 장점에 대해:
OOP에서 많은 기능으로 쪼개진 메커니즘은 클래스와 구조 간의 통신을 위해 많은 객체를 생성해야 합니다. 동시에, 각 함수의 프로토타입은 함수가 주변 코드와 연관되는 수많은 형식 매개변수로 가득 차 있습니다. 이 메커니즘을 개발하는 과정에서 메커니즘의 각 부분 간의 연결이 증가하기 때문에 코드의 내부 구조가 정확히 더 복잡해집니다.
내 기술에서는 모든 곳에 내려 놓는 전역 변수를 사용하여 기능과 블록 간의 통신을 완전히 단순화합니다. 함수는 전역 수준에서 즉시 보기 때문에 매개변수를 전달할 필요가 없습니다.
전역 변수의 값은 커서를 "따라가는" "개체 초점" 블록에 의해 설정됩니다. 커서의 현재 좌표에 따라 블록은 마우스가 있는 개체를 결정하고 모든 요소, 개체 및 창의 모든 속성이 기록된 코어(G_CORE)에 액세스합니다. 코어에서 블록은 커서 아래에 있는 개체의 모든 주요 속성의 현재 값을 가져와 전역 변수에 배치합니다. 커서가 개체 위로 이동하면 이 블록에서 전역 변수가 재정의되고 항상 포커스가 있는 개체에 해당합니다.
다음으로 OnChartEvent() 함수는 커서 아래에 있는 요소의 상태를 변경해야 하는 차트 이벤트를 캡처합니다. 이러한 이벤트에서 상태 제어 블록(OnChartEvent() 자체에 통합됨)은 포커스가 있는 창, 요소 및 개체와 해당 속성을 즉시 확인합니다. 필요한 모든 것이 이미 전역 변수에 초점이 맞춰져 있기 때문에 이 블록에 아무 것도 전달할 필요가 없습니다. 그 작업은 G_CORE 코어의 개체 속성 값을 변경하고 요소를 다시 그리는 것입니다. 값을 변경하고 Draw 블록을 호출합니다.
창, 캔버스 및 요소의 세 가지 매개변수만 도면 블록에 전달하면 됩니다. 요소를 다시 그려 현재 상태에 적절한 모양을 제공합니다. 모든 그리기 블록 도우미 함수는 포커스에 전역 변수도 사용합니다. 예를 들어 위의 "Detail Color()" 함수는 "WINDOW", "OBJECT", "OBJECT_CATEGORY" 등을 사용합니다. 이 모든 것이 매우 편리합니다.
이제 단점:
의심할 여지 없이 큰 블록과 개체 포커스는 코드 부분 간의 통신을 더 쉽게 만들지만 블록이 크기 때문에 작업하기 어려워집니다. 여기서 러시아어와 구문의 전체 단순화는 OOP를 사용하지 않기 때문에 저에게 도움이 됩니다.
시간이 지남에 따라 블록은 더 이상 변경할 필요가 없고 성장을 멈출 조건에 도달합니다. 점차적으로, 그들의 구조는 완전히 기억되고 그들과의 작업은 최대로 단순화됩니다.
물론 블록 자체를 연마하는 것은 다소 길고 지루한 일이지만 이것은 모든 메커니즘의 디버깅입니다.
OOP의 경우...
Peter Konow 와 같은 기억이 있다면 아마도 OOP가 필요하지 않다는 데 동의할 것입니다. 이러한 모든 인터페이스, 클래스, 개체, 상속 시스템 및 가상 기능을 차단하는 요점이 무엇입니까?
Aleksey는 올바르게 말했습니다. 프로세서는 개체에 대해 아무것도 모릅니다... 그는 기능에 대해서도 전혀 모릅니다. 이는 OOP 없이는 물론 기능 없이도 단순히 반환 주소를 기억하고 IP 레지스터(또는 최신 프로세서에 있는 명령 포인터)를 통해 제어 전송을 수행함으로써 모든 작업을 해결할 수 있음을 증명합니다.
나는 Peter Konow 가 그의 코드를 보여줄 때까지 그의 입장을 이해하지 못했습니다. 이제 - 모든 것이 명확하고 나는 그의 말에 동의할 수도 있습니다. 이 모든 것을 기억에 남길 수 있다면 오래도록 신경쓰지 않아도 됩니다. 그렇다면 나는 그가 쓰는 방식으로 쓰는 것이 더 합리적이라고 생각합니다. 더욱이 - 이 경우 OOP는 실제로 "장바구니의 다섯 번째 바퀴"가 됩니다.
하지만 개인적으로 작업의 복잡한 부분이 대부분 기억에서 사라져 버리는 문제가 있습니다. G_CORE 다차원 배열의 각 인덱스가 무엇을 담당하는지 계속 잊고 있다고 가정해 보겠습니다. 위 스니펫의 각 조건에서 - 나는 매번 그것에 대해 진지하게 생각할 것입니다 - 그것이 무엇을 정의하는지. 긴 조건을 파싱하는 것은 나에게도 스트레스가 될 것입니다.
더군다나 가끔은 스스로 이해하기 힘든 코드를 직접 작성하기도 합니다. 다음은 같은 방식으로 익사할 MY " 잘못된 " 코드의 일부입니다(위에서 인용했습니다).
이것은 주어진 구성 요소가 손익분기점에 있는지 여부를 결정하는 무역 구성 요소 인터페이스 CTradePosComponentI의 기능입니다.
이 코드의 "잘못"은 여기에서 간결함과 가시성을 위해 가독성이 희생된다는 것입니다. 인터페이스에 기능이 포함되어 있기 때문에 가능한 한 전체 인터페이스를 한 화면에서 볼 수 있고 볼 수 있어야 했습니다. 제공하는 기회를 기억하지 않기 위해 이러한 모든 기회를 즉시 볼 수 있습니다. 내가 모든 것을 기억한다면 함수를 문자열로 "끌어올" 필요가 없을 것입니다. 글쎄요, 기능은 수십 줄에 걸쳐 늘어서 있습니다 - 좋아요 ... 그러나 모든 기능이 인터페이스에 나란히 들어가고 모든 사람이 볼 수 있다는 것이 중요했습니다. 따라서 인터페이스를 한 번만 보면 인터페이스가 제공하는 기능 집합을 즉시 이해할 수 있습니다. 이런 이유로 - 하나의 긴 줄에 기능을 쓸 필요가 있었습니다. 그러나 그것을 이해하는 것은 완전히 비현실적입니다.
처음에 코드를 작성할 때 - 처음에는 완전히 다른 방식으로 이 함수를 작성했습니다. 분명히, 그리고 코멘트와 함께. 그것을 알아낼 수 있도록.
이와 같이:
그리고 이 모든 것을 확인하고 디버깅한 후에야 코드가 주석에서 지워지고 "한 줄로 늘어납니다".
그러나 이것은 예외입니다. 나는 "가시성"이 중요한 특별한 경우에 극히 드물게 이 작업을 수행합니다. 다른 모든 경우에 저는 코드를 "광범위하게" 그리고 들여쓰기로 작성하고 "무엇이 있습니까?"라는 질문에 약간의 문제가 발생할 수 있는 모든 위치에 주석으로 작성합니다.
그것은 단지 다릅니다 - 나는 그것이 어디에, 무엇을 제공하는지 매우 빨리 잊어 버립니다.
우리의 임무는 매우 다르기 때문에 귀하의 결정에 대해 말씀드리기가 어렵습니다. 제 기억만 그런지는 모르겠지만 뭔가 다른게 있을 수도 있겠네요. 자신의 코드의 의미는 의심할 여지 없이 코드의 암기를 향상시킵니다. 귀하의 코드가 덜 의미가 있다고 말하는 것이 아닙니다. 나는 당신의 문제를 해결하기 위해 어떻게 접근해야 할지 모르겠습니다. 아마도 당신의 접근 방식이 옳을 것입니다. 판단할 생각은 없습니다. 개인적으로 이런 스타일의 코드를 받아들이는 것이 매우 어렵다고 생각합니다.
아마도 습관의 문제일 것입니다.))
우리의 임무는 매우 다르기 때문에 귀하의 결정에 대해 말씀드리기가 어렵습니다. 제 기억만 그런지는 모르겠지만 뭔가 다른게 있을 수도 있겠네요. 자신의 코드의 의미는 의심할 여지 없이 암기를 향상시킵니다. 귀하의 코드가 덜 의미가 있다고 말하는 것이 아닙니다. 나는 당신의 문제를 해결하기 위해 어떻게 접근해야 할지 모르겠습니다. 아마도 당신의 접근 방식이 옳을 것입니다. 판단할 생각은 없습니다. 개인적으로 이런 스타일의 코드를 받아들이는 것이 매우 어렵다고 생각합니다.
아마도 습관의 문제일 것입니다.))
완전히 의미 없는 대화: 코드를 "좋음" 또는 "나쁨"으로 분류하는 기준이 없습니다 . 이것이 OOP에 대해 명확하지 않은 이유입니다.
나에게 그러한 기준은 코드의 가시성이며, 이는 작성자 또는 제3자가 오랜 시간 후에 코드를 읽고 수정, 검색에 사용할 수 있다는 사실에서 나타납니다. 버그 .....
위에서 Fedoseev가 OOP 스위치를 교체했습니다. 나에게 성공하지 못할 수도 있는 이 특정 예는 OOP의 사악함의 증거입니다. 100개 위치의 스위치가 있는 설명 코드가 한 줄로 대체됩니다. 이 선을 이해하려면 어딘가로 올라가야 합니다. 저에게는 이것이 용납되지 않습니다.
George Merts 위의 두 번째 예
디버깅 후 설명 코드가 비설명 코드로 대체된 경우. 내 기준에 따르면 고품질 코드(읽기 쉬운)가 잘못된 코드로 대체되었습니다.
따라서 OOP의 모든 지지자에게 질문이 있습니다. OOP를 사용할 때 프로그램이 더 시각적 으로 표시되고 스위치에서 Fedoseev가 제공한 예가 실패하거나 그 반대의 경우도 마찬가지입니다. Fedoseev의 예는 OOP를 매우 정확하게 특성화하고 OOP는 거의 항상 다음으로 이어집니다. 가시성 상실?
1. 완전히 무의미한 대화: 코드를 "좋음" 또는 "나쁨"으로 분류하는 기준이 없습니다 . 이것이 OOP에 대해 명확하지 않은 이유입니다.
나에게 그러한 기준은 코드의 가시성이며, 이는 작성자 또는 제3자가 오랜 시간 후에 코드를 읽고 수정, 검색에 사용할 수 있다는 사실에서 나타납니다. 버그 .....
2. 위에서 Fedoseev가 OOP 스위치를 교체했습니다. 나에게 성공하지 못할 수도 있는 이 특정 예는 OOP의 사악함의 증거입니다. 100개 위치의 스위치가 있는 설명 코드가 한 줄로 대체됩니다. 이 선을 이해하려면 어딘가로 올라가야 합니다. 저에게는 이것이 용납되지 않습니다.
George Merts 위의 두 번째 예
디버깅 후 설명 코드가 비설명 코드로 대체된 경우. 내 기준에 따르면 고품질 코드(읽기 쉬운)가 잘못된 코드로 대체되었습니다.
3. 따라서 OOP의 모든 지지자에게 질문이 있습니다. OOP를 사용할 때 프로그램이 더 시각적 으로 표시되고 스위치에서 Fedoseev가 제공한 예제가 실패하거나 그 반대의 경우도 마찬가지입니다. Fedoseev의 예제는 거의 항상 OOP와 OOP를 매우 정확하게 특성화합니다 가시성을 잃게 합니까?
1. 기준이 있습니다. 주요 기준은 작업 속도입니다.
코드의 시각화는 잘못된 기준입니다. 코드는 보기 위한 것이 아니라 작동하도록 작성되었습니다.
2. 일부는 아직 기능을 사용하여 코드를 구성하는 데 익숙하지 않은 것으로 나타났습니다. 따라서 주제에 들어가지 않고 "한 시트의 코드 대 기능으로 구성된 코드"라는 주제로 들어가야 합니다.
또한, 예제는 구조화 및 가시성/비가시성에 관한 것이 아니라 밸러스트 코드 섹션을 제거하는 것에 관한 것이었습니다.
3. 당신은 이것을 할 수 있습니까 ... 엔지니어링 그래픽? 또는 기술 기하학. 모든 것이 명확합니다.
코드의 시각화는 잘못된 기준입니다. 코드는 보기 위한 것이 아니라 작동하도록 작성되었습니다.
글쎄, 나는 동의하지 않는다.
시각적 코드는 유지 관리 및 수정이 훨씬 쉽기 때문에 시각적 코드는 매우 중요합니다.
모든 것이 올바르게 말해지고 있습니다. 저는 부드러운 기능을 작성한 다음 실제로 "난독화"하여 사랑스럽고 이해할 수 없게 만들었습니다. 강제적인 결정이었다. 이 경우 전체 수업의 가시성이 나에게 더 중요했습니다. 하나의 아주 사소한 기능의 가시성 - 나는 희생했습니다. 물론 이 함수의 본문을 .mq5 파일로 옮기는 것도 가능하지만 인터페이스를 두 개의 파일로 분할해서는 안 되며 .mqh 헤더 파일에 완전히 설명해야 한다고 생각합니다.
속도도 염두에 둬야 할 부분이지만, '어떤 대가를 치르더라도 속도'를 목표로 해서는 안 된다고 생각한다. 합리적으로 충분해야 합니다.