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

 
Реter Konow :

그 경우에, 나는 당신에게 새 프리즘을 물체에 "던졌습니다". 상태 개체는 클래스로 설명되지 않지만 메모리에 물리적 개체가 있습니다. 클래스는 Object 에 대한 설명입니다 . 다른 것들이 있을 수 있습니다. 그것은 오히려 객체의 복합체입니다. 그러나 개체 자체는 명명된 개체입니다.

분자는 물체입니다. 우주는 하나의 객체입니다. 둘 다 객체 세트로 구성됩니다. 따라서 클래스는 개체에 대한 설명입니다.
당신 자신이 불필요한 엔티티를 생성하기 시작했습니다 :)
 
Artyom Trishkin :
...
저는 철학자가 아닙니다. 나는 당신의 생각을 이해하기 어렵습니다. 저에게는 훨씬 쉽습니다.

걱정하지 마세요. 발전하고 있습니다.

이벤트 체인을 살펴보십시오. 여기에는 중요한 시스템 매개 변수의 어셈블리와 그 안에 시스템에 중요한 값이 포함되어 있습니다.

상태 체인은 동일합니다. 거기에만 고정된 값이 있으며, 이 값의 불변성은 시스템에 중요합니다.

물론 이벤트에는 핸들러가 있습니다. Object에는 핸들러가 있어야 합니다. 이것에서 당신은 절대적으로 옳습니다.

 
Artyom Trishkin :
분자는 물체입니다. 우주는 하나의 객체입니다. 둘 다 객체 세트로 구성됩니다. 따라서 클래스는 개체에 대한 설명입니다.

매개변수는 미리 결정된 값 선택의 이산 현상입니다. 그는 또한 개체입니다.

값 선택은 Parameter-Object의 속성에 범위 또는 옵션 집합으로 저장됩니다. 값의 유형과 핸들러도 여기에 저장됩니다.

 
Реter Konow :

동시에 본질은 반드시 나눌 수 없는 것은 아닙니다. 다른 엔터티로 구성될 수 있으며 하나의 개체가 될 수 있습니다. 예를 들어 - 개체 시스템. 그것은 많은 엔티티를 가지고 있으며 각각은 객체입니다.

또 다른 흥미로운 점은 State Object가 Event Object와 구조적으로 유사하다는 것입니다.

상태란 무엇입니까? 이것은 고정된 중요 불변에서 시스템의 중요한 매개변수의 복합체입니다. 시스템 매개변수의 중요한 연속성 - 상태. 그리고 이벤트는 시스템 매개변수의 중요한 변경입니다. 그들은 구조적으로 유사합니다.

1. 상태 - 살아 있습니다.
2. 이벤트 - 벽돌깨기.
3. 조건 - 시체.
 
Artyom Trishkin :
1. 상태 - 살아 있습니다.
2. 이벤트 - 벽돌깨기.
3. 조건 - 시체.
발생하기도 합니다...)
 
Реter Konow :

걱정하지 마세요. 발전하고 있습니다.

이벤트 체인을 살펴보십시오. 여기에는 중요한 시스템 매개 변수의 어셈블리와 그 안에 시스템에 중요한 값이 포함되어 있습니다.

상태 체인은 동일합니다. 거기에만 고정된 값이 있으며, 이 값의 불변성은 시스템에 중요합니다.

물론 이벤트에는 핸들러가 있습니다. Object에는 핸들러가 있어야 합니다. 이것에서 당신은 절대적으로 옳습니다.

개체에는 매개변수를 외부 환경으로 전송하는 방법인 뉴런이 있어야 합니다. 그러나 매개변수 변경 핸들러가 필요하지 않습니다. 다른 개체에 있을 수 있습니다.
 

그런데 왜 Parameter Object에 핸들러가 필요하다고 생각하시나요? 개념적 무결성과 목적을 유지하기 위해.

이해합니다. 매개변수는 두 개의 드라이브로 연결되어 있습니다.

1. 값을 취합니다.

2. 값을 전달합니다.

핸들러는 매개변수가 속성에 지정된 목적에 따라 기능을 수행하는지 확인합니다. 핸들러는 미리 정의된 선택 내에 값을 저장하므로 시스템을 보호합니다.

 
Artyom Trishkin :
개체에는 매개변수를 외부 환경으로 전송하는 방법인 뉴런이 있어야 합니다. 그러나 매개변수 변경 핸들러가 필요하지 않습니다. 다른 개체에 있을 수 있습니다.

매개변수 개체는 두 개의 드라이브를 통해 시스템에 연결됩니다. 첫 번째에 따르면 외부에서 값을 받고 두 번째에 따르면 전달합니다. 매개변수의 속성은 해당 체인에 기록되며 핸들러는 실제로 외부에 있을 수 있습니다. 그러나 이에 대한 참조는 매개변수 개체 체인에 있어야 합니다.

 

시스템은 "환경"과 불가분의 관계에 있기 때문에 자체적으로 고려될 수 없습니다.

시스템 - 개념적으로 환경에서 마음의 눈으로 격리되고 개체에 배치되는 상호 작용하는 매개 변수의 별도 복합체입니다. 소외된 매개변수 그룹을 독립된 시스템으로 보는 것은 환경과의 효과적인 공생을 유지하는 것을 볼 수 있게 해줍니다.

환경에는 3가지 상태가 있습니다.

1. 혼돈, - 매개변수 는 서로 부조화 상태에 있는 동안 시스템을 형성하기 위해 "추구하고 노력"합니다(원우주에서와 같이).

2. 질서 - 시스템으로 조직되고 혼돈으로부터 분리된 매개변수 세트. 이것은 시스템과 그 질서에 종속되는 주변 혼돈의 변화를 의미합니다. 시스템은 혼돈에 질서를 "부과"하고 내부를 확장합니다.

자기 복제 및 "승리".

3. 생태계 - 효과적인 공생을 달성하고 외부 변화에 대한 저항의 표현을 통해 무결성을 유지하는 시스템의 복합체.


시장은 외부 환경이다.

Expert Advisor - 시장과 효과적인 공생을 시도하는 시스템. 공생의 효과는 상담자가 기대하는 혼돈 속에서 패턴을 찾을 때 가능합니다.

EA는 매개변수를 최적화하고 전술을 변경하여 시장 패턴에 "연결"하려고 합니다. 그는 행동 모델을 구축하여 시장 자원의 일부를 "기대"하지만 대부분의 경우 자신의 자원이 시장에 있고 행동 모델이 깨졌습니다. 행동 모델이 자체 행동 모델을 가진 다른 많은 시스템이 있는 거대한 환경의 일반화된 파생 매개변수를 기반으로 한다는 점을 고려하면 이는 놀라운 일이 아닙니다.



매체로서의 시장

  1. 또는 절대적으로 혼란스럽고 열쇠를 줍는 것은 불가능합니다. ( 난수 생성기를 기반으로 하는 경우).
  2. 또는 - 고문의 행동 모델을 일반화하고 그들 사이에 자원을 재분배하는 복잡한 시스템.
  3. 또는 - 고문의 자원을 "공급"하고 재분배를 시뮬레이션하는 시스템.

인기있는 통계 95/5를 고려하십시오. 그것은 어디에서 왔으며 시장의 어떤 단계를 거쳤습니까?

  1. 제로 단계 - 시장은 혼란스럽고 형성됩니다. 자원의 급격한 농축과 완전한 손실에 대한 통계는 시장 거래 개념의 불안정성과 미성숙을 보여줍니다. 규칙은 모호하고 행동은 종종 "짐승"입니다.
  2. 첫 번째 단계 - 시장은 시스템 행동 모델을 일반화하고 자원을 재분배하기 시작합니다. 공명에 대한 열망을 감안할 때 재분배는 70/30% 또는 60/40% 범위에 있었습니다. 시스템은 다른 시스템과 결합하여 공통 방향으로 강력한 시장 움직임을 유발하는 행동 패턴을 빠르게 찾았습니다. 결국 복잡하고 일관성이 없는 알고리즘보다 단순한 통합 모델을 만드는 것이 훨씬 쉽습니다. 그리고 통합은 자원을 통합하고 통합되지 않은 반대쪽에서 수익을 얻기 위해 시장을 "밀어내는" 것입니다. 이 단계는 지난 세기에 지났습니다.
  3. 두 번째 단계 - 시장은 자발적이지만 자연스럽게 특정 시스템에서 막대한 자원을 "생성"하고 특정 시스템에서 특정 행동 패턴을 개발하고 다른 모델이 선택하는 것과 관계없이 자원을 끌어옵니다. 이러한 시스템에 있는 수많은 상대방으로 인해 시장에 대한 가시성과 시장을 이동할 수 있는 능력이 훨씬 더 뛰어납니다. 그들의 관심의 결과, 그들은 필연적으로 다른 사람들의 자원을 고갈시킵니다. 마켓의 현재 단계입니다.
  4. 세 번째 단계 - 시장에서 막대한 자원의 집중을 관리하는 시스템은 모든 작은 시스템의 자원을 무의식적으로 흡수하고 반복적으로 분해하고 행동 패턴의 선택을 좁히고 결과적으로 자원을 찾는 것을 중단합니다. 자기보존을 위한 시장. 마켓의 마지막 단계입니다.
추신 질문은 "다음은 무엇입니까? ..."입니다.


추신

Magic Grail은 다른 모든 시스템에서 리소스를 끌어와 항상 패배자로 남겨두는 이상적인 시스템 동작 모델입니다. 환상에서 태어난 추상화.

Документация по MQL5: Математические функции / MathSrand
Документация по MQL5: Математические функции / MathSrand
  • www.mql5.com
Функция MathRand() предназначена для генерации последовательности псевдослучайных чисел. Вызов MathSrand() с определенным инициализирующим числом позволяет получать всегда одну и ту же последовательность псевдослучайных чисел. Для гарантированного получения неповторяющейся последовательности используйте вызов MathSrand(GetTickCount()), так как...
 

OOP에서 "철" 클래스 프레임워크에 의해 바인딩된 여러 개체는 다른 수의 속성을 가질 수 있습니다.

하나의 개체에 대해 프로그램 작동 중에 속성 수가 변경될 수 있습니다.

개체 간의 연결은 설정 및 해제될 수 있습니다.

OOP에서 객체에 대한 메모리는 필요에 따라 할당되고 객체가 더 이상 필요하지 않으면 해제됩니다.


배열은 항상 고정되어 있습니다. 배열에 지정된 것보다 적은 수의 개체가 있으면 누락된 개체에 대한 메모리가 낭비됩니다. 그리고 더 이상 있을 수 없습니다.

어떤 이유로 당신은 이 질문을 피합니다. 비록 이것이 당신이 가장 먼저 처리했어야 할 일이지만.