학생을 위한 OOP. - 페이지 4

새 코멘트
 
Dmitry Fedoseev :

아니요, 그들은 (학생) 이해하지 못할 것입니다. 특히 매트릭스. 그들은 다음과 같이 말할 것입니다: 우리에게 이 다형성은... 무엇입니까?

폴리 뭐...

 
Ihor Herasko :

넌센스란 무엇인가? getter 의 정의를 열고 다음을 읽으십시오.

그러나 개인 데이터를 얻을 수 있는 메커니즘은 다를 수 있습니다. C#에서는 이것이 한 가지 방법이고 C++ 및 MQL에서는 다른 방법입니다. 그러나 이 방법에서 "게터"의 정의를 잃지 않습니다.

그래서 우리는 "특별한" 방법을 읽습니다.

 
Dmitry Fedoseev :

불편할 뿐입니다. x 요소와 y 요소를 알아야 합니다. 구조를 사용할 때 모든 것이 명확하고 오류가 제거되고 코드 양이 줄어 듭니다.

이 경우 (가령) 구조체를 통사론적 장치로 사용하고, 그 데이터에 접근할 때 배열과 달리 인스턴스를 곱해야 하는 불편함의 균형을 이룹니다.

구조를 사용하는 것의 의미는 더 깊지만 TS는 이 정도로만 제시합니다. 그것은 - OOP - 일련의 구문 기술로 밝혀졌습니다. 그것이 학생들이 배울 것입니다. 그런 다음 작업에서 구문을 단순화하고 OOP를 거부하기 시작할 수 있음을 이해합니다.

우리는 구문론적 증명이 아니라 OOP의 필요성에 대한 개념적 증명이 필요합니다.

 
스레드 주셔서 감사합니다. 좋아요
 
Dmitry Fedoseev :

그래서 우리는 "특별한"방법을 읽습니다.

기사를 조금 아래로 스크롤하십시오. MQL은 없지만 C++는 있습니다. 아니면 C++에도 getter가 없습니까?

 
Реter Konow :

이 경우 (가령) 구조를 통사론적 장치로 사용하고, 그 데이터에 접근할 때 배열과 달리 인스턴스를 곱해야 하는 불편함의 균형을 이룹니다.

구조를 사용하는 것의 의미는 더 깊지만 TS는 이 정도로만 제시합니다. 그것은 - OOP - 일련의 구문 기술로 밝혀졌습니다. 그것이 학생들이 배울 것입니다. 그런 다음 작업에서 구문을 단순화하고 OOP를 거부하기 시작할 수 있음을 이해합니다.

우리는 구문론적 증명이 아니라 OOP의 필요성에 대한 개념적 증명이 필요합니다.

아무것도 생산할 필요가 없습니다. 일반 배열처럼 작동하지만 더 편리합니다.

개념적 증명 ... 그러면 벽돌 생산 분야에서도 필요합니다 ... 즉시 점토로 벽을 번지는 것이 더 편리하고 그렇지 않다는 것을 증명하려고합니다.

 
Ihor Herasko :

기사를 조금 아래로 스크롤하십시오. MQL은 없지만 C++는 있습니다. 아니면 C++에도 getter가 없습니까?

이 스레드도 열지 않았습니다. 거기에서 무엇을 봐야 합니까? C++는 어떻습니까?

 
Dmitry Fedoseev :

아무것도 생산할 필요가 없습니다. 일반 배열처럼 작동하지만 더 편리합니다.

개념적 증명 ... 그러면 벽돌 생산 분야에서도 필요합니다 ... 즉시 점토로 벽을 번지는 것이 더 편리하고 그렇지 않다는 것을 증명하려고합니다.

데이터 작업에 OOP가 필요합니다. 반복 - 데이터로.

OOP는 데이터를 배포하고 이에 대한 편리한 액세스를 구성하는 데 도움이 됩니다. 이를 위해서는 클래스와 구조가 필요합니다.


좌표 문제에서는 데이터가 너무 적으므로 구조와 클래스가 필요하지 않습니다. 문제를 확장하고 해당 "필드"에 많은 데이터 유형 을 추가하면 분류가 필요합니다. 그리고 그 뒤에는 클래스와 구조가 있습니다.

분류가 필요하지 않으면 클래스가 필요하지 않습니다. 구조화가 필요하지 않으면 구조가 필요하지 않습니다.

다양한 객체가 다양한 데이터를 결합하지 않으면 OOP가 필요하지 않습니다.

단조로운 데이터로 플랫 프로그램에 OOP를 도입하는 것은 개념을 잘못 노출하기 때문에 훈련에서도 해롭습니다. 사람들은 OOP가 일련의 구문 트릭이라고 생각하기 시작하고 무작위로 사용합니다. 필요한 곳과 필요하지 않은 곳.

 
Реter Konow :

1. 데이터 작업에 OOP가 필요합니다. 반복 - 데이터로.

OOP는 데이터를 배포하고 이에 대한 편리한 액세스를 구성하는 데 도움이 됩니다. 이를 위해서는 클래스와 구조가 필요합니다.


2. 좌표 문제는 데이터가 너무 적어 구조체와 클래스가 필요하지 않다. 문제를 확장하고 해당 "필드"에 많은 데이터 유형 을 추가하면 분류가 필요합니다. 그리고 그 뒤에는 클래스와 구조가 있습니다.

분류가 필요하지 않으면 클래스가 필요하지 않습니다. 구조화가 필요하지 않으면 구조가 필요하지 않습니다.

3. 다양한 데이터가 다양한 개체로 통합되지 않으면 OOP가 필요하지 않습니다.

단조로운 데이터로 플랫 프로그램에 OOP를 도입하는 것은 개념을 잘못 노출하기 때문에 훈련에서도 해롭습니다. 사람들은 OOP가 일련의 구문 기술이라고 생각하고 무작위로 사용합니다. 필요한 곳과 필요하지 않은 곳.

1. 빈 대화. 모든 프로그래밍은 예외 없이 데이터로 작동합니다.

2. 좌표 문제 자체에는 데이터가 거의 없지만 작업이 많으면 쉬울 것입니다. OOP에서 장대한 것을 찾을 필요가 없습니다. 데이터를 그룹화하고 데이터를 사용하여 작업하는 방법이자 코드를 재사용하는 방법입니다.

3. 어떤 변종이라도 그 안에 있는 독립된 소장품을 구별할 수 있다면 분류로 나눌 수 있고 괜찮을 것이다.
 
Реter Konow :

자, 코드로 넘어가겠습니다.

과제는 무엇이었나요? - 포인트의 좌표를 저장하는 것이 편리합니다. 무엇을 위해? - 빠른 액세스를 위해.

작업이 빠른 데이터 액세스에만 있는 경우 POINT 구조 및 해당 인스턴스는 솔루션에서 불필요한 엔터티입니다. 매트릭스를 통해 액세스하는 것이 얼마나 쉬운지 확인하십시오.

당신은 당신이 철학자는 아니지만 "구조"는 철학적 개념이며 솔루션에 존재하는 것이 정당화되어야 한다고 말합니다.

"손 #1" 및 "손 #2"라고 부르는 것이 더 쉬울 수 있지만 대부분은 "왼쪽"과 "오른쪽"이라고 부르는 것을 선호합니다.

1234567891011...18
새 코멘트