아마도 당신이 옳을 수도 있습니다. 나는 그런 용어를 기억했습니다. 몇 달 전에 다른 포럼에서 자신을 다음과 같이 불렀습니다. 캐주얼 프로그래머, 나는 이것이 의미하는 바를 명확히하려고 시도했습니다. 내 지식에 따르면 캐주얼이라는 단어는 Android 게임 - "Zuma", 우연히 프로그래밍하는 프로그래머라는 사실이 밝혀졌습니다.
엄격한 코드 작성 형식은 OOP에서 저를 거부합니다. 보시다시피 저는 큰 데이터 테이블을 만드는 경향이 있으며 이것이 매우 실용적입니다. OOP에서는 개인적으로 나를 많이 속박하는 여러 규칙을 준수해야 합니다.
요컨대, 나는 다른 OOP로 프로그래밍하고 있습니다. 그의. 규칙은 적고 자유는 많습니다. 기능 자체는 큰 블록으로 구성되고 데이터는 코어에서 구성됩니다. 일부러 구조를 생각하지도 않는다. 모든 것은 스스로 발전합니다. 직관적인 수준에서.
Peter, 이 규칙은 당신 자신에게 필요한 것입니다. 그들이 당신을 "묶는"것입니다. 실수로 아무 것도 망치지 않도록, 그리고 의도하지 않은 방식으로 어딘가에 맞지 않도록. 사실, OOP 스타일은 "도로의 규칙"입니다. 물론 그들은 운전자를 제한합니다. 그리고 3야드가 있는 마을에서는 아무도 그들을 쳐다보지 않습니다. 더 쉽고 빠릅니다(더 효율적입니다). 그러나 대도시에서는 그 반대가 사실입니다. 가장 효율적인 교통 통신을 가능하게 하는 것은 교통 규칙입니다. OOP도 마찬가지입니다. 이것은 크고 복잡한 시스템을 가장 효율적으로 구축할 수 있는 규칙입니다.
귀하의 시스템 - 아직 변경 사항이 없으며 매우 제한적으로 사용되며 수정할 필요가 없습니다. 그렇기 때문에 머리에 새길 수 있습니다. 시스템에 사용자가 있고 개선이 필요한 경우(제어 및 캡슐화 부족) 매우 스트레스를 받을 것입니다.
다른 모든 것 - 차이가 없습니다. OOP와 스타일(이미 언급했듯이 절차 스타일도 같은 단점을 가지고 있습니다 - 전역 변수 , 유형 제어 부족 등)은 그렇지 않으면 가깝습니다.
당신의 스타일을 방어하기 위해 증명해야 할 유일한 것은 전체 시스템을 거대한 전역 랜덤 액세스 배열로 유지하는 것이 프로그램을 다형성 상속 체인에 중첩되고 캡슐화에 의해 숨겨지는 작은 부분으로 나누는 것보다 낫다는 것입니다.
그건 그렇고, 포럼에 상속을 좋아하지 않는 사람들이 있습니다. 그들이 당신을 지원할 수 있다고 생각합니다.
다른 모든 것 - 차이가 없습니다. OOP와 스타일(이미 언급했듯이 절차 스타일도 같은 단점을 가지고 있습니다 - 전역 변수 , 유형 제어 부족 등)은 그렇지 않으면 가깝습니다.
물론 내가 틀릴 수 있고 구글링하기에는 너무 게으르지만 절차적 스타일은 프로시저(함수)의 논리적 완전성을 의미합니다. 즉, 소스에서 "추출"하고 다른 코드에서 사용합니다. 내장 MQL 함수가 데이터를 매개변수로 받아들이고 결과를 반환하는 방법.... 그리고 Peter의 경우 두 발 모두 절름발이입니다. ))) - 전역적으로 선언된 변수를 통한 교환은 코드의 이식성을 감소시키고 추적하기 어려운 버그 ;)
아니요, 캐주얼 프로그래밍에 대한 토론이 있는 동안 저는 담요를 OOP로 끌어오는 것뿐입니다. topicstarter는 여전히 보류 중입니다! 모든 것을 머리 속에 보관할 수 있다고 씁니다 - 글쎄, 그것은 캐주얼 프로그래밍입니다)))
코어 엔진
자연스럽게 프로그래밍
캐주얼 프로그래밍 :)
캐주얼 프로그래밍 :)
아마도 당신이 옳을 수도 있습니다. 나는 그런 용어를 기억했습니다. 몇 달 전에 다른 포럼에서 자신을 다음과 같이 불렀습니다. 캐주얼 프로그래머, 나는 이것이 의미하는 바를 명확히하려고 시도했습니다. 내 지식에 따르면 캐주얼이라는 단어는 Android 게임 - "Zuma", 우연히 프로그래밍하는 프로그래머라는 사실이 밝혀졌습니다.
OOP는 매우 유연한 방법론이므로 "코어" 개념과 같은 선험적 아이디어가 없습니다. 그러나 OOP를 사용하면 여기에서 논의되는 커널 모델을 아주 잘 구축할 수 있습니다. 따라서 그 진술은 완전히 정확하지 않습니다.
아니요, OOP가 전혀 없습니다. 커널은 Unix이고 커널 주변의 모든 것을 수집합니다. 쉘 - Windows처럼 보이는 모든 것 - 우리는 불필요한 것을 제거하고 나머지는 작업합니다. 일반적으로 이것은 운영 체제에 관한 것입니다.
캐주얼 프로그래밍 :)
캐주얼, 걱정 마세요.
엄격한 코드 작성 형식은 OOP에서 저를 거부합니다. 보시다시피 저는 큰 데이터 테이블을 만드는 경향이 있으며 이것이 매우 실용적입니다. OOP에서는 개인적으로 나를 많이 속박하는 여러 규칙을 준수해야 합니다.
요컨대, 나는 다른 OOP로 프로그래밍하고 있습니다. 그의. 규칙은 적고 자유는 많습니다. 기능 자체는 큰 블록으로 구성되고 데이터는 코어에서 구성됩니다. 일부러 구조를 생각하지도 않는다. 모든 것은 스스로 발전합니다. 직관적인 수준에서.Peter, 이 규칙은 당신 자신에게 필요한 것입니다. 그들이 당신을 "묶는"것입니다. 실수로 아무 것도 망치지 않도록, 그리고 의도하지 않은 방식으로 어딘가에 맞지 않도록. 사실, OOP 스타일은 "도로의 규칙"입니다. 물론 그들은 운전자를 제한합니다. 그리고 3야드가 있는 마을에서는 아무도 그들을 쳐다보지 않습니다. 더 쉽고 빠릅니다(더 효율적입니다). 그러나 대도시에서는 그 반대가 사실입니다. 가장 효율적인 교통 통신을 가능하게 하는 것은 교통 규칙입니다. OOP도 마찬가지입니다. 이것은 크고 복잡한 시스템을 가장 효율적으로 구축할 수 있는 규칙입니다.
귀하의 시스템 - 아직 변경 사항이 없으며 매우 제한적으로 사용되며 수정할 필요가 없습니다. 그렇기 때문에 머리에 새길 수 있습니다. 시스템에 사용자가 있고 개선이 필요한 경우(제어 및 캡슐화 부족) 매우 스트레스를 받을 것입니다.
다른 모든 것 - 차이가 없습니다. OOP와 스타일(이미 언급했듯이 절차 스타일도 같은 단점을 가지고 있습니다 - 전역 변수 , 유형 제어 부족 등)은 그렇지 않으면 가깝습니다.
당신의 스타일을 방어하기 위해 증명해야 할 유일한 것은 전체 시스템을 거대한 전역 랜덤 액세스 배열로 유지하는 것이 프로그램을 다형성 상속 체인에 중첩되고 캡슐화에 의해 숨겨지는 작은 부분으로 나누는 것보다 낫다는 것입니다.
그건 그렇고, 포럼에 상속을 좋아하지 않는 사람들이 있습니다. 그들이 당신을 지원할 수 있다고 생각합니다.
Peter의 방법과 반대로 OOP를 사용하는 또 다른 이점. OOP에서 프로그래머는 기본 클래스의 소스 코드가 필요하지 않으며 작동 방식을 이해할 필요도 없습니다. 기본 클래스의 기능을 확장하거나 변경하려면 이 클래스의 상속자를 만드는 것으로 충분합니다.
Peter의 방법을 사용하는 경우 프로그래머는 전체 긴 코드 발판을 이해해야 하며 이 코드에 대한 소스 코드가 없으면 다시 작성해야 합니다.
다른 모든 것 - 차이가 없습니다. OOP와 스타일(이미 언급했듯이 절차 스타일도 같은 단점을 가지고 있습니다 - 전역 변수 , 유형 제어 부족 등)은 그렇지 않으면 가깝습니다.
물론 내가 틀릴 수 있고 구글링하기에는 너무 게으르지만 절차적 스타일은 프로시저(함수)의 논리적 완전성을 의미합니다. 즉, 소스에서 "추출"하고 다른 코드에서 사용합니다. 내장 MQL 함수가 데이터를 매개변수로 받아들이고 결과를 반환하는 방법.... 그리고 Peter의 경우 두 발 모두 절름발이입니다. ))) - 전역적으로 선언된 변수를 통한 교환은 코드의 이식성을 감소시키고 추적하기 어려운 버그 ;)
좋은. 내가 확신하게 해줘.
원칙적으로 나는이 모든 것을 오랫동안 이해합니다. 그리고 나는 그것에 동의합니다. 그러나 동시에 나는 내 접근 방식을 선호합니다. 왜요?
한 가지 구체적인 이유가 있습니다.
프로그램 개발.
//----------------------------------------
OOP와 내 접근 방식을 사용하면 프로그램이 얼마나 빨리 개발됩니까? 메커니즘의 성장과 복잡성에 더 유리한 접근 방식은 무엇입니까?
나는 내 접근 방식 + 코드의 모국어(60% 러시아어 및 40% 영어)가 프로그램의 가장 빠른 성장을 제공한다고 결론지었습니다.
이 빠른 성장이 바로 나에게 필요한 것입니다. 세부 사항을 파고 들지 마십시오. 코드의 모든 줄을 가리키지 않습니다. 전문적인 접근 방식이 아닙니다.
나는 빨리 발전하고 더 복잡해지기 위해 프로그램이 필요했습니다. 할당된 기능을 구현하는 메커니즘을 생성합니다. 빠르고 쉽습니다.
몇 줄의 코드로 새로운 기능을 추가할 수 있습니다.
내 접근 방식은 이 특정 문제를 해결하는 데 OOP보다 우수합니다.