읽기로는 충분하지 않습니다. IMHO, 작업을 설정하고 절차적 스타일로 작성해야 합니다. 그런 다음 (어렵지 않음) 이 작업을 OOP 스타일로 다시 작성해야 합니다.
TC가 반복적으로 작성했듯이 OOP를 사용하면 작업을 빠르게 확장하고 개발 속도를 높이며 프로그램 작성 시 오류 수를 줄일 수 있습니다.
MQL과 관련하여: 내가 가장 좋아하지 않는 작업 중 하나는 절차적 프로그래밍 스타일로 일련의 주문을 부분적으로 닫는 것입니다. 하나의 주문을 닫는 서브루틴을 호출한 후 오류 처리를 구성해야 합니다. 한 번의 호출로 모든 주문을 부분적으로 마감할 수 없었습니까? - 서버가 부분적으로 닫히지 않았습니까? - 나는 연초에 여느 때와 같이, 99%의 경우에 모든 일반적인 결정이 주문 주석을 분석하는 것으로 귀결된 것이 무엇인지에 대해 물었습니다. .IMHO, 전문적이지 않음
OOP 스타일에서 이 작업은 "2클릭"으로 해결되며 주문을 부분적으로 닫는 메서드를 호출하며 주문 상태 데이터 자체가 티켓이며 수정해야 하는 필요가 ..... 및 작동하는 메서드 주문과 함께 ORDER 클래스에 저장됩니다. 솔루션은 가능한 한 유연하고 후속 작업, IMHO에 대해 확장 가능합니다.
MQL의 그래픽이 있는 작업도 마찬가지입니다. 텍스트 레이블이 하나라면 작업하는 데 문제가 없지만 레이블이 10-100개라면 어떻게 될까요? - 그리고 색 구성표를 변경해야 하는 경우 일부 레이블은 "산호" 색상, 다른 레이블은 "버튼이 있는 자개"로 선택적으로 변경해야 합니까?... 그리고 일주일 후에 3개의 버튼을 더 추가해야 했습니다. ... 그리고 일주일 후에 10 개의 버튼을 제거해야했습니다 ....
추신 : 풍차와의 또 다른 싸움에 대한 주제 .... 아니, 나는 누군가를 기억했습니다 (나는 내 성을 잊었습니다))))-누가 지구가 둥글다고 말했고 그들은 그것을 태워 버렸습니까? )))) - 이것이 문맹 퇴치 및/또는 자신의 지평을 넓히는 것과 같은 것입니다.
읽기로는 충분하지 않습니다. IMHO, 작업을 설정하고 절차적 스타일로 작성해야 합니다. 그런 다음 (어렵지 않음) 이 작업을 OOP 스타일로 다시 작성해야 합니다.
TC가 반복적으로 작성했듯이 OOP를 사용하면 작업을 빠르게 확장하고 개발 속도를 높이며 프로그램 작성 시 오류 수를 줄일 수 있습니다.
MQL과 관련하여: 내가 가장 좋아하지 않는 작업 중 하나는 절차적 프로그래밍 스타일로 일련의 주문을 부분적으로 닫는 것입니다. 하나의 주문을 닫는 서브루틴을 호출한 후 오류 처리를 구성해야 합니다. 한 번의 호출로 모든 주문을 부분적으로 마감할 수 없습니까? - 서버가 부분적으로 닫히지 않았습니까? - 나는 연초에 여느 때와 같이, 99%의 경우에 모든 일반적인 결정이 주문 주석을 분석하는 것으로 귀결된 것이 무엇인지에 대해 물었습니다. .IMHO, 전문적이지 않음
OOP 스타일에서 이 작업은 "2클릭"으로 해결되며 주문을 부분적으로 닫는 메서드를 호출하며 주문 상태 데이터 자체가 티켓이며 수정해야 하는 필요가 ..... 및 작동하는 메서드 주문과 함께 ORDER 클래스에 저장됩니다. 솔루션은 가능한 한 유연하고 후속 작업, IMHO에 대해 확장 가능합니다.
MQL의 그래픽이 있는 작업도 마찬가지입니다. 텍스트 레이블이 하나라면 작업하는 데 문제가 없지만 레이블이 10-100개라면 어떻게 될까요? - 그리고 색 구성표를 변경해야 하는 경우 일부 레이블은 "산호" 색상, 다른 레이블은 "버튼이 있는 자개"로 선택적으로 변경해야 합니까?... 그리고 일주일 후에 3개의 버튼을 더 추가해야 했습니다. ... 그리고 일주일 후에 10 개의 버튼을 제거해야했습니다 ....
추신 : 풍차와의 또 다른 싸움에 대한 주제 .... 아니, 나는 누군가를 기억했습니다 (나는 내 성을 잊었습니다))))-누가 지구가 둥글다고 말했고 그들은 그것을 태워 버렸습니까? )))) - 이것이 문맹 퇴치 및 / 또는 자신의 지평을 넓히는 방법입니다.
제 생각에 mql에는 OOP를 사용하여 해결해야 하는 매우 좁은 작업 세트가 있습니다. 내가 보기에 언어 자체는 C ++의 OOP 또는 다른 것에 지나지 않습니다. 그리고 이 OOP는 OOP를 표준 라이브러리로 제공합니다. 그리고 OOP의이 OOP에 대해 그것을 망칠 것을 제안합니다. 그렇지 않으면 다른 OOP를 말할 수 없습니다. 그리고 한 걸음 더 ... The Sorcerer는 비록 사악하지만 자비로운 내 일을 위해 OOP는 개 차례와 같다고 올바르게 말했습니다. 그리고 이 작업이 절차적 방식으로 문제 없이 해결될 수 있다면 작업을 설정하고 OOP를 통해 구현하는 것이 무슨 소용이겠습니까?
예를 들어, fxsaber에서 .mqh를 사용하여 MT5 및 MT4용 코드를 작성합니다. 누군가는 그것을 필요로 할 수도 있지만 누가 봐... mql5를 마스터하기를 원하지 않거나 완전히 마스터할 수 없는 사람들을 위해. 또는 Nikolay의 iCanvas를 가져오십시오 ..., 나는 그의 성을 잊어 버렸습니다. 이해합니다. 유용한 라이브러리인 것 같지만 알아내기가 쉽지 않고, 설명서도 없고 최소한의 설명도 없습니다. 이것은 불만이 아닙니다. 죄송합니다. Nikolai, 이것은 사실입니다. 그래서 그래픽 레이블을 작성하려고 했을 때 표준 라이브러리나 Nikolai의 라이브러리를 참조하지 않고 작성하는 것이 더 쉬웠습니다.
제 생각에 mql에는 OOP를 사용하여 해결해야 하는 매우 좁은 작업 세트가 있습니다. 내가 보기에 언어 자체는 C ++의 OOP 또는 다른 것에 지나지 않습니다. 그리고 이 OOP는 OOP를 표준 라이브러리로 제공합니다. 그리고 OOP의이 OOP에 대해 그것을 망칠 것을 제안합니다. 그렇지 않으면 다른 OOP를 말할 수 없습니다. 그리고 한 걸음 더 ... The Sorcerer는 비록 사악하지만 자비로운 내 일을 위해 OOP는 개 차례와 같다고 올바르게 말했습니다. 그리고 이 작업이 절차적 방식으로 문제 없이 해결될 수 있다면 작업을 설정하고 OOP를 통해 구현하는 것이 무슨 소용이겠습니까?
불행히도 당신이 90% 옳았지만 트레이더가 작성하도록 요청한 거래 전략 때문에 .... 솔직히 말해서 원시적 인 MQL에서 고품질 그래픽 패널을 만들 수있게되었을 때 약간의 부흥이 있었지만 그 결과 이것은 최종 사용자에게도 필요하지 않았습니다. 일반적으로 청중은 잡종이지만 .... 하나의 버튼만 필요합니다 - 전리품 ...
알렉세이 빅토로프 :
예를 들어, fxsaber에서 .mqh를 사용하여 MT5 및 MT4용 코드를 작성합니다. 누군가는 그것을 필요로 할 수도 있지만 누가 봐... mql5를 마스터하기를 원하지 않거나 완전히 마스터할 수 없는 사람들을 위해.
이 라이브러리를 사용하는 이유는 MT5가 필요하지만 주문 시스템을 연구하는 데 시간을 낭비하고 싶지는 않습니다. MT5 초보자 분기에서 무엇과 방법을 몇 번이나 물어보려고 했지만... 결과는 부정적입니다. 이 포럼에서는 사실 , MT5 주문 시스템의 작동 방식, 내 질문에 대한 답변 ... 일반적으로 "Jumble이 쉬고 있습니다"에 대한 지식 전달자가 없습니다.
알렉세이 빅토로프 :
또는 Nikolay의 iCanvas를 가져오십시오 ..., 나는 그의 성을 잊어 버렸습니다. 이해합니다. 유용한 라이브러리인 것 같지만 알아내기가 쉽지 않고, 설명서도 없고 최소한의 설명도 없습니다. 이것은 불만이 아닙니다. 죄송합니다. Nikolai, 이것은 사실입니다. 그래서 그래픽 레이블을 작성하려고 했을 때 표준 라이브러리나 Nikolai의 라이브러리를 참조하지 않고 작성하는 것이 더 쉬웠습니다.
@Nikolai Semko 의 라이브러리를 두어 번 사용했습니다. 특별한 것은 없습니다. 플러그를 꽂고 사용하십시오... 원칙은 KB의 일일 Expert Advisors의 약 99%와 동일합니다. 중재자는 사용하지 않습니다. 거기 주문 시스템에 귀찮게? - OOP 형식으로 작성된 SB를 연결하고 그가 제안하는 조언자를 대량으로 생성
제 생각에 mql에는 OOP를 사용하여 해결해야 하는 매우 좁은 작업 세트가 있습니다. 내가 보기에 언어 자체는 C ++의 OOP 또는 다른 것에 지나지 않습니다. 그리고 이 OOP는 OOP를 표준 라이브러리로 제공합니다. 그리고 OOP의이 OOP에 대해 그것을 망칠 것을 제안합니다. 그렇지 않으면 다른 OOP를 말할 수 없습니다. 그리고 한 걸음 더 ... The Sorcerer는 비록 사악하지만 자비로운 내 일을 위해 OOP는 개 차례와 같다고 올바르게 말했습니다. 그리고 이 작업이 절차적 방식으로 문제 없이 해결될 수 있다면 작업을 설정하고 OOP를 통해 구현하는 것이 무슨 소용이겠습니까?
예를 들어, fxsaber에서 .mqh를 사용하여 MT5 및 MT4용 코드를 작성합니다. 누군가는 그것을 필요로 할 수도 있지만 누가 봐... mql5를 마스터하기를 원하지 않거나 완전히 마스터할 수 없는 사람들을 위해. 또는 Nikolay의 iCanvas를 가져오십시오 ..., 나는 그의 성을 잊어 버렸습니다. 이해합니다. 유용한 라이브러리인 것 같지만 알아내기가 쉽지 않고, 설명서도 없고 최소한의 설명도 없습니다. 이것은 불만이 아닙니다. 죄송합니다. Nikolai, 이것은 사실입니다. 그래서 그래픽 레이블을 작성하려고 했을 때 표준 라이브러리나 Nikolai의 라이브러리를 참조하지 않고 작성하는 것이 더 쉬웠습니다.
OOP의 사용은 알고리즘 거래보다 훨씬 더 높은 수준의 작업 복잡성을 의미합니다. 따라서 분쟁이 있습니다. OOP는 전문 프로그래머와 개발자가 복잡한 프로그램을 작업하는 데 필요합니다. 그렇게 진지하게 접근할 여지가 거의 없습니다. 작은 예를 들어 OOP의 의미를 설명하는 것은 잘못된 것입니다. OOP의 의미는 방대한 양의 데이터와 기능을 가진 대규모 작업에 있습니다. 데이터의 다양성은 분리와 분류를 필요로 하며, 계층으로 구분된 클래스들 사이에 기술, 속성 상속, 메소드 상속을 캡슐화하는 관련성이 있습니다.
프로그래머 가 OOP를 배우면 즉시 대규모 프로그램의 세계에 합류하여 그곳을 탐색하기 시작합니다. 그러나 이 "세계"에서 그들 자신의 기능은 작을 수 있습니다. 그것은 중요하지 않습니다. 그들은 단지 프로그램과 라이브러리의 일반적인 바다와 그곳에서 하는 일에 합류합니다. 알고 트레이더가 필요합니까? 말하기 어렵다. 누가 필요로 하는지 - 마스터할 것입니다. 나머지는 오랫동안 생각하고 OOP라고 부르는 무언가를 시도합니다 ...
확인. getter에 대한 정의를 내리십시오.
그것은 말이 아니다
그것은 말이 아니다
나는 그가 알고 있는 것을 설명할 수 있는 사람을 상대하고 있다고 생각했습니다. 그리고 정의의 수준에서도 문제가 있습니다.
나는 그가 알고 있는 것을 설명할 수 있는 사람을 상대하고 있다고 생각했습니다. 그리고 정의의 수준에서도 문제가 있습니다.
네, 원하는 대로 상상해 보세요. 여기 여러분 중 일부도 마찬가지입니다. 모든 것이 오래 전부터 분명해졌습니다. 그들은 제 할머니를 괴롭히기 위해 귀를 얼릴 준비가 되어 있습니다.
네, 원하는 대로 상상해 보세요. 여기에서 당신과 몇몇 사람들과 함께 모든 것이 나에게 오랫동안 분명해졌습니다.
모든 것이 명확합니다. 당신은 단지 설명할 수 없습니다
모든 것이 명확합니다. 당신은 단지 설명할 수 없습니다
할머니에게 욕을 먹으려고 귀를 계속 얼려두세요.
나는 창조의 첫 순간부터 읽었습니다.
읽기로는 충분하지 않습니다. IMHO, 작업을 설정하고 절차적 스타일로 작성해야 합니다. 그런 다음 (어렵지 않음) 이 작업을 OOP 스타일로 다시 작성해야 합니다.
TC가 반복적으로 작성했듯이 OOP를 사용하면 작업을 빠르게 확장하고 개발 속도를 높이며 프로그램 작성 시 오류 수를 줄일 수 있습니다.
MQL과 관련하여: 내가 가장 좋아하지 않는 작업 중 하나는 절차적 프로그래밍 스타일로 일련의 주문을 부분적으로 닫는 것입니다. 하나의 주문을 닫는 서브루틴을 호출한 후 오류 처리를 구성해야 합니다. 한 번의 호출로 모든 주문을 부분적으로 마감할 수 없었습니까? - 서버가 부분적으로 닫히지 않았습니까? - 나는 연초에 여느 때와 같이, 99%의 경우에 모든 일반적인 결정이 주문 주석을 분석하는 것으로 귀결된 것이 무엇인지에 대해 물었습니다. .IMHO, 전문적이지 않음
OOP 스타일에서 이 작업은 "2클릭"으로 해결되며 주문을 부분적으로 닫는 메서드를 호출하며 주문 상태 데이터 자체가 티켓이며 수정해야 하는 필요가 ..... 및 작동하는 메서드 주문과 함께 ORDER 클래스에 저장됩니다. 솔루션은 가능한 한 유연하고 후속 작업, IMHO에 대해 확장 가능합니다.
MQL의 그래픽이 있는 작업도 마찬가지입니다. 텍스트 레이블이 하나라면 작업하는 데 문제가 없지만 레이블이 10-100개라면 어떻게 될까요? - 그리고 색 구성표를 변경해야 하는 경우 일부 레이블은 "산호" 색상, 다른 레이블은 "버튼이 있는 자개"로 선택적으로 변경해야 합니까?... 그리고 일주일 후에 3개의 버튼을 더 추가해야 했습니다. ... 그리고 일주일 후에 10 개의 버튼을 제거해야했습니다 ....
추신 : 풍차와의 또 다른 싸움에 대한 주제 .... 아니, 나는 누군가를 기억했습니다 (나는 내 성을 잊었습니다))))-누가 지구가 둥글다고 말했고 그들은 그것을 태워 버렸습니까? )))) - 이것이 문맹 퇴치 및/또는 자신의 지평을 넓히는 것과 같은 것입니다.
읽기로는 충분하지 않습니다. IMHO, 작업을 설정하고 절차적 스타일로 작성해야 합니다. 그런 다음 (어렵지 않음) 이 작업을 OOP 스타일로 다시 작성해야 합니다.
TC가 반복적으로 작성했듯이 OOP를 사용하면 작업을 빠르게 확장하고 개발 속도를 높이며 프로그램 작성 시 오류 수를 줄일 수 있습니다.
MQL과 관련하여: 내가 가장 좋아하지 않는 작업 중 하나는 절차적 프로그래밍 스타일로 일련의 주문을 부분적으로 닫는 것입니다. 하나의 주문을 닫는 서브루틴을 호출한 후 오류 처리를 구성해야 합니다. 한 번의 호출로 모든 주문을 부분적으로 마감할 수 없습니까? - 서버가 부분적으로 닫히지 않았습니까? - 나는 연초에 여느 때와 같이, 99%의 경우에 모든 일반적인 결정이 주문 주석을 분석하는 것으로 귀결된 것이 무엇인지에 대해 물었습니다. .IMHO, 전문적이지 않음
OOP 스타일에서 이 작업은 "2클릭"으로 해결되며 주문을 부분적으로 닫는 메서드를 호출하며 주문 상태 데이터 자체가 티켓이며 수정해야 하는 필요가 ..... 및 작동하는 메서드 주문과 함께 ORDER 클래스에 저장됩니다. 솔루션은 가능한 한 유연하고 후속 작업, IMHO에 대해 확장 가능합니다.
MQL의 그래픽이 있는 작업도 마찬가지입니다. 텍스트 레이블이 하나라면 작업하는 데 문제가 없지만 레이블이 10-100개라면 어떻게 될까요? - 그리고 색 구성표를 변경해야 하는 경우 일부 레이블은 "산호" 색상, 다른 레이블은 "버튼이 있는 자개"로 선택적으로 변경해야 합니까?... 그리고 일주일 후에 3개의 버튼을 더 추가해야 했습니다. ... 그리고 일주일 후에 10 개의 버튼을 제거해야했습니다 ....
추신 : 풍차와의 또 다른 싸움에 대한 주제 .... 아니, 나는 누군가를 기억했습니다 (나는 내 성을 잊었습니다))))-누가 지구가 둥글다고 말했고 그들은 그것을 태워 버렸습니까? )))) - 이것이 문맹 퇴치 및 / 또는 자신의 지평을 넓히는 방법입니다.
제 생각에 mql에는 OOP를 사용하여 해결해야 하는 매우 좁은 작업 세트가 있습니다. 내가 보기에 언어 자체는 C ++의 OOP 또는 다른 것에 지나지 않습니다. 그리고 이 OOP는 OOP를 표준 라이브러리로 제공합니다. 그리고 OOP의이 OOP에 대해 그것을 망칠 것을 제안합니다. 그렇지 않으면 다른 OOP를 말할 수 없습니다. 그리고 한 걸음 더 ... The Sorcerer는 비록 사악하지만 자비로운 내 일을 위해 OOP는 개 차례와 같다고 올바르게 말했습니다. 그리고 이 작업이 절차적 방식으로 문제 없이 해결될 수 있다면 작업을 설정하고 OOP를 통해 구현하는 것이 무슨 소용이겠습니까?
예를 들어, fxsaber에서 .mqh를 사용하여 MT5 및 MT4용 코드를 작성합니다. 누군가는 그것을 필요로 할 수도 있지만 누가 봐... mql5를 마스터하기를 원하지 않거나 완전히 마스터할 수 없는 사람들을 위해. 또는 Nikolay의 iCanvas를 가져오십시오 ..., 나는 그의 성을 잊어 버렸습니다. 이해합니다. 유용한 라이브러리인 것 같지만 알아내기가 쉽지 않고, 설명서도 없고 최소한의 설명도 없습니다. 이것은 불만이 아닙니다. 죄송합니다. Nikolai, 이것은 사실입니다. 그래서 그래픽 레이블을 작성하려고 했을 때 표준 라이브러리나 Nikolai의 라이브러리를 참조하지 않고 작성하는 것이 더 쉬웠습니다.
제 생각에 mql에는 OOP를 사용하여 해결해야 하는 매우 좁은 작업 세트가 있습니다. 내가 보기에 언어 자체는 C ++의 OOP 또는 다른 것에 지나지 않습니다. 그리고 이 OOP는 OOP를 표준 라이브러리로 제공합니다. 그리고 OOP의이 OOP에 대해 그것을 망칠 것을 제안합니다. 그렇지 않으면 다른 OOP를 말할 수 없습니다. 그리고 한 걸음 더 ... The Sorcerer는 비록 사악하지만 자비로운 내 일을 위해 OOP는 개 차례와 같다고 올바르게 말했습니다. 그리고 이 작업이 절차적 방식으로 문제 없이 해결될 수 있다면 작업을 설정하고 OOP를 통해 구현하는 것이 무슨 소용이겠습니까?
불행히도 당신이 90% 옳았지만 트레이더가 작성하도록 요청한 거래 전략 때문에 .... 솔직히 말해서 원시적 인 MQL에서 고품질 그래픽 패널을 만들 수있게되었을 때 약간의 부흥이 있었지만 그 결과 이것은 최종 사용자에게도 필요하지 않았습니다. 일반적으로 청중은 잡종이지만 .... 하나의 버튼만 필요합니다 - 전리품 ...
예를 들어, fxsaber에서 .mqh를 사용하여 MT5 및 MT4용 코드를 작성합니다. 누군가는 그것을 필요로 할 수도 있지만 누가 봐... mql5를 마스터하기를 원하지 않거나 완전히 마스터할 수 없는 사람들을 위해.
이 라이브러리를 사용하는 이유는 MT5가 필요하지만 주문 시스템을 연구하는 데 시간을 낭비하고 싶지는 않습니다. MT5 초보자 분기에서 무엇과 방법을 몇 번이나 물어보려고 했지만... 결과는 부정적입니다. 이 포럼에서는 사실 , MT5 주문 시스템의 작동 방식, 내 질문에 대한 답변 ... 일반적으로 "Jumble이 쉬고 있습니다"에 대한 지식 전달자가 없습니다.
또는 Nikolay의 iCanvas를 가져오십시오 ..., 나는 그의 성을 잊어 버렸습니다. 이해합니다. 유용한 라이브러리인 것 같지만 알아내기가 쉽지 않고, 설명서도 없고 최소한의 설명도 없습니다. 이것은 불만이 아닙니다. 죄송합니다. Nikolai, 이것은 사실입니다. 그래서 그래픽 레이블을 작성하려고 했을 때 표준 라이브러리나 Nikolai의 라이브러리를 참조하지 않고 작성하는 것이 더 쉬웠습니다.
@Nikolai Semko 의 라이브러리를 두어 번 사용했습니다. 특별한 것은 없습니다. 플러그를 꽂고 사용하십시오... 원칙은 KB의 일일 Expert Advisors의 약 99%와 동일합니다. 중재자는 사용하지 않습니다. 거기 주문 시스템에 귀찮게? - OOP 형식으로 작성된 SB를 연결하고 그가 제안하는 조언자를 대량으로 생성
제 생각에 mql에는 OOP를 사용하여 해결해야 하는 매우 좁은 작업 세트가 있습니다. 내가 보기에 언어 자체는 C ++의 OOP 또는 다른 것에 지나지 않습니다. 그리고 이 OOP는 OOP를 표준 라이브러리로 제공합니다. 그리고 OOP의이 OOP에 대해 그것을 망칠 것을 제안합니다. 그렇지 않으면 다른 OOP를 말할 수 없습니다. 그리고 한 걸음 더 ... The Sorcerer는 비록 사악하지만 자비로운 내 일을 위해 OOP는 개 차례와 같다고 올바르게 말했습니다. 그리고 이 작업이 절차적 방식으로 문제 없이 해결될 수 있다면 작업을 설정하고 OOP를 통해 구현하는 것이 무슨 소용이겠습니까?
예를 들어, fxsaber에서 .mqh를 사용하여 MT5 및 MT4용 코드를 작성합니다. 누군가는 그것을 필요로 할 수도 있지만 누가 봐... mql5를 마스터하기를 원하지 않거나 완전히 마스터할 수 없는 사람들을 위해. 또는 Nikolay의 iCanvas를 가져오십시오 ..., 나는 그의 성을 잊어 버렸습니다. 이해합니다. 유용한 라이브러리인 것 같지만 알아내기가 쉽지 않고, 설명서도 없고 최소한의 설명도 없습니다. 이것은 불만이 아닙니다. 죄송합니다. Nikolai, 이것은 사실입니다. 그래서 그래픽 레이블을 작성하려고 했을 때 표준 라이브러리나 Nikolai의 라이브러리를 참조하지 않고 작성하는 것이 더 쉬웠습니다.
OOP의 사용은 알고리즘 거래보다 훨씬 더 높은 수준의 작업 복잡성을 의미합니다. 따라서 분쟁이 있습니다. OOP는 전문 프로그래머와 개발자가 복잡한 프로그램을 작업하는 데 필요합니다. 그렇게 진지하게 접근할 여지가 거의 없습니다. 작은 예를 들어 OOP의 의미를 설명하는 것은 잘못된 것입니다. OOP의 의미는 방대한 양의 데이터와 기능을 가진 대규모 작업에 있습니다. 데이터의 다양성은 분리와 분류를 필요로 하며, 계층으로 구분된 클래스들 사이에 기술, 속성 상속, 메소드 상속을 캡슐화하는 관련성이 있습니다.
작은 작업에서는 이 의미를 설명할 수 없습니다.