나는 당신이 이 문제에 대한 당신의 이해를 표현하기를 원했고 나에게 책 같은 공식을 제공하지 않기를 바랍니다. 아닌 건 아닌거야. 나는 나 자신에 대해 말해주지.
글쎄, 그래서 나는 "책 공식화"를 하지 않았다 :) 나는 이유에 대한 설명과 함께 아무 것도 공식화하지 않았다. 알약 덕분에 이미 답을 알고 있는 시험 문제가 출제되었다고 가정했습니다. 그래서 밝혀졌습니다 :) 개인적인 경험에 대한 답변을 거부하지 않았습니다.
때로는 현상을 "느끼는" 것으로 충분하며 "이것이 어떻게 될 수 있습니까?", "깊은 의미는 무엇입니까?"와 같은 철학적 질문을 묻지 않고 예를 들어 어떻게 작동하는지 이해하십시오. 테트리스 핸드북에 있는 언급만으로도 충분했고 이 예제는 아주 처음에는 충분했습니다.
생성된 클래스 개체에 따라 하나 또는 다른 파생 클래스의 가상 함수가 호출됩니다.
void CTetrisField::NewShape()
{
//--- случайным образом создаём одну из 7 возможных фигурint nshape= rand ()% 7 ;
switch (nshape)
{
case0 : m_shape= new CTetrisShape1; break ;
case1 : m_shape= new CTetrisShape2; break ;
case2 : m_shape= new CTetrisShape3; break ;
case3 : m_shape= new CTetrisShape4; break ;
case4 : m_shape= new CTetrisShape5; break ;
case5 : m_shape= new CTetrisShape6; break ;
case6 : m_shape= new CTetrisShape7; break ;
}
//--- отрисовываем
m_shape.Draw();
//---
}
소스 데이터에 따라 동작이 다른 개체의 직관적인 생성 - 무엇을 볼 필요가 있고 무엇을 볼 수 있는지. 추가 - 포럼에서 Tetris가 포함된 전체 파일과 디렉토리, 라이브러리 등의 자료를 요청했습니다. 그리고 출발합니다. 주제에 대한 포럼의 많은 질문.
파파클라스 :
사이트에서 많은 정보를 읽은 후에도 여전히 OOP가 무엇인지 이해하지 못했습니다.
접근 방식에서 근본적인 차이가 있을 뿐입니다. 나는 과학적인 관점에서 "OOP가 무엇인가"라는 질문을 스스로에게 던지지 않았습니다. - 새롭고 이해할 수 없는 용어의 겉모습 뒤에 숨은 본질을 잃지 않기 위해.
나는 사용 가능한 예를 연구하기 위해 어리석게도 올라갔습니다.
파파클라스 :
사이트에서 많은 정보를 읽은 후에도 여전히 OOP가 무엇인지 이해하지 못했습니다.
사용 가능한 정보를 다양한 방식으로 읽을 수도 있습니다. "OOP란 무엇인가"라는 질문에 대한 답변을 여기에서 찾을 수 있습니다. MQL5 Reference / Language Basics / Object-Oriented Programming. 페이지를 읽으십시오. 분명히 이것은 제 3 자 자료에서 다른 정의를 찾을 필요 없이 충분했습니다.
글쎄, 왜 즉시 "죽여"? MQL5의 대부분의 초보자는 "절차적 프로그래밍"에 익숙합니다. 그리고 OOP의 필요성과 의미에 대해 질문이 있으면 참을성 있게 설명/씹어야 합니다. 학교에서 교사로서, 그것은 해마다 똑같습니다. 참을성 있게 설명하십시오. 교사가 이미 이 주제를 반복하는 것을 귀찮게 했다고 해서 nah를 보내지 마십시오.
"처형은 용서할 수 없다" - 구두점 대신 마음대로 - 해설사전 작성 - 그리고 '무자비하게 죽일' 사람은 없을 것이다.
그런 다음 OOP의 "실천가"를 읽습니다. 그것은 고도로 지능적인 OOP 전문가의 "카스트"일 뿐입니다.
MQL5는 캐스터뿐만 아니라 모든 수준의 이해와 기능을 위한 언어입니다. 지표 및 Expert Advisor의 표준 예가 이를 증명합니다.
프로그래밍 언어는 목적이 아니라 수단입니다. PP만으로도 목표를 달성할 수 있다면 충분합니다. 누군가가 OOP를 이해하고 쉽게 이해한다면 - 그렇게 될 것입니다. 그리고 목표를 달성하기 위해 근본적인 차이는 없습니다. 특히 주로 작성되는 로우 코드 미세 기능 지표 및 조언자의 90%에서.
주제 연구를 시작할 때 그러한 문구를 만나면 책 전체에서 논의할 내용이 즉시 명확해집니다. 그리고 어떻게 든 모든 것이 제자리에 떨어집니다. 속성은 객체의 속성이고 구현과 메서드는 동일하며(함수) 마지막으로 클래스는 객체로 구성된다는 점을 이해합니다. 객체는 속성(속성)과 메서드(함수)를 가질 뿐만 아니라 서로 상호 작용할 수도 있습니다. 동시에 그들(객체)이 다른 객체의 속성과 방법을 아는 것은 중요하지 않습니다. 따라서 이러한 벽돌에서 서로 상호 작용하는 클래스가 만들어집니다.
죽도 끓일 수 없을 정도로 모든 것을 뒤섞었다.)) 이것이 책에 쓰여진 것은 아닐 것이다.
Как уже надоели все эти программистские теоретики, блин.
곧 "OOP 대 절차"라는 주제가 무자비하게 사라질 것입니다.
그리고 이것은 사람들이 장단점, 장소 및 사용 방법에 대한 이해가 없기 때문입니다. 간단한 예가 있는 기사: PP는 이 task_1에 대해 플러스 및 마이너스를 제공하고 OOP는 이 task_1에 대해 플러스 및 마이너스를 제공합니다. PP는 이 task_2와 같은 마이너스를 제공할 것입니다. OOP는 이 task_2와 같은 마이너스를 제공할 것입니다... 초보자가 OOP에 익숙해지기 위해서는 미묘함과 차이점이 어려울 수 있습니다. 그리고 모두 간단한 문제 해결에 중점을 두었습니다. 이것이 바로 어려움입니다. 설명과 예제는 가능한 한 간단하고 짧지 만 PP와 OOP의 원칙을 사용하는 것이 필요합니다.
그런 다음 일부 주제에 대해 체계화된 간단한 적용 예와 함께 모든 것이 정리된 장소로 주제를 전송함으로써 주제를 강타할 수 있을 것입니다.
예델킨 : 현명하게. 나는 스스로 판단한다. 단일 통화 지표는 소프트웨어로 작성된다. 다중 통화 전문가 고문 - OOP 사용(OOP가 없으면 전혀 나타나지 않기 때문에).
친애하는 예델킨! 관심이 있으시면 절차적으로 설계된 다중 통화 코어를 보내드릴 수 있습니다(오픈 바에서 작동함). 코드는 4에 대해 작성되었지만 5에도 적용됩니다. 두 옵션의 성능을 비교할 수 있습니다.
-Alexey- : 친애하는 Yedelkin! 관심이 있으시면 절차적으로 설계된 다중 통화 코어를 보내드릴 수 있습니다(오픈 바에서 작동함). 코드는 4개를 위해 작성되었습니다.
저는 가능하면 모두가 함께 살아가야 하고 서로를 이해하며 살아야 한다는 사실을 지지합니다. 내 메시지에 관해서는 OOP에 대한 내 이해만 설명했습니다. 그것은 (이해) 세 번 틀릴 수 있지만 그것은 "내 것"입니다. OOP의 도움으로 풀 수 있었던 일부 작업도 PP의 프레임워크 내에서 해결할 수 있다는 점을 전혀 배제하지 않습니다. abolk 의 진술의 지혜는 바로 " PP가 목표를 달성하기에 충분하다면 그렇게 하십시오. 누군가가 OOP를 수행하는 것이 더 명확하고 쉽다면 그렇게 하십시오 ."라는 것입니다. 내 게시물에 추가했습니다.
Yedelkin : 저는 가능하면 모두가 함께 살아가야 하고 서로를 이해하며 살아야 한다는 사실을 지지합니다. 내 메시지에 관해서는 OOP에 대한 내 이해만 설명했습니다. 그것은 (이해) 세 번 틀릴 수 있지만 그것은 "내 것"입니다. OOP의 도움으로 풀 수 있었던 일부 작업도 PP의 프레임워크 내에서 해결할 수 있다는 점을 전혀 배제하지 않습니다. abolk 의 진술의 지혜는 바로 " PP가 목표를 달성하기에 충분하다면 그렇게 하십시오. 누군가가 OOP를 수행하는 것이 더 명확하고 쉽다면 그렇게 하십시오 ."라는 것입니다.
동의한다. 그리고 하나 또는 다른 선호도의 분위기에 따라 싸우려면 포럼 회원 간의 경연 대회를 조직하는 것이 가장 좋습니다. 그러한 작업이 있습니다 ... : 속도, 메모리 소비, 코드 크기, 이식성 면에서 구체적으로 어떤 접근 방식이 승리할까요?
물어봐도 될까요? 절차적 프로그래밍과 OOP의 근본적인 차이점은 무엇입니까? 몇 마디, 그것이 차이점의 본질입니다.
절차 적 접근조차도 구조가 없으면 매우 어렵 기 때문에 구조의 존재를 의미한다는 사실부터 시작하겠습니다. 그것은 최소한 일종의 데이터 조직입니다.
OOP를 사용하면 디자인 단계에서 추상 엔티티와 이들 간의 관계를 매우 편안하게 강조 표시할 수 있습니다. 그런 다음 구현의 세부 사항에 신경 쓰지 않고 개별적으로라도 코딩하면 됩니다.
예, 모든 것이 더 논리적으로 보이고 더 잘 읽힙니다. 그리고 종종 더 빠르게 작동합니다. 그리고 가장 중요한 것은 더 빠르게 구현된다는 것입니다. 더 많은 코드가 있을 수 있음에도 불구하고.
나는 당신이 이 문제에 대한 당신의 이해를 표현하기를 원했고 나에게 책 같은 공식을 제공하지 않기를 바랍니다. 아닌 건 아닌거야. 나는 나 자신에 대해 말해주지.
글쎄, 그래서 나는 "책 공식화"를 하지 않았다 :) 나는 이유에 대한 설명과 함께 아무 것도 공식화하지 않았다. 알약 덕분에 이미 답을 알고 있는 시험 문제가 출제되었다고 가정했습니다. 그래서 밝혀졌습니다 :) 개인적인 경험에 대한 답변을 거부하지 않았습니다.
때로는 현상을 "느끼는" 것으로 충분하며 "이것이 어떻게 될 수 있습니까?", "깊은 의미는 무엇입니까?"와 같은 철학적 질문을 묻지 않고 예를 들어 어떻게 작동하는지 이해하십시오. 테트리스 핸드북에 있는 언급만으로도 충분했고 이 예제는 아주 처음에는 충분했습니다.
생성된 클래스 개체에 따라 하나 또는 다른 파생 클래스의 가상 함수가 호출됩니다.
소스 데이터에 따라 동작이 다른 개체의 직관적인 생성 - 무엇을 볼 필요가 있고 무엇을 볼 수 있는지. 추가 - 포럼에서 Tetris가 포함된 전체 파일과 디렉토리, 라이브러리 등의 자료를 요청했습니다. 그리고 출발합니다. 주제에 대한 포럼의 많은 질문.
사이트에서 많은 정보를 읽은 후에도 여전히 OOP가 무엇인지 이해하지 못했습니다.
접근 방식에서 근본적인 차이가 있을 뿐입니다. 나는 과학적인 관점에서 "OOP가 무엇인가"라는 질문을 스스로에게 던지지 않았습니다. - 새롭고 이해할 수 없는 용어의 겉모습 뒤에 숨은 본질을 잃지 않기 위해.
나는 사용 가능한 예를 연구하기 위해 어리석게도 올라갔습니다.
사이트에서 많은 정보를 읽은 후에도 여전히 OOP가 무엇인지 이해하지 못했습니다.
사용 가능한 정보를 다양한 방식으로 읽을 수도 있습니다. "OOP란 무엇인가"라는 질문에 대한 답변을 여기에서 찾을 수 있습니다. MQL5 Reference / Language Basics / Object-Oriented Programming. 페이지를 읽으십시오. 분명히 이것은 제 3 자 자료에서 다른 정의를 찾을 필요 없이 충분했습니다.
내 질문에 대한 답변:
절차적 프로그래밍은 동작(동사)에 초점을 맞추는 반면 객체 지향 프로그래밍은 사물 또는 객체(명사)에 중점을 둡니다. 이것이 주요 차이점입니다.
이론과 실제:
절차적 프로그래밍은 무엇을 해야 하는지(동사)에 대한 질문에 답합니다.
객체 지향 프로그래밍 - 객체(명사)를 동사 및 설명 (형용사) 합니다.
즉, OOP는 품사가 많은 의미 있는 문장으로 코드를 일반화하는 추가 기능입니다.
동사로만 말하는 사람은 절차에 따라 살 수 있습니다.
누가 그의 코드를 설명하고 싶습니까? 그런 다음 OOP로 작성하게 하십시오.
추신.
이 모든 프로그래머 이론가들에게 얼마나 지쳤는지, 젠장.
곧 "OOP 대 절차"라는 주제가 무자비하게 사라질 것입니다.추신.
이 모든 프로그래머 이론가들에게 얼마나 지쳤는지, 젠장.
곧 "OOP 대 절차"라는 주제가 무자비하게 사라질 것입니다.추신.
이 모든 프로그래머 이론가들에게 얼마나 지쳤는지, 젠장.
곧 "OOP 대 절차"라는 주제가 무자비하게 사라질 것입니다."처형은 용서할 수 없다" - 구두점 대신 마음대로 - 해설사전 작성 - 그리고 '무자비하게 죽일' 사람은 없을 것이다.
그런 다음 OOP의 "실천가"를 읽습니다. 그것은 고도로 지능적인 OOP 전문가의 "카스트"일 뿐입니다.
MQL5는 캐스터뿐만 아니라 모든 수준의 이해와 기능을 위한 언어입니다. 지표 및 Expert Advisor의 표준 예가 이를 증명합니다.
프로그래밍 언어는 목적이 아니라 수단입니다. PP만으로도 목표를 달성할 수 있다면 충분합니다. 누군가가 OOP를 이해하고 쉽게 이해한다면 - 그렇게 될 것입니다. 그리고 목표를 달성하기 위해 근본적인 차이는 없습니다. 특히 주로 작성되는 로우 코드 미세 기능 지표 및 조언자의 90%에서.
papaklass :
주제 연구를 시작할 때 그러한 문구를 만나면 책 전체에서 논의할 내용이 즉시 명확해집니다. 그리고 어떻게 든 모든 것이 제자리에 떨어집니다. 속성은 객체의 속성이고 구현과 메서드는 동일하며(함수) 마지막으로 클래스는 객체로 구성된다는 점을 이해합니다. 객체는 속성(속성)과 메서드(함수)를 가질 뿐만 아니라 서로 상호 작용할 수도 있습니다. 동시에 그들(객체)이 다른 객체의 속성과 방법을 아는 것은 중요하지 않습니다. 따라서 이러한 벽돌에서 서로 상호 작용하는 클래스가 만들어집니다.
프로그래밍 언어는 목적이 아니라 수단입니다. PP만으로도 목표를 달성할 수 있다면 충분합니다. 누군가가 OOP를 이해하고 쉽게 이해한다면 - 그렇게 될 것입니다.
Как уже надоели все эти программистские теоретики, блин.
곧 "OOP 대 절차"라는 주제가 무자비하게 사라질 것입니다.그리고 이것은 사람들이 장단점, 장소 및 사용 방법에 대한 이해가 없기 때문입니다. 간단한 예가 있는 기사: PP는 이 task_1에 대해 플러스 및 마이너스를 제공하고 OOP는 이 task_1에 대해 플러스 및 마이너스를 제공합니다. PP는 이 task_2와 같은 마이너스를 제공할 것입니다. OOP는 이 task_2와 같은 마이너스를 제공할 것입니다... 초보자가 OOP에 익숙해지기 위해서는 미묘함과 차이점이 어려울 수 있습니다. 그리고 모두 간단한 문제 해결에 중점을 두었습니다. 이것이 바로 어려움입니다. 설명과 예제는 가능한 한 간단하고 짧지 만 PP와 OOP의 원칙을 사용하는 것이 필요합니다.
그런 다음 일부 주제에 대해 체계화된 간단한 적용 예와 함께 모든 것이 정리된 장소로 주제를 전송함으로써 주제를 강타할 수 있을 것입니다.
현명하게. 나는 스스로 판단한다. 단일 통화 지표는 소프트웨어로 작성된다. 다중 통화 전문가 고문 - OOP 사용(OOP가 없으면 전혀 나타나지 않기 때문에).
저는 가능하면 모두가 함께 살아가야 하고 서로를 이해하며 살아야 한다는 사실을 지지합니다. 내 메시지에 관해서는 OOP에 대한 내 이해만 설명했습니다. 그것은 (이해) 세 번 틀릴 수 있지만 그것은 "내 것"입니다. OOP의 도움으로 풀 수 있었던 일부 작업도 PP의 프레임워크 내에서 해결할 수 있다는 점을 전혀 배제하지 않습니다. abolk 의 진술의 지혜는 바로 " PP가 목표를 달성하기에 충분하다면 그렇게 하십시오. 누군가가 OOP를 수행하는 것이 더 명확하고 쉽다면 그렇게 하십시오 ."라는 것입니다.