회사에 다니지 않기 때문일 것입니다. 그리고 OOP보다 절차적 프로그래밍을 사용하는 것이 더 쉽다는 것을 알게 되었습니다.
물론 이에 대해 많은 논란이 있어왔다.
음, 그냥, 지난 주에 TS 리그의 거래 품질을 평가하기 위한 알고리즘을 약간 수정했다는 사실에 관여했습니다. 그리고 모든 것이 가상 인터페이스를 기반으로 구축되어 매우 기뻤습니다.
결론은 최대 드로우다운 이전에는 잔액으로만 추정되었다는 것입니다. 그리고 Equity로 계산하고 싶었습니다. 하지만 이를 위해서는 각 거래 내역을 분석할 때 시계열을 요청해야 하며 당시 가격을 기준으로 거래의 최대 손실액이 얼마인지 확인해야 합니다.
이제 내 코드는 이식 가능합니다. 즉, 동일한 인터페이스를 기반으로 합니다. MT4와 MT5 모두에서 작동합니다. 따라서 각 플랫폼에 대해 해당 클래스가 호출되며 기능이 크게 다릅니다. 그래서 코드를 완성하는 동안 필요한 데이터에 직접 액세스할 수 없는 상황이 수십 번 정도 있었을 것입니다. 인터페이스가 이를 허용하지 않았습니다. 그리고 모든 것이 정확하고 인터페이스가 저를 제한한다고 확신할 때마다 이 데이터에 직접 "들어가면" 프로그램의 다른 부분에서 오류가 발생할 수 있습니다. 필요한 데이터의 경우 추가 요청을 통해 다르게 액세스해야 했기 때문에 다른 부분이 영향을 받지 않았음을 확인할 수 있었습니다.
요약: "각 장소에서 사용자는 지금 필요한 구조에만 액세스할 수 있어야 하며 더 이상은 - 아니요"라는 원칙이 절대적으로 사실이라는 것을 다시 한 번 확신했습니다. 사용자가 항상 무엇이든 액세스할 수 있도록 허용하는 것은 불가능합니다. 수정하는 동안 오류가 발생합니다.
그러나 반면에 절차적 스타일에 익숙한 사람들은 주어진 장소에서 변경할 수 있는 데이터와 변경할 수 없는 데이터를 기억하면서 이러한 경우에 스스로를 제한할 뿐입니다.
음, 그냥, 지난 주에 TS 리그의 거래 품질을 평가하기 위한 알고리즘을 약간 수정했다는 사실에 관여했습니다. 그리고 모든 것이 가상 인터페이스를 기반으로 구축되어 매우 기뻤습니다.
결론은 최대 드로우다운 이전에는 잔액으로만 추정되었다는 것입니다. 그리고 저는 Equity로 계산하고 싶었습니다. 하지만 이를 위해서는 각 거래 내역을 분석할 때 시계열을 요청해야 하며 당시 가격을 기준으로 거래의 최대 손실액이 얼마인지 확인해야 합니다.
이제 내 코드는 이식 가능합니다. 즉, 동일한 인터페이스를 기반으로 합니다. MT4와 MT5 모두에서 작동합니다. 따라서 각 플랫폼에 대해 해당 클래스가 호출되며 기능이 크게 다릅니다. 그래서 코드를 완성하는 동안 필요한 데이터에 직접 액세스할 수 없는 상황이 수십 번 정도 있었을 것입니다. 인터페이스가 이를 허용하지 않았습니다. 그리고 모든 것이 정확하고 인터페이스가 저를 제한한다고 확신할 때마다 이 데이터에 직접 "들어가면" 프로그램의 다른 부분에서 오류가 발생할 수 있습니다. 필요한 데이터의 경우 추가 요청을 통해 다르게 액세스해야 했기 때문에 다른 부분이 영향을 받지 않았음을 확인할 수 있었습니다.
요약: "각 장소에서 사용자는 지금 필요한 구조에만 액세스할 수 있어야 하며 더 이상은 - 아니요"라는 원칙이 절대적으로 사실이라는 것을 다시 한 번 확신했습니다. 사용자가 항상 무엇이든 액세스할 수 있도록 허용하는 것은 불가능합니다. 수정하는 동안 오류가 발생합니다.
그러나 반면에 절차적 스타일에 익숙한 사람들은 주어진 장소에서 변경할 수 있는 데이터와 변경할 수 없는 데이터를 기억하면서 이러한 경우에 스스로를 제한할 뿐입니다.
예, MT5 및 MT4에서 동일하게 작동하는 자체 라이브러리도 있습니다. 저는 1개의 코드만 작성하고 나머지는 라이브러리에서 수행합니다.
그리고 코드가 너무 커서 모든 것을 OOP로 만들지 않습니다.
그런데 자기자본에 의한 드로다운에 대해서는 지표에 그대로 사용했습니다.
그러나 많은 뉘앙스가 있습니다. 특히 특정 바 의 틱 히스토리 를 가져오는 것은 불가능합니다. 따라서 데이터는 근사치와 거리가 멉니다.
그렇게 해서 14살에 파스칼에 합류했고 제 자신을 바꿀 수는 없습니다. 그리고 나는 오래 전에 수업을 "배웠지만"자신을 확신 할 수 없습니다 ...
회사에 다니지 않기 때문일 것입니다. 그리고 OOP보다 절차적 프로그래밍을 사용하는 것이 더 쉽다는 것을 알게 되었습니다.
OOP 원칙은 절차적 프로그래밍과 크게 다르지 않습니다. 특히 MQL 프로그램은 고도로 전문화된 작업을 해결하고 종종 클래스의 내부 구조 를 개발하는 것이 의미가 없기 때문입니다. 코드베이스에서 클래스를 사용하는 예제의 90% 이상이 "클래스로 묶인" 절차적 프로그래밍에 불과합니다. 클래스가 해결하는 작업은 1회 수행되며 상속 및 다형성은 사용되지 않습니다(필요하지 않기 때문에).
그리고 OOP 없이는 방법이 없는 심각한 작업 - 이것은 그래픽입니다. 이 작업은 이미 완료되었으며 자유롭게 사용할 수 있으며 사용하거나 수정할 수만 있으면 됩니다(MQL의 그래픽)(상속 적용도 가능) .
추신: OOP 스타일의 MT 표준 제공은 매우 만족스럽고 모든 것이 준비되었으며 최소한의 수정이 필요합니다. 작업은 사용 방법과 클래스 또는 "서브루틴", IMHO에서 호출할 위치를 배우는 것뿐입니다. , 취향의 문제입니다.
ZYZY: ALGLIB 사용 측면에서 편의성에 대해 말하지 않을 것입니다. 일반 클래스에서 "래핑"해야 합니다!
OOP 원칙은 절차적 프로그래밍과 크게 다르지 않습니다. 특히 MQL 프로그램은 고도로 전문화된 작업을 해결하고 종종 클래스의 내부 구조 를 개발하는 것이 의미가 없기 때문입니다. 코드베이스에서 클래스를 사용하는 예제의 90% 이상이 "클래스에 래핑된" 절차적 프로그래밍에 불과합니다. 클래스가 해결하는 작업은 1회 수행되며 상속 및 다형성은 사용되지 않습니다(필요하지 않기 때문에).
그리고 OOP 없이는 방법이 없는 심각한 작업 - 이것은 그래픽입니다. 이 작업은 이미 완료되었으며 자유롭게 사용할 수 있으며 사용하거나 수정할 수만 있으면 됩니다(MQL의 그래픽)(상속 적용도 가능) .
추신: OOP 스타일의 MT 표준 제공은 매우 만족스럽고 모든 것이 준비되었으며 최소한의 수정이 필요합니다. 작업은 사용 방법과 클래스 또는 "서브루틴", IMHO에서 호출할 위치를 배우는 것뿐입니다. , 취향의 문제입니다.
ZYZY: ALGLIB 사용 측면에서 편의성에 대해 말하지 않을 것입니다. 일반 클래스에서 "래핑"해야 합니다!
무엇을 찾고 있습니다.
다른 사용자의 편의를 위해?
아마도 그렇습니다.
사용자가 "등반"하고 해를 끼치 지 않도록하십시오.
내 그래픽에 5가지 그리기 기능(텍스트, 버튼, 확인란, 필드, 배경)을 사용합니다! 모두 :-)
음, 그냥, 지난 주에 TS 리그의 거래 품질을 평가하기 위한 알고리즘을 약간 수정했다는 사실에 관여했습니다. 그리고 모든 것이 가상 인터페이스를 기반으로 구축되어 매우 기뻤습니다.
결론은 최대 드로우다운 이전에는 잔액으로만 추정되었다는 것입니다. 그리고 Equity로 계산하고 싶었습니다. 하지만 이를 위해서는 각 거래의 내역을 분석할 때 시계열을 요청해야 하며 당시 가격을 기준으로 거래의 최대 손실액이 얼마인지 확인해야 합니다.
이제 내 코드는 이식 가능합니다. 즉, 동일한 인터페이스를 기반으로 합니다. MT4와 MT5 모두에서 작동합니다. 따라서 각 플랫폼에 대해 해당 클래스가 호출되며 기능이 크게 다릅니다. 그래서 코드를 완성하는 동안 필요한 데이터에 직접 액세스할 수 없는 상황이 수십 번 정도 있었을 것입니다. 인터페이스가 이를 허용하지 않았습니다. 그리고 모든 것이 정확하고 인터페이스가 나를 제한한다고 확신할 때마다 이 데이터에 직접 "들어가면" 프로그램의 다른 부분에서 오류가 발생할 수 있습니다. 필요한 데이터의 경우 추가 요청을 통해 다르게 액세스해야 했기 때문에 다른 부분이 영향을 받지 않았음을 확인할 수 있었습니다.
요약: "각 장소에서 사용자는 지금 필요한 구조에만 액세스할 수 있어야 하며 더 이상은 - 아니요"라는 원칙이 절대적으로 사실이라는 것을 다시 한 번 확신했습니다. 사용자가 항상 무엇이든 액세스할 수 있도록 허용하는 것은 불가능합니다. 수정하는 동안 오류가 발생합니다.
그러나 반면에 절차적 스타일에 익숙한 사람들은 주어진 장소에서 변경할 수 있는 데이터와 변경할 수 없는 데이터를 기억하면서 이러한 경우에 스스로를 제한할 뿐입니다.
당신의 주장은 그가 의존하고 있는 지팡이의 필요성을 설명하고 증명하는 아주 늙은이의 주장과 같습니다. 그것 없이는 확실히 떨어질 것입니다. 그리고 있습니다. 하지만 모든 사람을 위한 것은 아닙니다.
당신의 주장은 그가 의존하고 있는 지팡이의 필요성을 설명하고 증명하는 아주 늙은이의 주장과 같습니다. 그것 없이는 나는 확실히 떨어질 것입니다. 그리고 있습니다. 그러나 모든 사람을 위한 것은 아닙니다.
내가 기억하는 것처럼 당신은 방대한 데이터 배열에 있는 모든 것을 완벽하게 기억합니다. 나는 어렸을 때에도 그런 일들을 기억하지 못했다. 이제 내가 이미 늙은 방귀가 되었을 때 이 블록이나 저 블록을 작성할 때 염두에 둔 모든 것을 기억조차 할 수 없습니다. 이 "지팡이"는 정말 많은 도움이 됩니다. 그러나 누군가가 당신이 필요로 하는 모든 것을 기억 속에 간직할 수 있다면 당신은 그것 없이도 할 수 있다는 데 동의합니다.
그럼에도 불구하고 나는 이미 존경받는 fxsaber의 코드를 여러 번 인용했는데, 그 자신은 그것이 어떻게 작동하는지 정확히 말할 수 없었습니다. 기억하기가 정말 어려운 매우 까다롭고 불분명한 검사가 있다는 것입니다. 그리고 그 사람은 기억하지 못합니다. 우리는 "이 코드는 여러 번 테스트되었으므로 신뢰할 수 있습니다."라는 데 동의했습니다. 그러나 일부 작업 프로토콜이 변경되면 어떻게 됩니까? 코드는 즉시 무효가 되며 동시에 - 변경된 사항을 수정하는 대신 - 가장 많이 변경된 위치를 찾을 때까지 재검토해야 합니다.
이것이 바로 이 "스틱"의 용도입니다. 소프트웨어 제품은 이제 너무 복잡하여 모든 미묘함을 염두에 두는 것이 비현실적입니다. 이것은 다양한 기술이 사용되는 것입니다(OOP는 그 중 하나일 뿐입니다).
회사에 다니지 않기 때문일 것입니다. 그리고 OOP보다 절차적 프로그래밍을 사용하는 것이 더 쉽다는 것을 알게 되었습니다.
물론 이에 대해 많은 논란이 있어왔다.
음, 그냥, 지난 주에 TS 리그의 거래 품질을 평가하기 위한 알고리즘을 약간 수정했다는 사실에 관여했습니다. 그리고 모든 것이 가상 인터페이스를 기반으로 구축되어 매우 기뻤습니다.
결론은 최대 드로우다운 이전에는 잔액으로만 추정되었다는 것입니다. 그리고 Equity로 계산하고 싶었습니다. 하지만 이를 위해서는 각 거래 내역을 분석할 때 시계열을 요청해야 하며 당시 가격을 기준으로 거래의 최대 손실액이 얼마인지 확인해야 합니다.
이제 내 코드는 이식 가능합니다. 즉, 동일한 인터페이스를 기반으로 합니다. MT4와 MT5 모두에서 작동합니다. 따라서 각 플랫폼에 대해 해당 클래스가 호출되며 기능이 크게 다릅니다. 그래서 코드를 완성하는 동안 필요한 데이터에 직접 액세스할 수 없는 상황이 수십 번 정도 있었을 것입니다. 인터페이스가 이를 허용하지 않았습니다. 그리고 모든 것이 정확하고 인터페이스가 저를 제한한다고 확신할 때마다 이 데이터에 직접 "들어가면" 프로그램의 다른 부분에서 오류가 발생할 수 있습니다. 필요한 데이터의 경우 추가 요청을 통해 다르게 액세스해야 했기 때문에 다른 부분이 영향을 받지 않았음을 확인할 수 있었습니다.
요약: "각 장소에서 사용자는 지금 필요한 구조에만 액세스할 수 있어야 하며 더 이상은 - 아니요"라는 원칙이 절대적으로 사실이라는 것을 다시 한 번 확신했습니다. 사용자가 항상 무엇이든 액세스할 수 있도록 허용하는 것은 불가능합니다. 수정하는 동안 오류가 발생합니다.
그러나 반면에 절차적 스타일에 익숙한 사람들은 주어진 장소에서 변경할 수 있는 데이터와 변경할 수 없는 데이터를 기억하면서 이러한 경우에 스스로를 제한할 뿐입니다.
음, 그냥, 지난 주에 TS 리그의 거래 품질을 평가하기 위한 알고리즘을 약간 수정했다는 사실에 관여했습니다. 그리고 모든 것이 가상 인터페이스를 기반으로 구축되어 매우 기뻤습니다.
결론은 최대 드로우다운 이전에는 잔액으로만 추정되었다는 것입니다. 그리고 저는 Equity로 계산하고 싶었습니다. 하지만 이를 위해서는 각 거래 내역을 분석할 때 시계열을 요청해야 하며 당시 가격을 기준으로 거래의 최대 손실액이 얼마인지 확인해야 합니다.
이제 내 코드는 이식 가능합니다. 즉, 동일한 인터페이스를 기반으로 합니다. MT4와 MT5 모두에서 작동합니다. 따라서 각 플랫폼에 대해 해당 클래스가 호출되며 기능이 크게 다릅니다. 그래서 코드를 완성하는 동안 필요한 데이터에 직접 액세스할 수 없는 상황이 수십 번 정도 있었을 것입니다. 인터페이스가 이를 허용하지 않았습니다. 그리고 모든 것이 정확하고 인터페이스가 저를 제한한다고 확신할 때마다 이 데이터에 직접 "들어가면" 프로그램의 다른 부분에서 오류가 발생할 수 있습니다. 필요한 데이터의 경우 추가 요청을 통해 다르게 액세스해야 했기 때문에 다른 부분이 영향을 받지 않았음을 확인할 수 있었습니다.
요약: "각 장소에서 사용자는 지금 필요한 구조에만 액세스할 수 있어야 하며 더 이상은 - 아니요"라는 원칙이 절대적으로 사실이라는 것을 다시 한 번 확신했습니다. 사용자가 항상 무엇이든 액세스할 수 있도록 허용하는 것은 불가능합니다. 수정하는 동안 오류가 발생합니다.
그러나 반면에 절차적 스타일에 익숙한 사람들은 주어진 장소에서 변경할 수 있는 데이터와 변경할 수 없는 데이터를 기억하면서 이러한 경우에 스스로를 제한할 뿐입니다.
글쎄요, 그것이 바로 경쟁입니다. 할 일이 없습니다. 포기하지 마세요. 계속 전진하고 승리하십시오. 그렇지 않으면 뒤에 있어.
OOP에 관해서는 잊어 버리십시오. 이 질문이 귀찮다면 프로그래밍에서 없이는 할 수 없는 것만 사용해야 한다고 말할 것입니다. 절차적인 스타일로 살 수 있다면 그렇게 하십시오.
나의 원칙: " 문제 해결에 있어 아무것도 없이 할 수 있다면, 반드시 그것 없이도 해야 합니다."
개에게 다섯 번째 다리가 필요합니까? :)
정확히.
이런 경쟁이 필요합니다.
당신은 놀랄 것입니다. 그러나 나는 여전히 절차적 프로그래밍으로 고통 받고 있습니다.
그렇게 해서 14살에 파스칼에 합류했고 제 자신을 바꿀 수는 없습니다. 그리고 나는 오래 전에 수업을 "배웠지만"자신을 확신 할 수 없습니다 ...
회사에 다니지 않기 때문일 것입니다. 그리고 OOP보다 절차적 프로그래밍을 사용하는 것이 더 쉽다는 것을 알게 되었습니다.
OOP 원칙은 절차적 프로그래밍과 크게 다르지 않습니다. 특히 MQL 프로그램은 고도로 전문화된 작업을 해결하고 종종 클래스의 내부 구조 를 개발하는 것이 의미가 없기 때문입니다. 코드베이스에서 클래스를 사용하는 예제의 90% 이상이 "클래스로 묶인" 절차적 프로그래밍에 불과합니다. 클래스가 해결하는 작업은 1회 수행되며 상속 및 다형성은 사용되지 않습니다(필요하지 않기 때문에).
그리고 OOP 없이는 방법이 없는 심각한 작업 - 이것은 그래픽입니다. 이 작업은 이미 완료되었으며 자유롭게 사용할 수 있으며 사용하거나 수정할 수만 있으면 됩니다(MQL의 그래픽)(상속 적용도 가능) .
추신: OOP 스타일의 MT 표준 제공은 매우 만족스럽고 모든 것이 준비되었으며 최소한의 수정이 필요합니다. 작업은 사용 방법과 클래스 또는 "서브루틴", IMHO에서 호출할 위치를 배우는 것뿐입니다. , 취향의 문제입니다.
ZYZY: ALGLIB 사용 측면에서 편의성에 대해 말하지 않을 것입니다. 일반 클래스에서 "래핑"해야 합니다!
Igor Makanu :
...
그리고 OOP가 없으면 방법이 없는 진지한 작업은 그래픽...
매우 논쟁의 여지가 있습니다.))
매우 논쟁의 여지가 있습니다.))
OOP 원칙은 절차적 프로그래밍과 크게 다르지 않습니다. 특히 MQL 프로그램은 고도로 전문화된 작업을 해결하고 종종 클래스의 내부 구조 를 개발하는 것이 의미가 없기 때문입니다. 코드베이스에서 클래스를 사용하는 예제의 90% 이상이 "클래스에 래핑된" 절차적 프로그래밍에 불과합니다. 클래스가 해결하는 작업은 1회 수행되며 상속 및 다형성은 사용되지 않습니다(필요하지 않기 때문에).
그리고 OOP 없이는 방법이 없는 심각한 작업 - 이것은 그래픽입니다. 이 작업은 이미 완료되었으며 자유롭게 사용할 수 있으며 사용하거나 수정할 수만 있으면 됩니다(MQL의 그래픽)(상속 적용도 가능) .
추신: OOP 스타일의 MT 표준 제공은 매우 만족스럽고 모든 것이 준비되었으며 최소한의 수정이 필요합니다. 작업은 사용 방법과 클래스 또는 "서브루틴", IMHO에서 호출할 위치를 배우는 것뿐입니다. , 취향의 문제입니다.
ZYZY: ALGLIB 사용 측면에서 편의성에 대해 말하지 않을 것입니다. 일반 클래스에서 "래핑"해야 합니다!
무엇을 찾고 있습니다.
다른 사용자의 편의를 위해?
아마도 그렇습니다.
사용자가 "등반"하고 해를 끼치 지 않도록하십시오.
내 그래픽에 5가지 그리기 기능(텍스트, 버튼, 확인란, 필드, 배경)을 사용합니다! 모두 :-)
저에게는 모든 것이 명확합니다. 다른 사람들은 볼 필요가 없습니다.
정확히.
이런 경쟁이 필요합니다.
이러한 경쟁이 우리 시장에서 성장하기를 꿈꿉니다. 시장만 정리하면 됩니다.
수영에 참가하려면 먼저 수영장을 청소한 다음 물로 채워야 합니다. 요컨대, 적절한 조건이 필요합니다.
수영장에서 더러워질 것이고 아무도 경쟁하기를 원하지 않을 것입니다. :)음, 그냥, 지난 주에 TS 리그의 거래 품질을 평가하기 위한 알고리즘을 약간 수정했다는 사실에 관여했습니다. 그리고 모든 것이 가상 인터페이스를 기반으로 구축되어 매우 기뻤습니다.
결론은 최대 드로우다운 이전에는 잔액으로만 추정되었다는 것입니다. 그리고 Equity로 계산하고 싶었습니다. 하지만 이를 위해서는 각 거래의 내역을 분석할 때 시계열을 요청해야 하며 당시 가격을 기준으로 거래의 최대 손실액이 얼마인지 확인해야 합니다.
이제 내 코드는 이식 가능합니다. 즉, 동일한 인터페이스를 기반으로 합니다. MT4와 MT5 모두에서 작동합니다. 따라서 각 플랫폼에 대해 해당 클래스가 호출되며 기능이 크게 다릅니다. 그래서 코드를 완성하는 동안 필요한 데이터에 직접 액세스할 수 없는 상황이 수십 번 정도 있었을 것입니다. 인터페이스가 이를 허용하지 않았습니다. 그리고 모든 것이 정확하고 인터페이스가 나를 제한한다고 확신할 때마다 이 데이터에 직접 "들어가면" 프로그램의 다른 부분에서 오류가 발생할 수 있습니다. 필요한 데이터의 경우 추가 요청을 통해 다르게 액세스해야 했기 때문에 다른 부분이 영향을 받지 않았음을 확인할 수 있었습니다.
요약: "각 장소에서 사용자는 지금 필요한 구조에만 액세스할 수 있어야 하며 더 이상은 - 아니요"라는 원칙이 절대적으로 사실이라는 것을 다시 한 번 확신했습니다. 사용자가 항상 무엇이든 액세스할 수 있도록 허용하는 것은 불가능합니다. 수정하는 동안 오류가 발생합니다.
그러나 반면에 절차적 스타일에 익숙한 사람들은 주어진 장소에서 변경할 수 있는 데이터와 변경할 수 없는 데이터를 기억하면서 이러한 경우에 스스로를 제한할 뿐입니다.
당신의 주장은 그가 의존하고 있는 지팡이의 필요성을 설명하고 증명하는 아주 늙은이의 주장과 같습니다. 그것 없이는 확실히 떨어질 것입니다. 그리고 있습니다. 하지만 모든 사람을 위한 것은 아닙니다.
매우 논쟁의 여지가 있습니다.))
아마도, 하지만 나는 또한 "90년대 후반의 공룡"이기도 합니다. Turbo Pascal과 라이브러리 형태의 그래픽의 시작도 보았고, 누가 뭐라고 해도 여전히 Norton Commander를 얻을 수 있습니다.))))
그리고 Delphi로의 도래(그리고 나의 전환)와 함께 인생은 이제 막 시작되었다고 합니다.... 이제 활성 창, 확인란 등을 만들 수 있는 방법이 좋지 않습니다. OOP가 없으면 이론상 가능할 수도 있지만 OOP 없이 구현하는 방법에 대한 계획조차 보이지 않습니다.
당신의 주장은 그가 의존하고 있는 지팡이의 필요성을 설명하고 증명하는 아주 늙은이의 주장과 같습니다. 그것 없이는 나는 확실히 떨어질 것입니다. 그리고 있습니다. 그러나 모든 사람을 위한 것은 아닙니다.
내가 기억하는 것처럼 당신은 방대한 데이터 배열에 있는 모든 것을 완벽하게 기억합니다. 나는 어렸을 때에도 그런 일들을 기억하지 못했다. 이제 내가 이미 늙은 방귀가 되었을 때 이 블록이나 저 블록을 작성할 때 염두에 둔 모든 것을 기억조차 할 수 없습니다. 이 "지팡이"는 정말 많은 도움이 됩니다. 그러나 누군가가 당신이 필요로 하는 모든 것을 기억 속에 간직할 수 있다면 당신은 그것 없이도 할 수 있다는 데 동의합니다.
그럼에도 불구하고 나는 이미 존경받는 fxsaber의 코드를 여러 번 인용했는데, 그 자신은 그것이 어떻게 작동하는지 정확히 말할 수 없었습니다. 기억하기가 정말 어려운 매우 까다롭고 불분명한 검사가 있다는 것입니다. 그리고 그 사람은 기억하지 못합니다. 우리는 "이 코드는 여러 번 테스트되었으므로 신뢰할 수 있습니다."라는 데 동의했습니다. 그러나 일부 작업 프로토콜이 변경되면 어떻게 됩니까? 코드는 즉시 무효가 되며 동시에 - 변경된 사항을 수정하는 대신 - 가장 많이 변경된 위치를 찾을 때까지 재검토해야 합니다.
이것이 바로 이 "스틱"의 용도입니다. 소프트웨어 제품은 이제 너무 복잡하여 모든 미묘함을 염두에 두는 것이 비현실적입니다. 이것은 다양한 기술이 사용되는 것입니다(OOP는 그 중 하나일 뿐입니다).