코드는 이식 가능하지 않으므로 이것이 그 기능입니다. 휴대하기 위한 것이 아닙니다. 다른 목적이 있습니다. 글쎄요, 변수의 전역 범위는 복잡한 메커니즘의 작동을 위한 강력한 도구입니다. 사용법만 알면 됩니다. 그리고 그들이 숨겨진 오류와 버그에 대해 나에게 말할 때 나는 길을 잃습니다. 변수의 전역 가시성과 관련된 버그가 없었습니다. 단어에서 전혀.
전역 변수의 문제는 프로젝트가 충분히 크고 이러한 변수의 상태가 코드의 여러 섹션에서 변경되면 버그를 찾는 것이 상당히 힘들다는 것입니다.
예시. 전역 변수의 값이 분명히 일치해야 하는 것과 일치하지 않는다는 사실과 관련된 버그를 찾았습니다. 프로젝트에는 이미 수십 개의 파일과 100500줄의 코드가 있습니다. 이 변수가 변경되는 코드의 위치를 아무도 기억하지 못합니다. 결과적으로 커피 한 캔과 머리를 clave에 넣은 건강한 수면.
그리고 지금은 똑같지만 OOP입니다. 코드를 올바르게 작성했으며 모든 필드는 비공개입니다. 따라서 클래스 메서드에서만 우리와 직접 변경되고 외부에서는 Set 메서드에 의해서만 변경됩니다. 따라서 우리는 Set 메소드에 breakpoint를 걸고, 필드가 변경되는 클래스에 얼마나 많은 메소드가 있는지, 변경이 이루어진 부분과 잘못 변경한 부분을 침착하게 추적합니다.
전역 변수의 문제는 프로젝트가 충분히 크고 이러한 변수의 상태가 코드의 여러 섹션에서 변경되면 버그를 찾는 것이 상당히 힘들다는 것입니다.
예시. 전역 변수의 값이 분명히 일치해야 하는 것과 일치하지 않는다는 사실과 관련된 버그를 찾았습니다. 프로젝트에는 이미 수십 개의 파일과 100500줄의 코드가 있습니다. 이 변수가 변경되는 코드의 위치를 아무도 기억하지 못합니다. 결과적으로 커피 한 캔과 머리를 clave에 넣은 건강한 수면.
그리고 지금은 똑같지만 OOP입니다. 코드를 올바르게 작성했으며 모든 필드는 비공개입니다. 따라서 클래스 메서드에서만 우리와 직접 변경되고 외부에서는 Set 메서드에 의해서만 변경됩니다. 따라서 우리는 Set 메소드에 breakpoint를 걸고, 필드가 변경되는 클래스에 얼마나 많은 메소드가 있는지, 변경이 이루어진 부분과 잘못 변경한 부분을 침착하게 추적합니다.
연습에서. 내 프로젝트에 100개 이상의 연결된 파일이 있습니다. 일부는 2000줄 이상의 코드를 가지고 있습니다. 전역 변수는 전체적으로 사용됩니다. 특히 글로벌성과 관련된 버그는 없었습니다. 그냥 익숙해진 것 아닐까요?)) 모든 변수가 러시아어로 되어 있고 모든 이름이 의미가 있기 때문에 아마 없을 것입니다. sdf 또는 iukj가 없습니다. 따라서 관련 오류가 없습니다. 기본적으로 저는 전역 이벤트 플래그에 전역 변수를 사용합니다. 예를 들어 창 열기, 마우스 버튼 누르기, 트리 목록 확장 등 ... 또한 포커스를 위해. 즉, 마우스가 GUI를 돌아다니며 전역 변수에 모든 객체와 요소의 수와 그 속성을 입력하고 필요한 블록을 OnChartEvent에서 호출하여 초점이 맞춰진 개체와 요소에 즉시 작업을 수행합니다. 매우 편안합니다.
나는 당신에게 명백한 사실을 어떻게 확신시킬 수 있는지조차 모릅니다. 그러나 그것은 아마도 가치가 없을 것입니다. 그들은 이것을 위해 나에게 돈을 지불하지 않습니까?
당신은 무엇을 위해 노력하고 있습니까? 글쎄, 당신이 칭찬을 받고 싶다면 - 유지하십시오 :
베드로! 잘했어, 계속해!
))))
나는 아무것도 얻지 못한다. 글쎄, 아마도 OOP를 사용하여 멋진 프로젝트 를 작성할 수 있다는 것을 이해하고 있을 것입니다. 그리고 OOP의 소유는 개발자의 표시일 뿐만 아니라. 나는 OOP로 많은 문제를 해결할 수 있다고 주장하지 않습니다. 그러나 다른 접근 방식도 있습니다.
Реter Konow : 글쎄, 아마도 OOP로 멋진 프로젝트를 작성할 수 있다는 것을 이해했을 것입니다. 그리고 OOP의 소유는 개발자의 표시일 뿐만 아니라. 나는 OOP로 많은 문제를 해결할 수 있다고 주장하지 않습니다. 그러나 다른 접근 방식도 있습니다.
이것은 OOP에 관한 것이 아니라 코드 작성의 바로 그 원칙에 대해 두 번째로 이야기하고 @Vladimir Simakov 가 위의 예를 작성했습니다.
변수의 전역 가시성을 사용하십시오. 예, 의심의 여지가 없습니다. 아무도 금지하지 않고 할 수 있습니다. 그러나 아무도 볼 수 없는 동안 조용히! )))
그러나 그것이 프로그램 작성의 지속적으로 사용되는 스타일이 얼마나 악한지, 그리고 더 많은 코드, 더 많은 이 악! - 그렇게 설명했습니까? )))
추신: 한 번 더 제어 샷 - MQL 도움말을 보세요. 모든 기능이 별도의 완성된 독립 블록에 의해 수행되는 것을 볼 수 있습니까? - 전달된 매개변수 = 수신된 결과! Metaquot 프로그래머가 다시 모든 것을 잘못하고 있다고 생각하십니까? 함수를 작성하려면 몇 가지 무료 스타일을 사용해야 합니다. 여기서는 전역 가시성에 대해 설명하지만 여기서는 사용자가 함수를 호출하고 결과를 얻습니다! )))) - 절차 스타일(각 서브루틴이 완전한 논리 블록인 경우)이 올바른 코드입니다. 코드를 올바르게 작성하십시오! 옳지 않습니다 ... 글쎄, "빨리 필요할 때"올 것입니다.)
Реter Konow : 연습에서. 내 프로젝트에 100개 이상의 연결된 파일이 있습니다. 일부는 2000줄 이상의 코드를 가지고 있습니다. 전역 변수는 전체적으로 사용됩니다. 특히 글로벌성과 관련된 버그는 없었습니다. 어쩌면 나는 그것에 익숙해지고 있습니까?
당신은 아주 좋은 기억을 가지고 있습니다. 모든 사람이 그렇게 운이 좋은 것은 아닙니다. 오늘 소개한 변수는 거의 기억나지 않습니다. 그리고 일주일 전에 - 그냥 잊어 버리십시오. 그러나 이것은 문제가 아니며 모두 로컬이며 모든 개체의 필드에 대한 액세스는 해당 기능을 통해서만 이루어집니다. OOP를 사용하면 많은 요점을 기억할 수 없습니다. 이미 두 번 이상 말했습니다. 이상적으로는 코드의 어느 위치에서나 필요한 것만 사용할 수 있어야 하며 단일 변수는 더 이상 사용할 수 없습니다. 따라서 원하는 경우에도 해서는 안 되는 것을 변경할 수 없습니다. 그리고 정말로 필요할 때변수에 대한 액세스 권한 을 얻으려면 액세스 권한이 없는 이유를 파악해야 합니다. 이것은 단지 실수일 뿐이거나 훨씬 더 자주 발생하는 이 변수를 수정하기 위한 추가 작업이 필요합니다. . 즉시 사용할 수 있는 경우 프로그램을 잊어버리고 오랫동안 프로그램이 작동하지 않거나 원하는 방식으로 작동하지 않는 이유를 알아낼 것입니다.
Реter Konow : 나는 아무것도 얻지 못한다. 글쎄, 아마도 OOP로 멋진 프로젝트를 작성할 수 있다는 것을 이해했을 것입니다. 그리고 OOP의 소유는 개발자의 표시일 뿐만 아니라. 나는 OOP로 많은 문제를 해결할 수 있다고 주장하지 않습니다. 그러나 다른 접근 방식도 있습니다.
OOP의 또 다른 좋은 점은 클래스 라이브러리, 그리고 평생 함께하고 이 삶을 더 쉽게 만들어주는 정말 보편적인 라이브러리를 천천히 습득한다는 것입니다.
실제 프로젝트에서 실제로 작동합니다. 여기서는 모든 것이 문제가 없습니다. 기존 주문/포지션의 수와 상태를 제어하기만 하면 됩니다. 이 기능은 포지션/오더가 청산/취소되지 않고 청산 후 목록에서 삭제되는 것만 제어합니다.
void OrdersControl(){
for (CTrade* it=gPos.Begine();
it!= NULL ;
it=it.Control()?gPos.Next():gPos.Delete());}
Реter Konow : 토론에 참여해 주신 모든 분들께 감사드립니다. 두 접근 방식의 가능성을 실제로 비교하기 위해 OOP를 이해하려고 노력할 것입니다. 저는 OOP가 제공할 수 있는 계층 구조에 관심이 있었고, OOP의 이점이 해당 구문에 묻혀 있지 않다면 확실히 서비스에 적용할 것입니다.
유튜브 도움말. 많이 있어요. 특히 당신이 친구인 영어에서.
미안해하지마, 피터, 45분. 초기 단계에서이 동지가 말하는 내용을 이해하는 것이 매우 중요합니다. 아마도 많은 사람들이 그와 논쟁할 것이지만 일반적으로 그가 옳습니다.
코드는 이식 가능하지 않으므로 이것이 그 기능입니다. 휴대하기 위한 것이 아닙니다. 다른 목적이 있습니다. 글쎄요, 변수의 전역 범위는 복잡한 메커니즘의 작동을 위한 강력한 도구입니다. 사용법만 알면 됩니다. 그리고 그들이 숨겨진 오류와 버그에 대해 나에게 말할 때 나는 길을 잃습니다. 변수의 전역 가시성과 관련된 버그가 없었습니다. 단어에서 전혀.
전역 변수의 문제는 프로젝트가 충분히 크고 이러한 변수의 상태가 코드의 여러 섹션에서 변경되면 버그를 찾는 것이 상당히 힘들다는 것입니다.
예시. 전역 변수의 값이 분명히 일치해야 하는 것과 일치하지 않는다는 사실과 관련된 버그를 찾았습니다. 프로젝트에는 이미 수십 개의 파일과 100500줄의 코드가 있습니다. 이 변수가 변경되는 코드의 위치를 아무도 기억하지 못합니다. 결과적으로 커피 한 캔과 머리를 clave에 넣은 건강한 수면.
그리고 지금은 똑같지만 OOP입니다. 코드를 올바르게 작성했으며 모든 필드는 비공개입니다. 따라서 클래스 메서드에서만 우리와 직접 변경되고 외부에서는 Set 메서드에 의해서만 변경됩니다. 따라서 우리는 Set 메소드에 breakpoint를 걸고, 필드가 변경되는 클래스에 얼마나 많은 메소드가 있는지, 변경이 이루어진 부분과 잘못 변경한 부분을 침착하게 추적합니다.
변수의 전역 가시성과 관련된 버그가 없었습니다. 단어에서 전혀.
나는 당신에게 명백한 사실을 어떻게 확신시킬 수 있는지조차 모릅니다. 그러나 그것은 아마도 가치가 없을 것입니다. 그들은 이것을 위해 나에게 돈을 지불하지 않습니까?
당신은 무엇을 위해 노력하고 있습니까? 글쎄, 당신이 칭찬을 받고 싶다면 - 유지하십시오 :
베드로! 잘했어, 계속해!
))))
전역 변수의 문제는 프로젝트가 충분히 크고 이러한 변수의 상태가 코드의 여러 섹션에서 변경되면 버그를 찾는 것이 상당히 힘들다는 것입니다.
예시. 전역 변수의 값이 분명히 일치해야 하는 것과 일치하지 않는다는 사실과 관련된 버그를 찾았습니다. 프로젝트에는 이미 수십 개의 파일과 100500줄의 코드가 있습니다. 이 변수가 변경되는 코드의 위치를 아무도 기억하지 못합니다. 결과적으로 커피 한 캔과 머리를 clave에 넣은 건강한 수면.
그리고 지금은 똑같지만 OOP입니다. 코드를 올바르게 작성했으며 모든 필드는 비공개입니다. 따라서 클래스 메서드에서만 우리와 직접 변경되고 외부에서는 Set 메서드에 의해서만 변경됩니다. 따라서 우리는 Set 메소드에 breakpoint를 걸고, 필드가 변경되는 클래스에 얼마나 많은 메소드가 있는지, 변경이 이루어진 부분과 잘못 변경한 부분을 침착하게 추적합니다.
나는 당신에게 명백한 사실을 어떻게 확신시킬 수 있는지조차 모릅니다. 그러나 그것은 아마도 가치가 없을 것입니다. 그들은 이것을 위해 나에게 돈을 지불하지 않습니까?
당신은 무엇을 위해 노력하고 있습니까? 글쎄, 당신이 칭찬을 받고 싶다면 - 유지하십시오 :
베드로! 잘했어, 계속해!
))))
글쎄, 아마도 OOP로 멋진 프로젝트를 작성할 수 있다는 것을 이해했을 것입니다. 그리고 OOP의 소유는 개발자의 표시일 뿐만 아니라. 나는 OOP로 많은 문제를 해결할 수 있다고 주장하지 않습니다. 그러나 다른 접근 방식도 있습니다.
이것은 OOP에 관한 것이 아니라 코드 작성의 바로 그 원칙에 대해 두 번째로 이야기하고 @Vladimir Simakov 가 위의 예를 작성했습니다.
변수의 전역 가시성을 사용하십시오. 예, 의심의 여지가 없습니다. 아무도 금지하지 않고 할 수 있습니다. 그러나 아무도 볼 수 없는 동안 조용히! )))
그러나 그것이 프로그램 작성의 지속적으로 사용되는 스타일이 얼마나 악한지, 그리고 더 많은 코드, 더 많은 이 악! - 그렇게 설명했습니까? )))
추신: 한 번 더 제어 샷 - MQL 도움말을 보세요. 모든 기능이 별도의 완성된 독립 블록에 의해 수행되는 것을 볼 수 있습니까? - 전달된 매개변수 = 수신된 결과! Metaquot 프로그래머가 다시 모든 것을 잘못하고 있다고 생각하십니까? 함수를 작성하려면 몇 가지 무료 스타일을 사용해야 합니다. 여기서는 전역 가시성에 대해 설명하지만 여기서는 사용자가 함수를 호출하고 결과를 얻습니다! )))) - 절차 스타일(각 서브루틴이 완전한 논리 블록인 경우)이 올바른 코드입니다. 코드를 올바르게 작성하십시오! 옳지 않습니다 ... 글쎄, "빨리 필요할 때"올 것입니다.)
연습에서. 내 프로젝트에 100개 이상의 연결된 파일이 있습니다. 일부는 2000줄 이상의 코드를 가지고 있습니다. 전역 변수는 전체적으로 사용됩니다. 특히 글로벌성과 관련된 버그는 없었습니다. 어쩌면 나는 그것에 익숙해지고 있습니까?
당신은 아주 좋은 기억을 가지고 있습니다. 모든 사람이 그렇게 운이 좋은 것은 아닙니다. 오늘 소개한 변수는 거의 기억나지 않습니다. 그리고 일주일 전에 - 그냥 잊어 버리십시오. 그러나 이것은 문제가 아니며 모두 로컬이며 모든 개체의 필드에 대한 액세스는 해당 기능을 통해서만 이루어집니다. OOP를 사용하면 많은 요점을 기억할 수 없습니다. 이미 두 번 이상 말했습니다. 이상적으로는 코드의 어느 위치에서나 필요한 것만 사용할 수 있어야 하며 단일 변수는 더 이상 사용할 수 없습니다. 따라서 원하는 경우에도 해서는 안 되는 것을 변경할 수 없습니다. 그리고 정말로 필요할 때변수에 대한 액세스 권한 을 얻으려면 액세스 권한이 없는 이유를 파악해야 합니다. 이것은 단지 실수일 뿐이거나 훨씬 더 자주 발생하는 이 변수를 수정하기 위한 추가 작업이 필요합니다. . 즉시 사용할 수 있는 경우 프로그램을 잊어버리고 오랫동안 프로그램이 작동하지 않거나 원하는 방식으로 작동하지 않는 이유를 알아낼 것입니다.
나는 아무것도 얻지 못한다. 글쎄, 아마도 OOP로 멋진 프로젝트를 작성할 수 있다는 것을 이해했을 것입니다. 그리고 OOP의 소유는 개발자의 표시일 뿐만 아니라. 나는 OOP로 많은 문제를 해결할 수 있다고 주장하지 않습니다. 그러나 다른 접근 방식도 있습니다.
OOP의 또 다른 좋은 점은 클래스 라이브러리, 그리고 평생 함께하고 이 삶을 더 쉽게 만들어주는 정말 보편적인 라이브러리를 천천히 습득한다는 것입니다.
실제 프로젝트에서 실제로 작동합니다. 여기서는 모든 것이 문제가 없습니다. 기존 주문/포지션의 수와 상태를 제어하기만 하면 됩니다. 이 기능은 포지션/오더가 청산/취소되지 않고 청산 후 목록에서 삭제되는 것만 제어합니다.
여기서 gPos는 CList<CTrade> gPos입니다.
CList 및 CTrade는 표준 라이브러리 에서 제공되지 않습니다.
CTrade - 내 라이브러리 CPosition에서 상속합니다.
실제로 아래는 프로젝트 코드의 가독성을 보장하기 위해서만 필요한 전체 CTrade입니다.
주문/위치 작업의 전체 구현은 플랫폼 간 라이브러리 파일 CPosition에 숨겨져 있습니다.토론에 참여해 주신 모든 분들께 감사드립니다. 두 접근 방식의 가능성을 실제로 비교하기 위해 OOP를 이해하려고 노력할 것입니다. 저는 OOP가 제공할 수 있는 계층 구조에 관심이 있었고, OOP의 이점이 해당 구문에 묻혀 있지 않다면 확실히 서비스에 적용할 것입니다.
유튜브 도움말. 많이 있어요. 특히 당신이 친구인 영어에서.
미안해하지마, 피터, 45분. 초기 단계에서이 동지가 말하는 내용을 이해하는 것이 매우 중요합니다. 아마도 많은 사람들이 그와 논쟁할 것이지만 일반적으로 그가 옳습니다.
유튜브 도움말. 많이 있어요. 특히 당신이 친구인 영어에서.
미안해하지마, 피터, 45분. 초기 단계에서이 동지가 말하는 내용을 이해하는 것이 매우 중요합니다. 아마도 많은 사람들이 그와 논쟁할 것이지만 일반적으로 그가 옳습니다.