디자인 시작에 대한 매우 일반적인 문제: 프로그램에서 이벤트 처리를 구성(구조화)하여 미래에 개발할 수 있고 동시에 이미 수행된 작업을 최소한으로 다시 실행하는 방법.
옵션에 대해 논의하시겠습니까?
일반적으로 이것은 보다 글로벌한 문제이며 유능한 이벤트 모델을 구성하는 데 국한되지 않습니다. 많은 것은 언어 자체에 달려 있습니다. 불행히도 MQL5 언어 도구는 지난 세기의 80년대 수준입니다. 현대 프로그래밍 표준은 OOP 프로그래밍의 원래 원칙에서 멀어졌습니다. 이제 상속보다 분해가 선호되고 인터페이스 수준에서 수평적 비계층적 링크가 다형성을 제공하며 다양한 표준 라이브러리 컬렉션, 분해 설계 및 프로젝트에 타사 어셈블리의 투명한 포함을 통해 코드 재사용이 제공됩니다.
C-4 : 일반적으로 이것은 보다 글로벌한 문제이며 유능한 이벤트 모델을 구성하는 데 국한되지 않습니다. 많은 것은 언어 자체에 달려 있습니다. 불행히도 MQL5 언어 도구는 지난 세기의 80년대 수준입니다. 현대 프로그래밍 표준은 OOP 프로그래밍의 원래 원칙에서 멀어졌습니다. 이제 상속보다 분해가 선호되고 인터페이스 수준에서 수평적 비계층적 링크가 다형성을 제공하며 다양한 표준 라이브러리 컬렉션, 분해 설계 및 프로젝트에 타사 어셈블리의 투명한 포함을 통해 코드 재사용이 제공됩니다.
그것으로부터 나는 객체 지향 프로그래밍의 주요 특징을 잘 배웠다. 프로그램을 편리한 "큐브"로 자르는 추가 기회로 전혀 구성되지 않습니다. 이는 추가 관련 편의일 뿐입니다. 주요 기능은 데이터 추상화 입니다.
산요우우우우우우우우우우우우우 : 당신은 객체 지향, 나는 기능적이라고 생각)
몇 문장으로 설명하겠습니다.
1. 절차적(알고리즘) 추상화는 함수형 프로그래밍의 특징입니다. 추상화 엔티티는 프로시저(함수)입니다. 구현에서 일부 작업 또는 계산을 수행하기 위한 요청을 분리할 수 있습니다. 기능 코드는 별도의 블록(프로시저, 기능)에 할당되며, 이 코드에 대한 액세스는 형식/실제 매개변수의 분리를 통해 발생합니다(이는 절차적 접근 방식의 본질이자 주요 기능입니다). 프로그램은 계산 또는 작업(예: 파일에 쓰기)의 방법(알고리즘)을 변경하기 위해 필요한 경우 변경되지 않은 상태로 남아 있을 수 있는 기회를 얻습니다.
그러나 프로그램이 기본 데이터 구조(예: 전역 배열)를 변경해야 하는 경우 이 데이터로 작동하는 많은 프로시저를 다시 작성해야 합니다. -- 이것은 절차적 프로그래밍 스타일의 기본적인 한계입니다.
2. 데이터 추상화 - 기본 규칙에 따라 기본 데이터 구조(기본 작업과 함께)를 별도의 엔터티("클래스")로 캡슐화: 절대 직접 액세스(캡슐화된 데이터)하지 않고 기능을 통해서만 액세스 이 목적을 위해 특별히 생성된 동일한 클래스("인터페이스"). 따라서 이 데이터로 작업하는 방식에서 데이터 저장 형태의 추상화가 이루어집니다. 그리고 지금까지 알려지지 않은(절차적 프로그래밍에서) 기회가 있습니다. 즉, 데이터를 표시하는 방법에 대해 미리 걱정하지 않고 프로그램을 개발할 수 있습니다. 데이터는 변경할 수 없는 표준 인터페이스를 통해 액세스되므로 프로젝트 개발의 모든 단계에서 데이터가 표시되는 방식을 개선할 수 있지만 이러한 변경으로 인해 프로젝트의 다른 부분을 변경할 필요가 없습니다. 절차적 프로그래밍에서는 이것이 불가능했습니다. 주 데이터의 구조는 처리 방법을 엄격하게 결정했습니다.
어서요, 저는 모델이 전혀 없었고, 절차적인 것부터 시작해서 객관적인 것으로 바꿨어요.
일반적으로 기본적으로 MQ에는 이벤트 모델이 있습니다. 우리는 처음에 모든 일이 일어나는 사건을 받습니다.
mq5 말씀하시는건가요?
같은 건 어때
스레드 " 오류, 버그, 질문 "에서:
디자인 시작에 대한 매우 일반적인 문제: 프로그램에서 이벤트 처리를 구성(구조화)하여 미래에 개발할 수 있고 동시에 이미 수행된 작업을 최소한으로 다시 실행하는 방법.
옵션에 대해 논의하시겠습니까?
일반적으로 이것은 보다 글로벌한 문제이며 유능한 이벤트 모델을 구성하는 데 국한되지 않습니다. 많은 것은 언어 자체에 달려 있습니다. 불행히도 MQL5 언어 도구는 지난 세기의 80년대 수준입니다. 현대 프로그래밍 표준은 OOP 프로그래밍의 원래 원칙에서 멀어졌습니다. 이제 상속보다 분해가 선호되고 인터페이스 수준에서 수평적 비계층적 링크가 다형성을 제공하며 다양한 표준 라이브러리 컬렉션, 분해 설계 및 프로젝트에 타사 어셈블리의 투명한 포함을 통해 코드 재사용이 제공됩니다.
예를 들어 문학의 종류가 있습니까?
특히 이 주제에 대해:
어떤 언어를 롤 모델로 생각합니까(현대성과 사용 용이성 측면에서)?
자바/C#
그리고 그것은 내 편견이 아니라(비록 그것이 없는 경우에도), 이러한 언어가 프로그래밍 기술의 오랜 진화의 최종 산물이라는 사실입니다. 그들은 우리 시대에 만들어졌으며 전임자의 경험을 기반으로합니다.
대규모 프로젝트 를 작성하기 전에 명확하고 잘 정립된 프로젝트 지원 인프라를 만드는 것이 좋습니다.
예를 들어 문학의 종류가 있습니까?
물론 있습니다.
// 문학에 관하여: 문학적 출처를 공유합시다. 그러나 실제 의사소통이 때때로 책(심지어 좋은 것)보다 학습에 훨씬 더 효과적이라는 사실을 잊지 말자.
--
한때(90년대 초반) 이 책은 많은 도움이 되었습니다.
B. Liskov, J. Gatag. "프로그램 개발에서 추상화 및 사양 사용."
그것으로부터 나는 객체 지향 프로그래밍의 주요 특징을 잘 배웠다. 프로그램을 편리한 "큐브"로 자르는 추가 기회로 전혀 구성되지 않습니다. 이는 추가 관련 편의일 뿐입니다. 주요 기능은 데이터 추상화 입니다.
당신은 객체 지향, 나는 기능적이라고 생각)
1. 절차적(알고리즘) 추상화는 함수형 프로그래밍의 특징입니다. 추상화 엔티티는 프로시저(함수)입니다. 구현에서 일부 작업 또는 계산을 수행하기 위한 요청을 분리할 수 있습니다. 기능 코드는 별도의 블록(프로시저, 기능)에 할당되며, 이 코드에 대한 액세스는 형식/실제 매개변수의 분리를 통해 발생합니다(이는 절차적 접근 방식의 본질이자 주요 기능입니다). 프로그램은 계산 또는 작업(예: 파일에 쓰기)의 방법(알고리즘)을 변경하기 위해 필요한 경우 변경되지 않은 상태로 남아 있을 수 있는 기회를 얻습니다.
그러나 프로그램이 기본 데이터 구조(예: 전역 배열)를 변경해야 하는 경우 이 데이터로 작동하는 많은 프로시저를 다시 작성해야 합니다. -- 이것은 절차적 프로그래밍 스타일의 기본적인 한계입니다.
2. 데이터 추상화 - 기본 규칙에 따라 기본 데이터 구조(기본 작업과 함께)를 별도의 엔터티("클래스")로 캡슐화: 절대 직접 액세스(캡슐화된 데이터)하지 않고 기능을 통해서만 액세스 이 목적을 위해 특별히 생성된 동일한 클래스("인터페이스"). 따라서 이 데이터로 작업하는 방식에서 데이터 저장 형태의 추상화가 이루어집니다. 그리고 지금까지 알려지지 않은(절차적 프로그래밍에서) 기회가 있습니다. 즉, 데이터를 표시하는 방법에 대해 미리 걱정하지 않고 프로그램을 개발할 수 있습니다. 데이터는 변경할 수 없는 표준 인터페이스를 통해 액세스되므로 프로젝트 개발의 모든 단계에서 데이터가 표시되는 방식을 개선할 수 있지만 이러한 변경으로 인해 프로젝트의 다른 부분을 변경할 필요가 없습니다. 절차적 프로그래밍에서는 이것이 불가능했습니다. 주 데이터의 구조는 처리 방법을 엄격하게 결정했습니다.
프로그램을 작성하기도 전에 간단한 알고리즘 언어인 종이에 스케치를 하는 방법을 가르쳐 주셨지만 전혀 익숙해지지 않았습니다.
이제 일반 프로그래머는 순서도를 그리지 않습니다. 이 모든 것은 학생들을 가르치기 위해 고안된 이론적 넌센스이지만 실제 프로젝트에서 작업하기 위한 것은 아닙니다.
추신 저는 종이에 그림을 그립니다. 그게 더 편해요. 때로는 50장까지 찍어도 명확한 구조가 나옵니다. 물론 특수 편집기에서 할 수는 있지만 각각이 저에게는 불편(제한적)이고, 공상의 비행을 실현하는 것은 불가능합니다. 간단히 말해서 작업 속도를 늦추는 것입니다.
그리고 프로젝트 중간 또는 더 가까이에 고객이 갑자기 변경하면 명확한 구조는 어떻게 됩니까?
이것은 프로젝트가 변경에 대한 준비가 되어 있고 변경에 저항하는 방법을 보여주는 좋은 테스트입니다. 실제로는 항상 원래 요구 사항의 변경 사항을 처리해야 합니다. 따라서 일반적으로 "모든 것을 예측" 패러다임에서 "문제 - 솔루션" 패러다임으로 이동하는 것이 좋습니다.