OOP의 바로 그 개념은 쓰지 않는 것을 의미합니다 - 메소드의 구현을 알 필요가 없습니다(귀하의 예에서 return(SymbolSelect(m_name,select)))
이 줄 대신 다음을 상상해보십시오.
많은 요청, 다양한 확인 등을 수행해야 합니다. - 자신의 라이브러리를 작성하고 자료 자체를 연구하는 데 시간이 걸립니다.
귀하의 작업은 클래스 형태의 기성 솔루션의 한 가지 방법을 사용하는 것으로 끝납니다. 클래스(객체)의 인스턴스를 만들고 기성품 Select(const bool select) 방법을 사용합니다.
이러한 작업이 더 이상 수행되지 않아야 하는 경우 여유 메모리 = 개체를 파괴합니다.
시장 시계에서 기호를 활성화/비활성화하는 버튼을 표시하는 것으로 작업을 줄이십시오 ---> 자신의 클래스를 만들고 기성품 버튼 클래스와 기성품 CSymbolInfo 클래스를 캡슐화합니다. 과제가 해결되다
OOP 패러다임은 클래스로 무엇을 할 수 있는지에 대한 일반적인 정보만 제공합니다. - CSymbolInfo를 캡슐화하고 싶지 않다면 - 글쎄요, 클래스를 가져오세요.
나는 믿는다, 나는 이해하지 못하고 받아들이지 않는다. 그 때 이 모든 소명 없이는 할 수 없는 특정한 과업이 있을 때 "마음의 깨달음"과 이해가 올 것입니다. 그래서 지금까지 내 관점에서 유행하는 종소리와 휘파람 이 항상 정당화되는 것은 아닙니다. 항상이 아님은 절대를 의미하지 않습니다. 나는 기꺼이 Ctrade 클래스를 사용하지만 위에 표시된 것과 같은 것을 수락하지 않습니다. 문서에서 SymbolSelect 기능에 대한 설명을 찾는 것이 어렵지 않다면, 안전보장이사회에서 설명을 찾는 것은 이미 확실히 어려운 일입니다.
이고르 마카누 :
추신 : "손가락에"라면 OOP의 본질은구현을 알지 못한 채 작업에 대한 빠른 솔루션 입니다.
이 경우 구현을 아는 대신 원하는 메서드를 호출하는 방법, 찾을 위치 등을 알아야 합니다. 이게 뭐야? 프로그래밍 언어의 일종의 언어?
하나의 프로젝트에 개체의 여러 인스턴스가 필요한지 이해할 수 있습니다. 그러나 지금까지는 앞에서 언급한 Artyom 데모를 제외하고는 그러한 구현을 본 적이 없습니다. 그렇다면 이것이 더 좋고, 더 쉽고, 더 간단하다는 것은 분명하지만, 나는 무익함, 작업 부족으로 인해 정확한 이해에 도달하지 못했습니다. mql5 언어 기능을 한 번만 사용하기 위해 개체를 래핑하는 것은 의미가 없습니다. 이것이 내가 주장하는 방법입니다.
클래스는 객체에 대한 설명입니다. 좋은. 개체 및 해당 기능의 속성을 포함합니다. 확인. 이 모든 것이 명령, 공개 또는 보호됩니다.
그런 다음 OBJECT ITSELF가 무대 뒤에 있습니다. 그것은 클래스의 컨텍스트에 있습니다. 이름과 설명의 맥락에서. 즉, OOP에서 Object는 속성의 명명된 복합체(속성뿐만 아니라 기능적 요소 - 메서드)이지만 내 것보다 더 정렬되고 캡슐화됩니다. (그렇게 하면 더 명확해집니다.)
Peter, 마지막으로 클래스에 대해 Google에서 메모리 할당 컨텍스트에서 클래스가 무엇인지, 메소드 호출, 즉 컴파일러가 이 모든 것을 변환하는 것입니다. 대부분의 질문은 그 후에 저절로 사라집니다.
MFC를 처음 사용하고 CDialog를 기반으로 Windows 응용 프로그램을 만들고 모든 종류의 개체를 만들고 얼마나 쉽게 관리되는지 확인하는 것이 좋습니다.
그 후, 당신은 당신의 아이디어를 버릴 것입니다. 안타깝게도.
글쎄, 그럴 가능성은 없다. 사실 나는 내 접근 방식과 OOP 사이에 개념적 차이점이 거의 없다는 것을 발견했습니다. 내 접근 방식도 객체 지향입니다. 객체는 커널에 캡슐화되어 있으며 매우 구체적인 표현을 가지고 있습니다. 그것들은 포인터로 상호 연결되어 요소, 창 등의 복합체를 형성합니다. 그래픽을 넘어 더 다양한 형태를 포함하는 다른 형태의 코어를 만들면 OOP보다 나쁘지 않습니다.
접근 방식의 차이점은 코드 작성 스타일, 구문 및 기능 배포 방법에 있습니다. 내 접근 방식에서 기능은 OOP에서 단편화로 통합되는 경향이 있습니다. 동시에 기능의 단일화는 시스템의 효율성을 높이고 구문의 적은 양을 보장하며 기능의 단편화는 코드의 이식성을 용이하게 합니다. 모듈을 연결할 수 있습니다. 일반적으로 이러한 차이점이 있습니다.
물론 내 접근 방식은 아직 그렇게 광범위한 "객관성"을 갖고 있지 않습니다. 그러나 나는 그것을 고칠 방법을 이미 가지고 있습니다. 커널은 한 가지 유형이며 이는 내부에 저장된 속성을 제한하지만 커널이 단일 행렬일 필요는 없습니다. 그것은 핵의 복합체 일 수 있습니다. 주요 이점은 긴 설명, 추가 구문 및 기능 분할이 필요하지 않은 객체의 디지털 표현입니다.
우리는 "클래스", "객체", "속성", "캡슐화", "다형성", "상속"의 개념을 남겨두고 구문 및 기술 용어에서 추상화합니다. 그 개념의 철학적 "근본"을 설명하겠습니다.
현실은 "공간", "시간", "물질"(감각 기관이 작동하는 방식)의 프리즘을 통해 의식에 의해 인식되며 "대상"은 지속적인 상호 작용의 개별 결과입니다.
다양한 형태의 상호작용은 무의식적 주체에 의해 특정 "프레임워크"에 "이식"되는 다양한 대상을 생성합니다. 이 프레임은 분기되는 계단식 구조를 가지고 있으며 "원형" 중 하나인 무의식에 "내재"되어 있습니다. 프레임워크는 구조 전체에 분산되는 점점 더 많은 새로운 객체(관련 정보)를 사용합니다. 여기서 OOP의 개념이 나옵니다. 이것은 무의식의 "알고리즘"을 모방한 대상의 의식적인 배포 및 바인딩입니다. 자신의 사고 방식을 마스터한 대상자는 두뇌의 "추적지"인 컴퓨터인 메커니즘에서 자신의 작업을 모델링할 수 있습니다. 컴퓨터는 뇌의 비참한 패러디에 불과하지만 사람 자신은 객관적인 세계의 그림자 만 인식합니다. 계단식, 분기형 원형은 우리의 기억 속에 있는 일반적으로 객체, 속성, 프로세스 및 모든 정보의 분포에 대한 "패턴"입니다. 이것은 현실의 인식을 단순화하고 주변 세계의 모델을 구조화하기 위한 생물학적 도구입니다. 이것은 자연적으로 우리에게 주어진 것입니다. 자신의 "자연적"(즉, 무의식적) 정보 처리 메커니즘에 대한 인식 은 OOP를 사용하는 데 필요한 자기 인식 수준입니다.
암묵적, 생물학적, "나무" 원형을 "인공적" 응용의 맥락에서 생각하여 암기, 학습 및 인식을 단순화합니다. OOP에서 우리는 속성과 값을 설정하는 클래스에 설명을 캡슐화하여 개체를 "생성"합니다. 객체의 관계는 분류에 반영되며 전역에서 전용으로 속성 및 메서드의 상속을 통해 구현됩니다. 실제로는 다음과 같이 보입니다. 모든 개인 개체는 하나의 개체일 뿐이므로 단순 개체의 모든 속성과 고유한 개인 속성을 가집니다. 그것에서 파생된 객체는 개인 속성을 일반 속성으로 가지지만 고유한 개인 속성을 갖습니다. 또한 체인은 무한정 갈 수 있습니다. 객체 메서드도 마찬가지입니다. 이 방법은 동작, 상호 작용, 프로세스, 상태 변경을 반영합니다. 개체 메서드는 속성과 마찬가지로 공개에서 비공개로 정렬됩니다. 특정 일반 프로세스가 있는 경우 각각의 개별 형태는 고유한 속성과 고유한 속성을 갖습니다. 그리고 이것은 다형성입니다. 즉, 오버로딩과 달리 다형성은 기본 메커니즘을 유지하면서 기본 기능의 다른 비공개 구현을 제공합니다. 이것은 "기능적" 상속입니다.
우리가 볼 수 있듯이 OOP의 "나무 모양"은 어디에나 있습니다. 어떤 계획을 생각해내더라도 여전히 "나무"를 얻을 수 있습니다.) 그러나 이것은 맞습니다. 왜냐하면 우리는 정보로 작업할 때 우리 자신의 무의식적인 패턴을 단순히 복사하기 때문입니다.
설명하겠습니다. 결론은 OOP가 우리의 기억에 있는 무의식적인 정보 분포를 복제한다는 것입니다. 정보는 계단식으로 "분해"되고 "나무 모양"입니다. 이것은 무의식의 원형(숨겨진 메커니즘) 때문입니다. 사람들은 이 메커니즘을 "찾아서" 프로그래밍에 성공적으로 적용하기 시작했습니다. OOP는 우리의 무의식과 같은 방식으로 상속 체인을 따라 공통 속성과 기능의 전달을 구현합니다.
우리의 의식과 무의식의 작동 원리를 더 잘 이해함으로써 우리는 컴퓨터에서 그들의 작동 메커니즘을 재현할 수 있을 것입니다. 나는 기술적인 세부 사항에서 뒤로 물러나 개념의 뿌리를 살펴보았다.
OOP의 바로 그 개념은 쓰지 않는 것을 의미합니다 - 메소드의 구현을 알 필요가 없습니다(귀하의 예에서 return(SymbolSelect(m_name,select)))
이 줄 대신 다음을 상상해보십시오.
많은 요청, 다양한 확인 등을 수행해야 합니다. - 자신의 라이브러리를 작성하고 자료 자체를 연구하는 데 시간이 걸립니다.
귀하의 작업은 클래스 형태의 기성 솔루션의 한 가지 방법을 사용하는 것으로 끝납니다. 클래스(객체)의 인스턴스를 만들고 기성품 Select(const bool select) 방법을 사용합니다.
이러한 작업이 더 이상 수행되지 않아야 하는 경우 여유 메모리 = 개체를 파괴합니다.
시장 시계에서 기호를 활성화/비활성화하는 버튼을 표시하는 것으로 작업을 줄이십시오 ---> 자신의 클래스를 만들고 기성품 버튼 클래스와 기성품 CSymbolInfo 클래스를 캡슐화합니다. 과제가 해결되다
OOP 패러다임은 클래스로 무엇을 할 수 있는지에 대한 일반적인 정보만 제공합니다. - CSymbolInfo를 캡슐화하고 싶지 않다면 - 글쎄요, 클래스를 가져오세요.
나는 믿는다, 나는 이해하지 못하고 받아들이지 않는다. 그 때 이 모든 소명 없이는 할 수 없는 특정한 과업이 있을 때 "마음의 깨달음"과 이해가 올 것입니다. 그래서 지금까지 내 관점에서 유행하는 종소리와 휘파람 이 항상 정당화되는 것은 아닙니다. 항상이 아님은 절대를 의미하지 않습니다. 나는 기꺼이 Ctrade 클래스를 사용하지만 위에 표시된 것과 같은 것을 수락하지 않습니다. 문서에서 SymbolSelect 기능에 대한 설명을 찾는 것이 어렵지 않다면, 안전보장이사회에서 설명을 찾는 것은 이미 확실히 어려운 일입니다.
추신 : "손가락에"라면 OOP의 본질은 구현을 알지 못한 채 작업에 대한 빠른 솔루션 입니다.
이 경우 구현을 아는 대신 원하는 메서드를 호출하는 방법, 찾을 위치 등을 알아야 합니다. 이게 뭐야? 프로그래밍 언어의 일종의 언어?
하나의 프로젝트에 개체의 여러 인스턴스가 필요한지 이해할 수 있습니다. 그러나 지금까지는 앞에서 언급한 Artyom 데모를 제외하고는 그러한 구현을 본 적이 없습니다. 그렇다면 이것이 더 좋고, 더 쉽고, 더 간단하다는 것은 분명하지만, 나는 무익함, 작업 부족으로 인해 정확한 이해에 도달하지 못했습니다. mql5 언어 기능을 한 번만 사용하기 위해 개체를 래핑하는 것은 의미가 없습니다. 이것이 내가 주장하는 방법입니다.
이 경우 구현을 아는 대신 원하는 메서드를 호출하는 방법, 찾을 위치 등을 알아야 합니다. 이게 뭐야? 프로그래밍 언어의 일종의 언어?
문서를 보세요. 공개적으로 게시되는 모든 것은 매뉴얼, 말하자면 윤리를 동반합니다.
스타일이 아니라 패러다임입니다! - 컨셉, 매너, 아무도 그렇게 쓰라고 강요하지 않지만, 어째서인지 가장 보편적인 스타일
OOP의 본질은 구현을 모른 채 문제에 대한 빠른 솔루션입니다.
데이터가 있는 구조를 전달하여 함수를 호출할 수 있으며 이 함수의 구현을 몰라도 똑같이 빠른 솔루션을 얻을 수 있습니다.
예, 하지만 방법은 이것으로 제한됩니다. OOP에서는 상속할 수도 있습니다. 구현을 모르고 작업에 추가할 수도 있습니다. 가장 먼저 떠오르는 것은 모서리가 둥근 버튼입니다. 예의 네트워크
추신: 글쎄요, 생성자를 통해 객체를 배포하는 논리는 상당히 편리합니다.
클래스는 객체에 대한 설명입니다. 좋은. 개체 및 해당 기능의 속성을 포함합니다. 확인. 이 모든 것이 명령, 공개 또는 보호됩니다.
그런 다음 OBJECT ITSELF가 무대 뒤에 있습니다. 그것은 클래스의 컨텍스트에 있습니다. 이름과 설명의 맥락에서. 즉, OOP에서 Object는 속성의 명명된 복합체(속성뿐만 아니라 기능적 요소 - 메서드)이지만 내 것보다 더 정렬되고 캡슐화됩니다. (그렇게 하면 더 명확해집니다.)
모든 것을 이해하려면 책을 읽어야 합니다. 21일 이내에 최소 VC++
MFC를 처음 사용하고 CDialog를 기반으로 Windows 응용 프로그램을 만들고 모든 종류의 개체를 만들고 얼마나 쉽게 관리되는지 확인하는 것이 좋습니다.
그 후, 당신은 당신의 아이디어를 버릴 것입니다. 안타깝게도.
글쎄, 그럴 가능성은 없다. 사실 나는 내 접근 방식과 OOP 사이에 개념적 차이점이 거의 없다는 것을 발견했습니다. 내 접근 방식도 객체 지향입니다. 객체는 커널에 캡슐화되어 있으며 매우 구체적인 표현을 가지고 있습니다. 그것들은 포인터로 상호 연결되어 요소, 창 등의 복합체를 형성합니다. 그래픽을 넘어 더 다양한 형태를 포함하는 다른 형태의 코어를 만들면 OOP보다 나쁘지 않습니다.
접근 방식의 차이점은 코드 작성 스타일, 구문 및 기능 배포 방법에 있습니다. 내 접근 방식에서 기능은 OOP에서 단편화로 통합되는 경향이 있습니다. 동시에 기능의 단일화는 시스템의 효율성을 높이고 구문의 적은 양을 보장하며 기능의 단편화는 코드의 이식성을 용이하게 합니다. 모듈을 연결할 수 있습니다. 일반적으로 이러한 차이점이 있습니다.
물론 내 접근 방식은 아직 그렇게 광범위한 "객관성"을 갖고 있지 않습니다. 그러나 나는 그것을 고칠 방법을 이미 가지고 있습니다. 커널은 한 가지 유형이며 이는 내부에 저장된 속성을 제한하지만 커널이 단일 행렬일 필요는 없습니다. 그것은 핵의 복합체 일 수 있습니다. 주요 이점은 긴 설명, 추가 구문 및 기능 분할이 필요하지 않은 객체의 디지털 표현입니다.
그러나 OOP는 나에게 매우 흥미 롭습니다. 나는 그에게서 배울 것이다.Peter, 마지막으로 클래스에 대해 Google에서 메모리 할당 컨텍스트에서 클래스가 무엇인지, 메소드 호출, 즉 컴파일러가 이 모든 것을 변환하는 것입니다. 대부분의 질문은 그 후에 저절로 사라집니다.
나는 OOP의 개념에 대해 많이 생각했고 이것이 무엇입니까?
우리는 "클래스", "객체", "속성", "캡슐화", "다형성", "상속"의 개념을 남겨두고 구문 및 기술 용어에서 추상화합니다. 그 개념의 철학적 "근본"을 설명하겠습니다.
현실은 "공간", "시간", "물질"(감각 기관이 작동하는 방식)의 프리즘을 통해 의식에 의해 인식되며 "대상"은 지속적인 상호 작용의 개별 결과입니다.
다양한 형태의 상호작용은 무의식적 주체에 의해 특정 "프레임워크"에 "이식"되는 다양한 대상을 생성합니다. 이 프레임은 분기되는 계단식 구조를 가지고 있으며 "원형" 중 하나인 무의식에 "내재"되어 있습니다. 프레임워크는 구조 전체에 분산되는 점점 더 많은 새로운 객체(관련 정보)를 사용합니다. 여기서 OOP의 개념이 나옵니다. 이것은 무의식의 "알고리즘"을 모방한 대상의 의식적인 배포 및 바인딩입니다. 자신의 사고 방식을 마스터한 대상자는 두뇌의 "추적지"인 컴퓨터인 메커니즘에서 자신의 작업을 모델링할 수 있습니다. 컴퓨터는 뇌의 비참한 패러디에 불과하지만 사람 자신은 객관적인 세계의 그림자 만 인식합니다. 계단식, 분기형 원형은 우리의 기억 속에 있는 일반적으로 객체, 속성, 프로세스 및 모든 정보의 분포에 대한 "패턴"입니다. 이것은 현실의 인식을 단순화하고 주변 세계의 모델을 구조화하기 위한 생물학적 도구입니다. 이것은 자연적으로 우리에게 주어진 것입니다. 자신의 "자연적"(즉, 무의식적) 정보 처리 메커니즘에 대한 인식 은 OOP를 사용하는 데 필요한 자기 인식 수준입니다.
암묵적, 생물학적, "나무" 원형을 "인공적" 응용의 맥락에서 생각하여 암기, 학습 및 인식을 단순화합니다. OOP에서 우리는 속성과 값을 설정하는 클래스에 설명을 캡슐화하여 개체를 "생성"합니다. 객체의 관계는 분류에 반영되며 전역에서 전용으로 속성 및 메서드의 상속을 통해 구현됩니다. 실제로는 다음과 같이 보입니다. 모든 개인 개체는 하나의 개체일 뿐이므로 단순 개체의 모든 속성과 고유한 개인 속성을 가집니다. 그것에서 파생된 객체는 개인 속성을 일반 속성으로 가지지만 고유한 개인 속성을 갖습니다. 또한 체인은 무한정 갈 수 있습니다. 객체 메서드도 마찬가지입니다. 이 방법은 동작, 상호 작용, 프로세스, 상태 변경을 반영합니다. 개체 메서드는 속성과 마찬가지로 공개에서 비공개로 정렬됩니다. 특정 일반 프로세스가 있는 경우 각각의 개별 형태는 고유한 속성과 고유한 속성을 갖습니다. 그리고 이것은 다형성입니다. 즉, 오버로딩과 달리 다형성은 기본 메커니즘을 유지하면서 기본 기능의 다른 비공개 구현을 제공합니다. 이것은 "기능적" 상속입니다.
우리가 볼 수 있듯이 OOP의 "나무 모양"은 어디에나 있습니다. 어떤 계획을 생각해내더라도 여전히 "나무"를 얻을 수 있습니다.) 그러나 이것은 맞습니다. 왜냐하면 우리는 정보로 작업할 때 우리 자신의 무의식적인 패턴을 단순히 복사하기 때문입니다.
나는 OOP의 개념에 대해 많이 생각했고 이것이 무엇입니까?
...주석.
Peter, 당신은 시급히 정치에 들어가야 합니다. 여기에서 그러한 재능은 요구되지 않습니다. 많은 것을 현명하고 이해할 수 없으며 아무 것도 말하지 않습니다.
...
우리의 의식과 무의식의 작동 원리를 더 잘 이해함으로써 우리는 컴퓨터에서 그들의 작동 메커니즘을 재현할 수 있을 것입니다. 나는 기술적인 세부 사항에서 뒤로 물러나 개념의 뿌리를 살펴보았다.