절차 코드가 할 수 없는 OOP 코드는 무엇입니까?
OOP는 자연 존재처럼 작동하고 생각하도록 설계되었습니다. 다양한 유형의 차량, 많은 기술을 가진 군인 및 다양한 사양의 무기가 있는 전쟁 게임을 개발하려는 경우를 상상해 봅시다.
OOP 없이 이런 종류의 게임을 개발하는 것은 개발자가 이러한 모든 종류의 개체를 추적하고 데이터 구조와 메모리를 잘 관리하고 상속과 같은 OOP 기능을 시뮬레이션하는 데 어려움을 겪을 것입니다. 할 수 있음), OOP를 사용하면 코드를 읽고 디버그하는 것도 더 쉽게 생각하고 개발할 수 있습니다.
때때로 OOP가 필요 이상으로 있으면 내가 좋아하지 않는 코드를 이해하고 읽는 것이 비우호적입니다(내 개인적인 관점).
사실, 절차 코드에서 OOP로 또는 그 반대로 리팩토링할 수 없는 작업이 있을 수 있다고 생각하지 않습니다. 차이점은 코드의 유지 관리 가능성과 가독성에 있습니다. 예를 들어 절차 코드에서 전역 및/또는 지역 데이터(변수)를 참조할 수 있습니다. 여기에 더해 OOP는 객체 내부 변수(상태)라는 범위를 하나 더 추가합니다. OOP에서 사용하는 것은 매우 쉽고 자연스럽습니다. 동일한 논리를 절차적으로 구현하려면 추가 코드 및 데이터 구조 가 포함된 일종의 해결 방법이 필요합니다. 즉, OOP는 더 짧고 멋진 코딩 방법입니다.
OOP의 가장 중요한 부분인 상속 트리를 포함하여 과부하된 가상 기능에 대한 해결 방법을 어떻게 구축하고 싶습니까? OOP가 아닌 구조체에 대해 이야기하는 것 같습니다.
OOP는 자연 존재처럼 작동하고 생각하도록 설계되었습니다. 다양한 유형의 차량, 많은 기술을 가진 군인 및 다양한 사양의 무기가 있는 전쟁 게임을 개발하려는 경우를 상상해 봅시다.
OOP 없이 이런 종류의 게임을 개발하는 것은 개발자가 이러한 모든 종류의 개체를 추적하고 데이터 구조와 메모리를 잘 관리하고 상속과 같은 OOP 기능을 시뮬레이션하는 데 어려움을 겪을 것입니다. 할 수 있음), OOP는 코드를 읽고 디버그하기 위해 더 쉽게 생각하고 개발할 수 있도록 했습니다.
때때로 OOP가 필요 이상으로 있으면 내가 좋아하지 않는 코드를 이해하고 읽는 것이 비우호적입니다(내 개인적인 관점).
거래, 자동 거래 시스템 및 거래 전략 테스트에 관한 포럼
Alain Verleyen , 2016.05.22 14:03
객체 지향 프로그래밍과 절차적 프로그래밍의 장점에 대한 유용한 정보를 수집하기 위해 이 주제를 시작합니다.
또한 이 주제는 mql4 및 mql5가 동일한 OOP 언어를 제공하므로 언어 독립적입니다(현재 mql4에서 아직 사용할 수 없는 일부 새로운 고급 기능 제외).
나는 OOP의 지지자와 반대자 사이의 "전쟁"을 원하지 않으므로 이 주제는 밀접하게 조정될 것입니다. 시간을 낭비하지 마십시오.
또한 높은 이론이나 추상적인 개념이 아닌 귀하의 요점을 설명하는 예제와 코드를 제공하십시오.
편집: 이 주제는 언어 독립적이지만 우리는 여전히 거래 및 mql4/mql5에 대해 이야기하고 있으므로 "전쟁 게임" 또는 "사과와 오렌지" 예제는 사용하지 마십시오.
저는 OOP의 열렬한 팬입니다. 절차적 MQL로 돌아갈 것이라고는 상상조차 할 수 없습니다. 프로그램을 더 복잡하게 만드는 것이 더 쉽습니다. 어쨌든... MQL의 문제는 새로운 사용자가 여기서 시작하기 어렵다는 것입니다.
- 내장 이벤트 메서드는 OO가 아닙니다. 그것들에 연결해야 하므로 루트 수준에서 수신 개체를 선언해야 합니다. 이 설계에서는 기본적인 OOP 원칙 중 하나가 손상되었습니다.
- 공통 패턴을 가진 누락된 '시스템' 코드 패키지가 있습니다. 이는 사용자 간에 호환되는 패키지를 만드는 것을 방지하며, 진지한 OOP 코더는 개인용 패키지를 만드는 데 많은 시간이 필요합니다. 지원되지 않는 클래스 이름 접두사(패키지 이름)는 외부 코드를 어쨌든 재사용할 수 없을 때 사소한 문제일 뿐입니다.
따라서 MQL에서 바로 OOP를 배우기 시작하는 것은 권장하지 않습니다. 코더는 작업을 수행하는 데 필요한 것이 무엇인지 알아야 합니다.
"if...then...else..." 문은 작업을 수행해야 합니다.
어 어서 ;) 별로 ;) 네이티브가 뭔가 이상하게 일을 할 수 있다면, 그 포인터가 있지만 MQL에는 제한이 있습니다. 그렇다면 ... 코드는 터무니없게 될 것입니다. 그리고 이 스레드의 질문에 대한 답변으로 터무니없는 코드를 수락하면 전혀 쓸모없게 됩니다. 자, 네, 한 번만 제 자존심을 위해 ;)
죄송하지만 아니오라고 대답하지 않겠습니다... 코드가 목표에 도달했는지 여부 중 하나입니다. 사양에 따라 작동한다면 터무니없는 것은 없습니다.
질문은 "절차상 할 수 없는 OOP가 할 수 있는 것"입니까? Stanislav 는 OOP가 절차와 동일하지만 "더 짧고 좋은" 방식으로 수행할 수 있다고 말했습니다. 나는 동의하는 경향이 있습니다 (짧은 아이디어를 제외하고는 중요 하지 않습니다).
프로그래밍 GUI는 프로그래머로서 내가 가장 많이 한 일이었습니다. if then else에 의해 여러 방향으로 통신해야 하는 완전한 GUI를 코딩하는 것은 불가능합니다. 코드를 읽을 수 없게 되고 결국에는 너무 느려진다는 진술이 많이 필요할 것입니다. 이는 다음을 의미합니다. 목표에 도달하지 못했습니다. 결과를 볼 때까지 클릭할 때마다 커피 한 잔을 강제로 마시고 싶지 않기 때문입니다.
CPU가 OOP에 대해 아무것도 모르는 상황 때문에 포인터와 복잡한 배열을 사용하지 않고도 모든 것을 코딩할 수 있습니다. 그러나 그것은 터무니없다. 또한 10,000명을 고용하여 필름에 내 스크린 콘텐츠를 실시간으로 그리고 벽에 라이트 프로젝터 로 순차적으로 비출 수 있습니다. 이것도 목표달성인가요?
객체 지향 프로그래밍과 절차적 프로그래밍의 장점에 대한 유용한 정보를 수집하기 위해 이 주제를 시작합니다.
또한 이 주제는 mql4 및 mql5가 동일한 OOP 언어를 제공하므로 언어 독립적입니다(현재 mql4에서 아직 사용할 수 없는 일부 새로운 고급 기능 제외).
나는 OOP의 지지자와 반대자 사이의 "전쟁"을 원하지 않으므로 이 주제는 밀접하게 조정될 것입니다. 시간을 낭비하지 마십시오.
또한 높은 이론이나 추상적인 개념이 아닌 귀하의 요점을 설명하는 예제와 코드를 제공하십시오.
편집: 이 주제는 언어 독립적이지만 우리는 여전히 거래 및 mql4/mql5에 대해 이야기하고 있으므로 "전쟁 게임" 또는 "사과와 오렌지" 예제는 사용하지 마십시오.