그런 예가 실제로 존재 합니까? 당신의 것이 아니라? 깊은 의심이 있습니다. 2000년대 초에 디버깅하고 작업한 코드 줄 수를 세는 것을 중단했는데, 백만 개를 초과했기 때문에 재미가 없었습니다. 그리고 작업의 다양성과 범위가 매우 다르지만 자신만의 클래스를 만들 필요가 전혀 없었습니다. 절차형 변수는 여러 사람의 작업을 병렬화해야 할 때 사용해야 했지만 더 이상은 필요하지 않습니다. 왜 그런 겁니까?
사실 OOP는 이미 만들어진 코드의 패키징에만 적용될 수 있고, 코드를 작성하는 단계에서는 간섭만 할 뿐입니다. 그러나 그러한 필요가 없다면 OOP는 필요하지 않습니다.
블라디미르 :
OOP는 계산의 자동 병렬화를 방지합니다. 이제 이것은 매우 심각한 결점으로 간주되어야 하며 전망은 OOP가 아닙니다.
여기에 한 번에 추가 경계를 추가 하면 코드의 가독성 이 상당히 복잡해지고 이러한 경계 때문에 길을 잃기 때문에 무언가가 어딘가에 도달하지 못했을 때 가능한 오류가 증가합니다.
그 반대가 사실입니다. 경계를 사용하면 "이 변수는 무엇을 위한 것이며, 이 경우에 어떤 역할을 합니까?"
사용자는 고려해야 할 사항과 변경할 수 있는 사항에만 액세스할 수 있습니다. 이것들은 "길을 따라 무엇인가를 잃어버렸을 때" 바로 그 실수입니다. 그리고 그것들은 바로 사용할 수 있는 것이 너무 많고 무언가가 " 도중에 잊혀졌기" 때문에 발생합니다. "잘린" 가상 인터페이스를 사용하면 이 작업을 수행하기가 훨씬 더 어렵습니다.
가장 간단한 예는 다음과 같습니다. 포지션은 MT4의 오픈 오더 또는 MT5의 오픈 포지션입니다.
전체 액세스 권한이 있는 경우 위치를 선택할 때 사용자는 현재 읽을 수 있는 변수, 현재 유효하지 않은 변수, 변경할 수 있는 변수와 그렇지 않은 변수를 기억해야 합니다.
인터페이스를 사용하면 모든 것이 훨씬 간단합니다. 당신은 그것을 얻었고 두 가지 기능만 포함합니다. 구성 요소 수를 가져오고 상수 구성 요소에 대한 포인터를 가져옵니다. 모두. 이 두 가지 기능의 도움으로 물리적으로 "불필요한 변수"에 액세스할 수 없습니다.
앤드류 :
물론 적어도 유용한 무언가를 위해 OOP의 귀를 어떻게든 잡아 당기고 싶은 욕망은 이해할 수 있지만 그러한 경우는 일반적으로 프로그래밍 분야가 아니라 상업 분야에 있습니다. 인터페이스의 아키텍처에 대해, 그리고 작업 시간에 유사한 즐거운 취미에 대해.
그리고 당신 자신은 조만간 이것에 올 것입니다. 또한 캡슐화는 "순수한 절차적" 접근 방식으로 수행할 수 있습니다. 그러나 OOP 접근 방식에서는 상속과 다형성도 "자동으로" 가져오기 때문에 이것이 더 편리합니다.
사실 OOP는 이미 만들어진 코드의 패키징에만 적용될 수 있고, 코드를 작성하는 단계에서는 간섭만 할 뿐입니다. 그러나 그러한 필요가 없다면 OOP는 필요하지 않습니다.
음 ... 아니. 모든 것이 반대입니다.
상호 작용 인터페이스 - "코드 작성 단계 이전"에도 초기에 정의됩니다. 실제로 인터페이스는 프로그래머에게 있어 모두 동일한 기술 사양입니다. Freelance의 모든 상호 작용은 명확한 참조 조건을 사용하여 수행됩니다. 여기에서 가상 인터페이스는 프로그래밍이 시작되는 일종의 TK입니다.
내가 이해하는 것처럼 당신은 OOP의 본질에 대한 잘못된 접근입니다. 먼저 많은 기능을 작성한 다음 OOP 디자인에 "압착"해야 합니다. 그러나 이것은 잘못된 방법입니다. 반대로 하는 것이 옳습니다. 먼저 OOP 설계가 결정되고 시스템 구성 요소 간의 기본 인터페이스 집합이 결정됩니다. 그런 다음 각 구성 요소는 이러한 미리 정의된 인터페이스를 준수하여 순차적으로 작성됩니다.
예, 쓸 때 인터페이스가 무언가를 제공하지 않은 것으로 나타났습니다. 그리고 시작됩니다 ... "Voooot ... 절차적 접근 방식 - 이 모든 것에 액세스할 수 있고 문제 없이 필요한 작업을 수행했을 것입니다. 이제 - 어떻게 이러한 변수에 액세스할 수 있습니까?" 이것은 인터페이스 디자인 단계에서 고려되지 않은 것이 있을 때 발생합니다. 그리고 이것은 매우 불쾌한 상황입니다. 몇 가지 추가 인터페이스를 추가하거나 기존 인터페이스를 변경해야 하며, 이는 오류로 가득 차 있습니다. 물론 그러한 상황은 피해야 합니다.
가장 간단한 예는 다음과 같습니다. 포지션은 MT4의 오픈 오더 또는 MT5의 오픈 포지션입니다.
전체 액세스 권한이 있는 경우 위치를 선택할 때 사용자는 현재 읽을 수 있는 변수, 현재 유효하지 않은 변수, 변경할 수 있는 변수와 그렇지 않은 변수를 기억해야 합니다.
인터페이스를 사용하면 모든 것이 훨씬 간단합니다. 당신은 그것을 얻었고 두 가지 기능만 포함합니다. 구성 요소 수를 가져오고 상수 구성 요소에 대한 포인터를 가져옵니다. 모두. 이 두 가지 기능의 도움으로 물리적으로 "불필요한 변수"에 액세스할 수 없습니다.
그 반대가 사실입니다. 예를 들어 품질 모듈 테스트를 위해 사용자가 내부 변수를 아는 것이 종종 중요하지만 그렇지 않습니다. 그리고 그들은 나중에 이 액세스 권한을 얻는 방법을 특별하고 까다로운 방법으로 제시합니다. 따라서 원칙적으로 불필요한 정보는 없으며 필요하지 않은 사람들은 단순히 사용하지 않을 수 있습니다.
그 반대가 사실입니다. 예를 들어 품질 모듈 테스트를 위해 사용자가 내부 변수를 아는 것이 종종 중요하지만 그렇지 않습니다. 그리고 그들은 나중에 이 액세스 권한을 얻는 방법을 특별하고 까다로운 방법으로 제시합니다. 따라서 원칙적으로 불필요한 정보는 없으며 필요하지 않은 사람들은 단순히 사용하지 않을 수 있습니다.
예를 들어, 입력 신호 생성기를 작성하는 경우 자금 관리와 관련된 정보에 액세스할 수 없어야 합니다.
물론 디버깅할 때 입력이 발생하지 않은 상황이 발생할 수 있습니다. 자금 관리에서 작업을 금지했기 때문에(예: 마진이 충분하지 않음) 이러한 상황이 발생한 경우 즉시 제거해야 합니다. 그리고 입력 생성기에서 그것에 대해 어떻게 알 수 있습니까? 아니요, 액세스 권한이 없습니다. 그러나이 경우 발생기가 입력에 신호를 보내고 올바르게 작동하는지 확인하는 것으로 충분합니다. 입력이 없었습니다. 다른 이유로 입력 생성기 외부에 있습니다. 그 이유를 알아내는 것은 모든 자금 관리 변수에 직접 액세스할 수 있는 경우보다 실제로 다소 어렵습니다. 그러나 정상적인 정규 근무 중에 액세스할 수 있는 "잘못된 위치에 들어갈 것"이 훨씬 더 위험합니다.
누가 제안했는지 모르겠지만 MT4에 있는 모든 것을 MT5로 옮기면 모두가 전환할 것입니다.
George Merts :
첫째, 부분이 작성된 다음 전체로 결합됩니다. 종종 부분이 서로 잘 호환되지 않는다는 사실에 직면합니다. 그런데 이것이 바로 "사용 가능한 모든 변수에 액세스할 수 있는 권한을 갖고자 하는 욕구"를 설명하는 것입니다. ."
아니요. 가능한 모든 변수에 대한 액세스에는 문제가 없지만 필요한 변수에만 액세스할 수 있습니다. 일반적으로 이들은 서로 다른 기능의 입력 및 출력 변수입니다.
여기에 한 번에 추가 경계를 추가 하면 코드의 가독성 이 상당히 복잡해지고 이러한 경계로 인해 도중에 손실되었기 때문에 무언가가 어딘가에 도달하지 않았을 때 발생할 수 있는 오류가 증가합니다.
물론 적어도 유용한 무언가를 위해 OOP의 귀를 어떻게든 잡아 당기고 싶은 욕망은 이해할 수 있지만 그러한 경우는 일반적으로 프로그래밍 분야가 아니라 상업 분야에 있습니다. 인터페이스의 아키텍처에 대해, 그리고 작업 시간에 유사한 즐거운 취미에 대해.
그런 예가 실제로 존재 합니까? 당신의 것이 아니라? 깊은 의심이 있습니다. 2000년대 초에 디버깅하고 작업한 코드 줄 수를 세는 것을 중단했는데, 백만 개를 초과했기 때문에 재미가 없었습니다. 그리고 작업의 다양성과 범위가 매우 다르지만 자신만의 클래스를 만들 필요가 전혀 없었습니다. 절차형 변수는 여러 사람의 작업을 병렬화해야 할 때 사용해야 했지만 더 이상은 필요하지 않습니다. 왜 그런 겁니까?
사실 OOP는 이미 만들어진 코드의 패키징에만 적용될 수 있고, 코드를 작성하는 단계에서는 간섭만 할 뿐입니다. 그러나 그러한 필요가 없다면 OOP는 필요하지 않습니다.
블라디미르 :
OOP는 계산의 자동 병렬화를 방지합니다. 이제 이것은 매우 심각한 결점으로 간주되어야 하며 전망은 OOP가 아닙니다.
Systemverilog와 같은 언어의 관점.
isNewBar() 함수가 자연에 전혀 존재하지 않아야 한다는 사실을 제외하고는 모든 것이 괜찮습니다. 그런 사소한 일 주위에 많은 춤이 있다는 것이 웃기다.
변수일 뿐이고 막대의 시간과 비교했을 뿐입니다. 모든 경우가 성공했다면 마지막에 변수에 새 막대 의 시간이 할당됩니다. 그렇지 않으면 모든 경우에 한 번의 시도만 할당됩니다.
여기에 한 번에 추가 경계를 추가 하면 코드의 가독성 이 상당히 복잡해지고 이러한 경계 때문에 길을 잃기 때문에 무언가가 어딘가에 도달하지 못했을 때 가능한 오류가 증가합니다.
그 반대가 사실입니다. 경계를 사용하면 "이 변수는 무엇을 위한 것이며, 이 경우에 어떤 역할을 합니까?"
사용자는 고려해야 할 사항과 변경할 수 있는 사항에만 액세스할 수 있습니다. 이것들은 "길을 따라 무엇인가를 잃어버렸을 때" 바로 그 실수입니다. 그리고 그것들은 바로 사용할 수 있는 것이 너무 많고 무언가가 " 도중에 잊혀졌기" 때문에 발생합니다. "잘린" 가상 인터페이스를 사용하면 이 작업을 수행하기가 훨씬 더 어렵습니다.
가장 간단한 예는 다음과 같습니다. 포지션은 MT4의 오픈 오더 또는 MT5의 오픈 포지션입니다.
전체 액세스 권한이 있는 경우 위치를 선택할 때 사용자는 현재 읽을 수 있는 변수, 현재 유효하지 않은 변수, 변경할 수 있는 변수와 그렇지 않은 변수를 기억해야 합니다.
인터페이스를 사용하면 모든 것이 훨씬 간단합니다. 당신은 그것을 얻었고 두 가지 기능만 포함합니다. 구성 요소 수를 가져오고 상수 구성 요소에 대한 포인터를 가져옵니다. 모두. 이 두 가지 기능의 도움으로 물리적으로 "불필요한 변수"에 액세스할 수 없습니다.
앤드류 :
물론 적어도 유용한 무언가를 위해 OOP의 귀를 어떻게든 잡아 당기고 싶은 욕망은 이해할 수 있지만 그러한 경우는 일반적으로 프로그래밍 분야가 아니라 상업 분야에 있습니다. 인터페이스의 아키텍처에 대해, 그리고 작업 시간에 유사한 즐거운 취미에 대해.
그리고 당신 자신은 조만간 이것에 올 것입니다. 또한 캡슐화는 "순수한 절차적" 접근 방식으로 수행할 수 있습니다. 그러나 OOP 접근 방식에서는 상속과 다형성도 "자동으로" 가져오기 때문에 이것이 더 편리합니다.
누가 제안했는지 모르겠지만 MT4에 있는 모든 것을 MT5로 옮기면 모두가 전환할 것입니다.
문제는 5-ke에 없는 무언가가 4-ke에 있다는 것 뿐만이 아닙니다. 그리고 OOP도 아닙니다.
5는 거래자에게 실질적으로 아무것도 주지 않았습니다(프로그래머도, 프로그래머도 거래자가 아닌 - 거래자일 뿐입니다).
고유한 형식의 역사, 관습 금지 - 그러나 이 두 가지 점만이 기하학을 거래하는 모든 사람을 두려워했습니다. 그리고 "많은 TF"(연간 없음, lol)도 없고 막대당 점수의 척도가 그들을 끌어들이지 않을 것입니다.
간단한 질문입니다. 그리드는 무엇을 보여줍니까? 알아내려고 하면 프리랜서를 신청하고 원하는 것을 주문하라는 권장 사항이 표시됩니다.
MT - 프로그래머용 터미널. 이것이 전체 답변입니다.
사실 OOP는 이미 만들어진 코드의 패키징에만 적용될 수 있고, 코드를 작성하는 단계에서는 간섭만 할 뿐입니다. 그러나 그러한 필요가 없다면 OOP는 필요하지 않습니다.
음 ... 아니. 모든 것이 반대입니다.
상호 작용 인터페이스 - "코드 작성 단계 이전"에도 초기에 정의됩니다. 실제로 인터페이스는 프로그래머에게 있어 모두 동일한 기술 사양입니다. Freelance의 모든 상호 작용은 명확한 참조 조건을 사용하여 수행됩니다. 여기에서 가상 인터페이스는 프로그래밍이 시작되는 일종의 TK입니다.
내가 이해하는 것처럼 당신은 OOP의 본질에 대한 잘못된 접근입니다. 먼저 많은 기능을 작성한 다음 OOP 디자인에 "압착"해야 합니다. 그러나 이것은 잘못된 방법입니다. 반대로 하는 것이 옳습니다. 먼저 OOP 설계가 결정되고 시스템 구성 요소 간의 기본 인터페이스 집합이 결정됩니다. 그런 다음 각 구성 요소는 이러한 미리 정의된 인터페이스를 준수하여 순차적으로 작성됩니다.
예, 쓸 때 인터페이스가 무언가를 제공하지 않은 것으로 나타났습니다. 그리고 시작됩니다 ... "Voooot ... 절차적 접근 방식 - 이 모든 것에 액세스할 수 있고 문제 없이 필요한 작업을 수행했을 것입니다. 이제 - 어떻게 이러한 변수에 액세스할 수 있습니까?" 이것은 인터페이스 디자인 단계에서 고려되지 않은 것이 있을 때 발생합니다. 그리고 이것은 매우 불쾌한 상황입니다. 몇 가지 추가 인터페이스를 추가하거나 기존 인터페이스를 변경해야 하며, 이는 오류로 가득 차 있습니다. 물론 그러한 상황은 피해야 합니다.
가장 간단한 예는 다음과 같습니다. 포지션은 MT4의 오픈 오더 또는 MT5의 오픈 포지션입니다.
전체 액세스 권한이 있는 경우 위치를 선택할 때 사용자는 현재 읽을 수 있는 변수, 현재 유효하지 않은 변수, 변경할 수 있는 변수와 그렇지 않은 변수를 기억해야 합니다.
인터페이스를 사용하면 모든 것이 훨씬 간단합니다. 당신은 그것을 얻었고 두 가지 기능만 포함합니다. 구성 요소 수를 가져오고 상수 구성 요소에 대한 포인터를 가져옵니다. 모두. 이 두 가지 기능의 도움으로 물리적으로 "불필요한 변수"에 액세스할 수 없습니다.
그 반대가 사실입니다. 예를 들어 품질 모듈 테스트를 위해 사용자가 내부 변수를 아는 것이 종종 중요하지만 그렇지 않습니다. 그리고 그들은 나중에 이 액세스 권한을 얻는 방법을 특별하고 까다로운 방법으로 제시합니다. 따라서 원칙적으로 불필요한 정보는 없으며 필요하지 않은 사람들은 단순히 사용하지 않을 수 있습니다.
그 반대가 사실입니다. 예를 들어 품질 모듈 테스트를 위해 사용자가 내부 변수를 아는 것이 종종 중요하지만 그렇지 않습니다. 그리고 그들은 나중에 이 액세스 권한을 얻는 방법을 특별하고 까다로운 방법으로 제시합니다. 따라서 원칙적으로 불필요한 정보는 없으며 필요하지 않은 사람들은 단순히 사용하지 않을 수 있습니다.
"교활한 액세스 권한"이 필요한 경우 시스템이 잘못 설계 되었음을 나타냅니다.
예를 들어, 입력 신호 생성기를 작성하는 경우 자금 관리와 관련된 정보에 액세스할 수 없어야 합니다.
물론 디버깅할 때 입력이 발생하지 않은 상황이 발생할 수 있습니다. 자금 관리에서 작업을 금지했기 때문에(예: 마진이 충분하지 않음) 이러한 상황이 발생한 경우 즉시 제거해야 합니다. 그리고 입력 생성기에서 그것에 대해 어떻게 알 수 있습니까? 아니요, 액세스 권한이 없습니다. 그러나이 경우 발생기가 입력에 신호를 보내고 올바르게 작동하는지 확인하는 것으로 충분합니다. 입력이 없었습니다. 다른 이유로 입력 생성기 외부에 있습니다. 그 이유를 알아내는 것은 모든 자금 관리 변수에 직접 액세스할 수 있는 경우보다 실제로 다소 어렵습니다. 그러나 정상적인 정규 근무 중에 액세스할 수 있는 "잘못된 위치에 들어갈 것"이 훨씬 더 위험합니다.
"교활한 액세스 권한"이 필요한 경우 시스템이 잘못 설계되었음을 나타냅니다.
발달은 주로 마음의 자연스러운 과정입니다.
이 과정에서 아이디어는 자유롭고 자발적으로 형성됩니다.
OOP를 따르면 무료 코드 변환이 복잡해집니다.
개발의 자연스러운 과정에서 코드 자체는 점차 압축되고 보편화됩니다.
자연스러운 과정에서 기능은 분해되지 않고 오히려 성장하여 큰 블록으로 결합됩니다.
큰 블록은 광범위한 작업을 해결합니다.
OOP는 이러한 블록의 형성을 방해하여 코드를 단편화합니다.
OOP는 복잡한 액세스를 생성하므로 변수에 대한 참조 수가 꾸준히 증가하고 있습니다.
액세스 제어의 장점은 단일 메커니즘을 만드는 어려움으로 인해 상쇄됩니다.
주요 단점: OOP를 사용하면 코드를 여러 기능으로 분할하는 경로를 따라야 합니다.
사람이 단편화 된 코드를 인식하는 것이 더 쉽지만 단편화는 모든 메커니즘에서 금기입니다.