OOP 전문가를 위한 질문입니다. - 페이지 50

[Реter Konow]

Vladimir Simakov :
쓰레기. 큰 술. 읽어보니 이해가 잘 안되네요. Peter, 이해하십시오. 프로그래밍 언어가 있고 그 중 많은 언어가 있으며 작성자가 특정 메모리 관리 메커니즘을 통합했지만 OOP는 옵션 중 하나일 뿐입니다. 그들은 정말 다르고 실제로 장단점이 있습니다. 따라서 AI를 원하면 I ENVY라는 것이 좋습니다. 왜냐하면 나 자신이 결코 결정하지 않기 때문입니다. 하지만 여기에서 구현할 필요는 없습니다. 다른 응용 언어와 마찬가지로 mql은 롤링되지 않습니다. 여기서 C++가 없어도 순수한 C가 보입니다. 그래서, 당신은 다른 포럼으로 가거나 "글로벌" 트롤입니다)))).

이해했습니다. 고맙습니다.

[Реter Konow]

Yury Kulikov :

그러나 약속된 유리는 어떻습니까? " 근본적으로 새로운 수준의 응용 프로그램입니다. 이전에는 MQL 프로그래머가 도달할 수 없었던 수준 "입니다.

우리는 더 이상 기다리지 않습니까?

아무도 구형 오리너구리를 필요로하지 않습니다.))

알고리즘 거래 "집단 학살"의 평범한 " Grails "는 MQL의 모든 훌륭한 사업입니다. 그들의 의미를 파괴했습니다.

끝까지 버텼습니다.

[Реter Konow]

Aliaksandr Hryshyn :
AI의 구현을 기다리고 있습니다 :).

확인.))

[Реter Konow]

이 지점을 떠나고 싶지 않으므로 최근의 성공 사례를 보고하겠습니다.

핵심에 있는 객체 표현과 클래스에 있는 객체에 대한 표준 설명의 "하이브리드"인 OOP의 새로운 개념은 일반 OOP보다 더 "객관적"이 되었습니다. 설명하겠습니다:

이제 모든 엔터티는 개체입니다. 즉:

• 매개변수 개체(속성)
• 상태 객체
• 프로세스 객체
• 이벤트 개체
• 매개변수 바인딩 객체
• 매개변수 처리기 개체
• 값 필터 개체
• 값 변환기 개체
• 객체 시스템
  

이것은 작동하는 시스템을 구성하는 기본 개체의 전체 목록이 아닙니다.

결론은 이러한 각 개체가 실제 개체라는 것입니다. 즉, 시스템 내에 속성과 연결이 있습니다.

예를 들어 매개변수 개체 - 값 유형 및 변경 경계를 포함하는 속성 집합이 있습니다. 또한 Parameter Object는 자체 핸들러를 가리킬 수 있습니다.

또한 - Object-state는 사전 설정된 값이 있는 시스템 또는 환경 매개변수의 집합입니다.

기타, - 이벤트 개체, - 시스템 또는 환경에 대한 모든 중요한 변경. 특정 값이 있는 매개변수의 집합으로 special로 확인됩니다. 매니저. 이벤트는 다양한 시스템 개체에 대한 트리거 기능을 수행합니다.

Parameter Objects는 그들 사이에 값을 전달하는 Link Objects에 의해 연결됩니다. 예를 들어: 매개변수 A는 매개변수 B에 값을 전달하거나 그 반대의 경우도 마찬가지입니다. 또는 양쪽. 이것은 Parameter Link Object에 작성됩니다. 값 필터 개체 또는 값 변환기 개체는 값을 전달하는 데 방해가 될 수 있습니다.

내 개념의 각 개체에는 반드시 템플릿(원래 형식)과 n번째 인스턴스가 있습니다.

결론은 나열된 모든 개체가 모든 복잡성의 모든 시스템의 보편적인 빌딩 블록이라는 것입니다. 그것들은 그렇게 많지 않으며, 그것들로부터 구축할 수 있는 시스템에 대한 무한한 수의 옵션이 있습니다.

현재 나는 여행의 시작 단계에 있다. 아직 이해해야 할 것이 많이 있습니다.

[[삭제]]

Реter Konow :

이 지점을 떠나고 싶지 않으므로 최근의 성공 사례를 보고하겠습니다.

핵심에 있는 객체 표현과 클래스에 있는 객체에 대한 표준 설명의 "하이브리드"인 OOP의 새로운 개념은 일반 OOP보다 더 "객관적"이 되었습니다. 설명하겠습니다:

이제 모든 엔터티는 개체입니다. 즉:

• 매개변수 개체(속성)
• 상태 객체
• 프로세스 객체
• 이벤트 개체
• 매개변수 바인딩 객체
• 매개변수 처리기 개체
• 값 필터 개체
• 값 변환기 개체
• 객체 시스템
  

이것은 작동하는 시스템을 구성하는 기본 개체의 전체 목록이 아닙니다.

결론은 이러한 각 개체가 실제 개체라는 것입니다. 즉, 시스템 내에 속성과 연결이 있습니다.

예를 들어 매개변수 개체 - 값 유형 및 변경 경계를 포함하는 속성 집합이 있습니다. 또한 Parameter Object는 자체 핸들러를 가리킬 수 있습니다.

또한 - Object-state는 사전 설정된 값이 있는 시스템 또는 환경 매개변수의 집합입니다.

기타, - 이벤트 개체, - 시스템 또는 환경에 대한 모든 중요한 변경. 특정 값이 있는 매개변수의 집합으로 special로 확인됩니다. 매니저. 이벤트는 다양한 시스템 개체에 대한 트리거 기능을 수행합니다.

Parameter Objects는 그들 사이에 값을 전달하는 Link Objects에 의해 연결됩니다. 예를 들어: 매개변수 A는 매개변수 B에 값을 전달하거나 그 반대의 경우도 마찬가지입니다. 또는 양쪽. 이것은 Parameter Link Object에 작성됩니다. 값 필터 개체 또는 값 변환기 개체는 값을 전달하는 데 방해가 될 수 있습니다.

내 개념의 각 개체에는 반드시 템플릿(원래 형식)과 n번째 인스턴스가 있습니다.

결론은 나열된 모든 개체가 모든 복잡성의 모든 시스템의 보편적인 빌딩 블록이라는 것입니다. 그것들은 그렇게 많지 않으며, 그것들로부터 구축할 수 있는 시스템에 대한 무한한 수의 옵션이 있습니다.

현재 나는 여행의 시작 단계에 있다. 아직 이해해야 할 것이 많이 있습니다.

귀하의 성공에 만족합니다. 그래서, 당신은보고 언젠가 바퀴를 발명하게 될 것입니다.

[Реter Konow]

Koldun Zloy :

귀하의 성공에 만족합니다. 그래서, 당신은보고 언젠가 바퀴를 발명하게 될 것입니다.

이해해 주셔서 감사합니다. 그러므로 나는 여기에 조용히 내 생각을 진술합니다. 그래도 가끔은 여기에서 더 이해해 주는 사람이 있기를 바랍니다.

[Реter Konow]

나는 새로운 OOP 개념의 프리즘을 통해 일반적인 GUI 컨트롤 - 버튼 을 설명하려고 노력할 것입니다. 나는 이 객체 시스템의 분석에 내 자신의 개념만을 사용합니다.

그래서 우리는 다음을 가지고 있습니다:

• 값이 bool(값 1/0)인 유형 속성이 있는 매개변수 객체. 커널에 씁니다.
• 매개변수 래퍼 객체(버튼 자체)는 직사각형 그래픽 레이블입니다. 속성 - x, y, x_size, y_size, 색상. 우리는 커널에 씁니다.
• 2 셸 상태 개체. 매개변수의 두 어셈블리(색상, x, y, 규정된 값 포함).
• 커서 개체입니다. x,y, 커서 및 왼쪽(1/0) 및 오른쪽(1/0) 버튼의 상태인 4가지 매개변수의 집합입니다.
  
• 버튼 래퍼 이벤트 객체. 커서의 x,y 매개변수와 버튼 쉘 공간 매개변수(x,y, x+length, y+height)의 어셈블리.
• 커서와 버튼의 위치, 마우스 왼쪽 버튼의 상태를 확인하는 이벤트 핸들러 객체.
• 클릭 이벤트에서 셸의 상태를 변경하기 위한 개체 핸들러입니다.
• 버튼 매개변수의 값을 변경하기 위한 객체 핸들러입니다(버튼으로 제어되는 주요 매개변수를 의미함 - (1/0)).
• 버튼 매개변수를 외부 시스템과 연결하는 개체입니다.

다음은 좀 더 복잡한 시스템에서 작동 하는 간단한 버튼 시스템 개체를 만드는 데 필요한 대략적인 개체 집합입니다. 이 모든 것은 이러한 개체의 템플릿에서 구축할 수 있으며 커널의 인스턴스에서 작동할 수 있습니다.

[Dmitry Fedoseev]

... 버킷의 인스턴스에 대해 작업합니다. :)

버킷에 무엇이든, 특히 특정 객체와 관련된 것을 기록해야 하는 이유는 무엇입니까? 객체 자체에는 자신에 대한 정보가 저장되지만 버킷에는 객체에 대한 포인터만 포함됩니다.

[Реter Konow]

Dmitry Fedoseev :

... 버킷의 인스턴스에 대해 작업합니다. :)

버킷에 무엇이든, 특히 특정 객체와 관련된 것을 기록해야 하는 이유는 무엇입니까? 객체 자체에는 자신에 대한 정보가 저장되지만 버킷에는 객체에 대한 포인터만 포함됩니다.

아르템에게 물어보세요. 나는 그가 내가 쓰는 것을 누구보다 잘 이해하고 있다고 생각합니다.

그건 그렇고, 처음에는 핸들러가있는 객체 속성에 대한 아이디어가 그에게 속했습니다. 나는 그것을 개발하고 복잡하게 만들었다. 이제 모든 것이 객체이고 핸들러도 마찬가지입니다. 객체로부터 시스템을 구축할 때 객체를 연결하는 특정 순서가 있다는 것입니다.

[Aliaksandr Hryshyn]

" OOP의 새로운 개념 " - 목표가 명확하지 않습니다. 왜 이런 짓을하는?