이것이 실습에서 이론으로 가는 길의 장점입니다. 나도 이 길을 걸었다. 내 직감은 OOP 패러다임을 오랫동안 받아들이지 않았기 때문에 나는 그것이 자연에 존재하지 않을 때 프로그래밍을 시작했습니다. 그러나 이제 나는 이것이 프로그래밍에서 가장 가치 있는 발명이라는 것을 이해합니다. 그리고 때로는 아무도 아직 OOP를 발명하지 않았다면 내가 직접 발명했을 것 같습니다 :)) Peter는 그것을 좋아할 것이고 OOP의 아름다움과 그것이 어떤 기회를 열어주는지 깨닫게 되면 기뻐할 것입니다. 나는 당신을 확신합니다 :)). 특히 프로그래밍 경험이 있는 경우 OOP에는 복잡하고 혼란스러운 것이 없습니다. 그리고 귀하의 경우 Metaquotes 문서 가 본질을 파악하기에 충분할 수도 있습니다. 문학의 바다.
피터 코노우 :
그러나 Nikolai, 나는 여전히 내가 무엇에 대해 묻고 있는지 이해하지 못했습니다. CCcanvas 클래스에서 경계 그라디언트 선의 특정 색상을 설정할 수 있습니까? 귀하의 예를 보면 다음이 있다고 생각할 수 있습니다. 그렇다면 제 예와 유사한 것을 그릴 수 있습니까?
알았어. 알았어. 이것이 이 스레드의 주제는 아니지만 지식이 풍부한 프로그래머에게는 분명해 보이지만 Canvas를 처음 접하는 프로그래머에게는 분명하지 않은 몇 가지 사항을 명확히 하려고 합니다. 그렇다면 캔버스란 무엇인가? 영어에서 번역 - 캔버스. 이것은 단순히 화면이 연결된 창 내의 화면 영역입니다. 주요 특성은 너비(너비) 및 높이(높이)의 크기입니다. 그리고 실제로 이것은 Width*Height 차원의 uint 유형(4바이트) 포인트의 1차원 배열입니다. CCanvas 클래스 구현에서 이 배열은 m_pixels라고 하며 기본적으로 privat(클래스 내부에서만 사용 가능)이지만 개인적으로 항상 공개합니다(클래스 내부뿐만 아니라 사용자에서도 사용 가능). 응용 프로그램), 데이터 배열로 직접 작업하고 싶기 때문입니다. 이 캔버스의 각 점은 모든 RGB 색상의 점을 의미하는 유형 색상 값(uint와 같은 4바이트, 1바이트 예약됨)을 사용할 수 있습니다. 각 색상(빨간색, 녹색 또는 파란색)은 1바이트(256개 값)에 해당하므로 모든 RGB 색상은 256 * 256 * 256 = 16 777 216입니다.
X는 0에서 (Width-1)까지, Y는 0에서 (Height-1)까지의 값을 취할 수 있는 X,Y 좌표에 빨간색 점을 지정하려면 빨간색 값을 숫자가 있는 m_pixels 배열 셀(Y * 너비+X):
다야!!! 이제 CCanvas 클래스의 내장 함수를 사용할 필요조차 없습니다. 화면 어디에나 어떤 색상으로든 점을 찍을 수 있다면 - 당신은 당신이 원하는 신이고, 버튼, 그래픽, 자신만의 GDI 만들기 등을 그립니다. 등.
누군가 캔버스가 느리게 작동한다고 생각한다면 그것은 착각입니다. Canvas는 놀라울 정도로 민첩하며 이것이 개발 팀의 장점입니다. 캔버스의 그리기 속도와 C++로 작성된 Dll 라이브러리를 사용하여 반복적으로 테스트했습니다. 이제 작년 업데이트 이후 MT5의 캔버스는 C++의 Visual Studio에서 작성한 것처럼 거의 빠르게 작동합니다. 10-15%만 느려집니다. 그리고 잊지 마세요. Windows는 C++로 작성되었으며 견고한 Canvas입니다. 이것이 바로 MQL5가 탑재된 MT5의 미덕이자 전망!!! 이 스레드에서 일부가 작성한 것처럼 Java나 C# 모두 이러한 속도를 자랑할 수 없습니다.
개발자가 최근 차트 표시를 비활성화하기 위해 새로운 속성 CHART_SHOW를 도입한 것은 아무 것도 아닙니다. 예제 스크립트로 이것을 보여드리겠습니다.
//+------------------------------------------------------------------+//| CleanScreen.mq5 |//| Copyright 2016, MetaQuotes Software Corp. |//| https://www.mql5.com |//+------------------------------------------------------------------+// Внимание !!! В классе CCanvas массив m_pixels должен быть определен как public#include <Canvas\Canvas.mqh>
voidOnStart ()
{
ChartSetInteger ( 0 ,CHART_SHOW, false ); // очищаем экран от всегоint Width =( int ) ChartGetInteger ( 0 , CHART_WIDTH_IN_PIXELS ); // получаем Ширину экранаint Height=( int ) ChartGetInteger ( 0 , CHART_HEIGHT_IN_PIXELS ); // получаем Высоту экрана
CCanvas C; // создаем объект Canvasif (!C.CreateBitmapLabel( 0 , 0 , "CleanScreen" , 0 , 0 ,Width,Height, COLOR_FORMAT_XRGB_NOALPHA )) // Создаем холст на весь экранPrint ( "Error creating canvas: " , GetLastError ());
// Теперь что-нибудь нарисуем на этом чистом экране// например красную точку в центре экранаint X=Width/ 2 ;
int Y=Height/ 2 ;
C.m_pixels[Y*Width+X]= 0xFF0000 ; // красный// или нарисуем окружность в центре с радиусом 100 по точкам фиолетового цветаint r= 100 ;
int q=( int ) ceil (r* M_SQRT1_2 );
int r2=r*r;
for ( int x= 0 ; x<=q; x++)
{
int y=( int ) round ( sqrt (r2-x*x));
C.m_pixels[(Y+y)*Width+X+x]= 0xFF00FF ;
C.m_pixels[(Y+y)*Width+X-x]= 0xFF00FF ;
C.m_pixels[(Y-y)*Width+X+x]= 0xFF00FF ;
C.m_pixels[(Y-y)*Width+X-x]= 0xFF00FF ;
C.m_pixels[(Y+x)*Width+X+y]= 0xFF00FF ;
C.m_pixels[(Y+x)*Width+X-y]= 0xFF00FF ;
C.m_pixels[(Y-x)*Width+X+y]= 0xFF00FF ;
C.m_pixels[(Y-x)*Width+X-y]= 0xFF00FF ;
}
// конечно же можно окружность построить проще :) - через встроенную функцию класса CCanvas:
C.Circle(X,Y,r+ 20 , 0xFFFF00 ); // желтого цвета
C.Update(); // Теперь выводим это на экран
}
이 스크립트의 작동 방식:
화면은 지워졌지만 따옴표에 대한 액세스는 남아 있으며 이 빈 캔버스를 사용하여 예를 들어 그래디언트를 사용하여 자체 차트 인터페이스를 만들 수 있습니다.
피터 코노우 :
그러나 Nikolai, 나는 여전히 내가 무엇에 대해 묻고 있는지 이해하지 못했습니다. CCcanvas 클래스에서 경계 그라디언트 선의 특정 색상을 설정할 수 있습니까? 귀하의 예를 보면 다음이 있다고 생각할 수 있습니다. 그렇다면 제 예와 유사한 것을 그릴 수 있습니까?
색상은 GButton 클래스 내부에 설정되며 두 가지 색상을 혼합하고 한 색상에서 다른 색상으로 흐르는 색상 배열을 만드는 두 가지 기능도 있습니다. 단지 그라디언트를 위해. 그라디언트의 개념을 정의하기만 하면 됩니다. 내 이해에서 그라디언트(또는 그라디언트 채우기)는 한 색상이 다른 색상으로 부드럽게 흐르는 것입니다. 귀하의 예에는 그라디언트가 없으며 4 가지 색상 만 있습니다. 내 예에서는 GButton 클래스 내부에 이 색상의 밝기가 다른 4가지 추가 색상이 하나의 색상으로 구성되고 그라데이션 채우기를 위해 색상 배열이 형성됩니다. 이것은 클래스의 최종 사용자의 삶을 단순화하기 위해 수행됩니다. 그는 왜 이 꽃의 형성을 귀찮게 했을까요? 당신의 예와 비슷한 것을 그리는 것이 당신의 숙제입니다. Piotr :)) OOP를 의미하는 클래스에 대한 이해를 시작합시다. 행운을 빕니다!
Nikolay, 어제 귀하의 유익한 게시물에 답변하고 싶었지만 제 생각을 모을 수 없었습니다. 이제 나는 마음이 아니라 마음에서 글을 써야 한다는 것을 깨달았습니다. 그렇지 않으면 아무 것도 설명하지 않겠습니다. 물론 주제를 벗어나서 운영자가 삭제하겠지만 그래도 ..
당신이 OOP에 대해 쓰는 것은 영감을 줍니다. 나는 이미 그것을 마스터하려는 진지한 의도로 연구를 시작했습니다. 그런데 공부하는 과정에서 "짧은 길이 있는데 왜 먼 길을 가는가?"라는 범주의 질문에 끊임없이 압도당했습니다. 나는 끊임없이 문제를 해결하는 쉽고 간결하고 명확한 방법을 보았고 마치 그들이 나에게 이렇게 말하는 것 같았습니다. "안돼! OOP에서는 이것은 해결되지 않습니다. 당신은 모든 것을 형식에 따라 품위있고 고상하게 해야 합니다." . 이에 대한 응답으로 저는 스스로에게 "하지만 어때요? 이러한 엔티티가 필요하지 않습니다. 왜 코드에 추가해야 합니까? 불필요합니다. 코드를 압축하고 싶습니다."라고 자문했습니다. 그리고 내 대답은 "아니요! 이것은 전문적이지 않습니다. 이것은 나쁜 코드입니다."였습니다.
나는 OOP의 장점이 나에게 무엇인지 이해하려고 노력하면서 OOP라는 주제에 대해 나 자신과 많은 논쟁을 벌였습니다. 나는 "OOP 없이 문제를 아름답고 쉽게 풀었다면 왜 그것을 사용해야 할까? 내가 간단하고 이해할 수 있는 것을 왜 더 복잡하게 해야 합니까? 필요하지 않은 것을 코드에 어떻게, 어디에, 왜 넣어야합니까?"라고 생각했습니다. ? ". 그런 다음 나는 모든 것을 스스로하고 아주 잘하기 때문에 OOP가 필요하지 않다고 결정했습니다. 모든 것을 스스로하고 아무 것도 연결할 것으로 기대하지 않고 가장 효과적인 솔루션을 찾고 찾을 때 "왜 다른 것이 있습니까?"라는 자연스러운 질문이 생깁니다. OOP는 프로그램에 편의와 질서를 부여하는 것 같습니다. 그렇습니다. 그러나 나는 내 자신의 명령이 있습니다. 자체 구조. 당신의 본질. 자신의 규칙. 왜 거절해야 합니까?
우리 몸이 외부 조직을 거부하는 것처럼 나는 다른 사람의 생각의 산물로 "성장"할 수 없습니다. 모든 곳에서 거부감을 느꼈습니다. OOP는 다른 사람의 생각으로 만든 주문이었고 효율성 테스트를 통과하지 못했습니다. 이 테스트는 저에게 결정적인 요소였습니다. OOP를 사용하면 내 방식대로 모든 문제를 스스로 해결하는 것보다 약한 프로그래머가 될 것이라는 것을 깨달았습니다. 나의 "소프트웨어 강점"은 내가 이해할 수 있는 러시아어로 작성하고, "커널"이라고 부르는 그래픽 개체에 대한 공통 글로벌 메모리를 사용하고, 이 코어와 함께 작동하는 크고 복잡한 메커니즘을 만드는 것입니다. 이것이 나의 접근 방식이 있는 곳입니다.
누군가가 이 접근 방식으로 나를 이길 때까지 나는 OOP를 프로그래밍하지 않을 것입니다. 그들이 내가 하는 일을 할 때까지, 그러나 훨씬 더 효율적입니다.
실제로 내 메커니즘이 더 효율적인 이유를 이해하고 싶었기 때문에 캔버스에 대해 물었습니다. 이론이나 코드의 아름다움이 아니라 실제로 그렇습니다.
누군가가 이 접근 방식으로 나를 이길 때까지 나는 OOP를 프로그래밍하지 않을 것입니다. 그들이 내가 하는 일을 할 때까지, 그러나 훨씬 더 효율적입니다.
실제로 내 메커니즘이 더 효율적인 이유를 이해하고 싶었기 때문에 캔버스에 대해 물었습니다. 이론이나 코드의 아름다움이 아니라 실제로 그렇습니다.
어쨌든, 영감을 주고 지도해 준 Nikolai에게 감사드립니다. ))
동일한 경험과 지능을 가진 두 명의 프로그래머가 경쟁하면 유사한 대규모 프로젝트가 생성됩니다. 그러나 첫 번째는 함수만 사용하고 두 번째는 함수와 클래스를 사용합니다. 확실히 승리는 두 번째 것입니다. 그러나 반복합니다. 이것이 방대한 프로젝트라면 그는 단순히 더 빨리 만들 것입니다. 더 적은 버그와 더 많은 주문이 있을 것입니다. 그리고 두 번째 제품은 더 읽기 쉽고 유지 관리가 쉬우며 더 쉽게 업데이트되고 보충될 것입니다. 제 의견도 아니고 그냥 사실대로 말한겁니다. 삽보다 삽으로 구멍을 파는 것이 더 쉽습니다. 기능뿐만 아니라 클래스에서도 메커니즘을 구현하면 더 효율적일 것입니다. 여기 내 IMHO입니다.
그리고 Peter, 나는 당신의 코드를 간략하게 보았고 당신이 힘과 주와 함께 캔버스를 사용하고 있다는 것을 깨달았습니다 (CCanvas 클래스는 아니지만 차이점은 무엇입니까). 그렇다면 왜 캔버스에 대한 이 모든 질문과 내가 왜 여기에 십자가에 못 박혔습니까? :)).
))) 글쎄, 내가 왜 이 주제를 시작했지? ) 나는 이제 OOP를 공부할 것이다.
이것이 실습에서 이론으로 가는 길의 장점입니다. 나도 이 길을 걸었다. 내 직감은 OOP 패러다임을 오랫동안 받아들이지 않았기 때문에 나는 그것이 자연에 존재하지 않을 때 프로그래밍을 시작했습니다. 그러나 이제 나는 이것이 프로그래밍에서 가장 가치 있는 발명이라는 것을 이해합니다. 그리고 때로는 아무도 아직 OOP를 발명하지 않았다면 내가 직접 발명했을 것 같습니다 :))
Peter는 그것을 좋아할 것이고 OOP의 아름다움과 그것이 어떤 기회를 열어주는지 깨닫게 되면 기뻐할 것입니다. 나는 당신을 확신합니다 :)). 특히 프로그래밍 경험이 있는 경우 OOP에는 복잡하고 혼란스러운 것이 없습니다. 그리고 귀하의 경우 Metaquotes 문서 가 본질을 파악하기에 충분할 수도 있습니다. 문학의 바다.
그러나 Nikolai, 나는 여전히 내가 무엇에 대해 묻고 있는지 이해하지 못했습니다. CCcanvas 클래스에서 경계 그라디언트 선의 특정 색상을 설정할 수 있습니까? 귀하의 예를 보면 다음이 있다고 생각할 수 있습니다. 그렇다면 제 예와 유사한 것을 그릴 수 있습니까?
알았어. 알았어. 이것이 이 스레드의 주제는 아니지만 지식이 풍부한 프로그래머에게는 분명해 보이지만 Canvas를 처음 접하는 프로그래머에게는 분명하지 않은 몇 가지 사항을 명확히 하려고 합니다.
그렇다면 캔버스란 무엇인가? 영어에서 번역 - 캔버스. 이것은 단순히 화면이 연결된 창 내의 화면 영역입니다. 주요 특성은 너비(너비) 및 높이(높이)의 크기입니다. 그리고 실제로 이것은 Width*Height 차원의 uint 유형(4바이트) 포인트의 1차원 배열입니다. CCanvas 클래스 구현에서 이 배열은 m_pixels라고 하며 기본적으로 privat(클래스 내부에서만 사용 가능)이지만 개인적으로 항상 공개합니다(클래스 내부뿐만 아니라 사용자에서도 사용 가능). 응용 프로그램), 데이터 배열로 직접 작업하고 싶기 때문입니다. 이 캔버스의 각 점은 모든 RGB 색상의 점을 의미하는 유형 색상 값(uint와 같은 4바이트, 1바이트 예약됨)을 사용할 수 있습니다. 각 색상(빨간색, 녹색 또는 파란색)은 1바이트(256개 값)에 해당하므로 모든 RGB 색상은 256 * 256 * 256 = 16 777 216입니다.
X는 0에서 (Width-1)까지, Y는 0에서 (Height-1)까지의 값을 취할 수 있는 X,Y 좌표에 빨간색 점을 지정하려면 빨간색 값을 숫자가 있는 m_pixels 배열 셀(Y * 너비+X):
m_pixels[Y*Width+X]= clrRed ;또는 동일한 것은 무엇입니까?
다야!!!
이제 CCanvas 클래스의 내장 함수를 사용할 필요조차 없습니다. 화면 어디에나 어떤 색상으로든 점을 찍을 수 있다면 - 당신은 당신이 원하는 신이고, 버튼, 그래픽, 자신만의 GDI 만들기 등을 그립니다. 등.
누군가 캔버스가 느리게 작동한다고 생각한다면 그것은 착각입니다. Canvas는 놀라울 정도로 민첩하며 이것이 개발 팀의 장점입니다. 캔버스의 그리기 속도와 C++로 작성된 Dll 라이브러리를 사용하여 반복적으로 테스트했습니다. 이제 작년 업데이트 이후 MT5의 캔버스는 C++의 Visual Studio에서 작성한 것처럼 거의 빠르게 작동합니다. 10-15%만 느려집니다. 그리고 잊지 마세요. Windows는 C++로 작성되었으며 견고한 Canvas입니다. 이것이 바로 MQL5가 탑재된 MT5의 미덕이자 전망!!! 이 스레드에서 일부가 작성한 것처럼 Java나 C# 모두 이러한 속도를 자랑할 수 없습니다.
개발자가 최근 차트 표시를 비활성화하기 위해 새로운 속성 CHART_SHOW를 도입한 것은 아무 것도 아닙니다.
예제 스크립트로 이것을 보여드리겠습니다.
이 스크립트의 작동 방식:
화면은 지워졌지만 따옴표에 대한 액세스는 남아 있으며 이 빈 캔버스를 사용하여 예를 들어 그래디언트를 사용하여 자체 차트 인터페이스를 만들 수 있습니다.
그러나 Nikolai, 나는 여전히 내가 무엇에 대해 묻고 있는지 이해하지 못했습니다. CCcanvas 클래스에서 경계 그라디언트 선의 특정 색상을 설정할 수 있습니까? 귀하의 예를 보면 다음이 있다고 생각할 수 있습니다. 그렇다면 제 예와 유사한 것을 그릴 수 있습니까?
당신의 예와 비슷한 것을 그리는 것이 당신의 숙제입니다. Piotr :)) OOP를 의미하는 클래스에 대한 이해를 시작합시다.
행운을 빕니다!
행운을 빕니다!
좋아, 니콜라이. 당신에게도 감사하고 행운을 빕니다!
Nikolay, 어제 귀하의 유익한 게시물에 답변하고 싶었지만 제 생각을 모을 수 없었습니다. 이제 나는 마음이 아니라 마음에서 글을 써야 한다는 것을 깨달았습니다. 그렇지 않으면 아무 것도 설명하지 않겠습니다. 물론 주제를 벗어나서 운영자가 삭제하겠지만 그래도 ..
당신이 OOP에 대해 쓰는 것은 영감을 줍니다. 나는 이미 그것을 마스터하려는 진지한 의도로 연구를 시작했습니다. 그런데 공부하는 과정에서 "짧은 길이 있는데 왜 먼 길을 가는가?"라는 범주의 질문에 끊임없이 압도당했습니다. 나는 끊임없이 문제를 해결하는 쉽고 간결하고 명확한 방법을 보았고 마치 그들이 나에게 이렇게 말하는 것 같았습니다. "안돼! OOP에서는 이것은 해결되지 않습니다. 당신은 모든 것을 형식에 따라 품위있고 고상하게 해야 합니다." . 이에 대한 응답으로 저는 스스로에게 "하지만 어때요? 이러한 엔티티가 필요하지 않습니다. 왜 코드에 추가해야 합니까? 불필요합니다. 코드를 압축하고 싶습니다."라고 자문했습니다. 그리고 내 대답은 "아니요! 이것은 전문적이지 않습니다. 이것은 나쁜 코드입니다."였습니다.
나는 OOP의 장점이 나에게 무엇인지 이해하려고 노력하면서 OOP라는 주제에 대해 나 자신과 많은 논쟁을 벌였습니다. 나는 "OOP 없이 문제를 아름답고 쉽게 풀었다면 왜 그것을 사용해야 할까? 내가 간단하고 이해할 수 있는 것을 왜 더 복잡하게 해야 합니까? 필요하지 않은 것을 코드에 어떻게, 어디에, 왜 넣어야합니까?"라고 생각했습니다. ? ". 그런 다음 나는 모든 것을 스스로하고 아주 잘하기 때문에 OOP가 필요하지 않다고 결정했습니다. 모든 것을 스스로하고 아무 것도 연결할 것으로 기대하지 않고 가장 효과적인 솔루션을 찾고 찾을 때 "왜 다른 것이 있습니까?"라는 자연스러운 질문이 생깁니다. OOP는 프로그램에 편의와 질서를 부여하는 것 같습니다. 그렇습니다. 그러나 나는 내 자신의 명령이 있습니다. 자체 구조. 당신의 본질. 자신의 규칙. 왜 거절해야 합니까?
우리 몸이 외부 조직을 거부하는 것처럼 나는 다른 사람의 생각의 산물로 "성장"할 수 없습니다. 모든 곳에서 거부감을 느꼈습니다. OOP는 다른 사람의 생각으로 만든 주문이었고 효율성 테스트를 통과하지 못했습니다. 이 테스트는 저에게 결정적인 요소였습니다. OOP를 사용하면 내 방식대로 모든 문제를 스스로 해결하는 것보다 약한 프로그래머가 될 것이라는 것을 깨달았습니다. 나의 "소프트웨어 강점"은 내가 이해할 수 있는 러시아어로 작성하고, "커널"이라고 부르는 그래픽 개체에 대한 공통 글로벌 메모리를 사용하고, 이 코어와 함께 작동하는 크고 복잡한 메커니즘을 만드는 것입니다. 이것이 나의 접근 방식이 있는 곳입니다.
누군가가 이 접근 방식으로 나를 이길 때까지 나는 OOP를 프로그래밍하지 않을 것입니다. 그들이 내가 하는 일을 할 때까지, 그러나 훨씬 더 효율적입니다.
실제로 내 메커니즘이 더 효율적인 이유를 이해하고 싶었기 때문에 캔버스에 대해 물었습니다. 이론이나 코드의 아름다움이 아니라 실제로 그렇습니다.
어쨌든 영감을 주고 지도해 준 Nikolai에게 감사드립니다. ))
...
누군가가 이 접근 방식으로 나를 이길 때까지 나는 OOP를 프로그래밍하지 않을 것입니다.
...
이 사람은 아마도 당신이 상상 속에서 그토록 치열하게 싸우는 풍차 중 하나일 것입니다. )
이 사람은 아마도 당신이 상상 속에서 그토록 치열하게 싸우는 풍차 중 하나일 것입니다. )
잘! 트롤들이 뛰노는데...
나는 절대적으로 OOP의 팬이 아니지만 최소한 독학을 위해 스스로를 프로그래머라고 생각한다면 OOP를 분명히 알고 사용할 수 있어야 합니다.
그러나 적용된 문제를 해결하기 위해 사용하거나 사용하지 않는 것은 전적으로 귀하의 비즈니스입니다.
진정해 피터. 이것들은 단지 그라인더입니다. 그들은 단지 서서 특정 기능을 수행하고 당신을 물리 치려고하지 않습니다. 그러나 그것이 당신의 풍부한 상상력에 어떻게 시각화되는지 누가 압니까? 분명히, 그것은 매우 인상적입니다. )
Anatoly, 풍차든 아니든, 나는 싸우고 이기기를 좋아합니다. 특히 내가 잘하는 것. 저는 실시간 경쟁, 싸움 등을 좋아합니다... 모두 진화와 자연 선택의 일부입니다. 그러니 괜찮아... 가장 중요한 것은 규칙이 공정하다는 것입니다.
같은 생각을 가진 사람들과 협업하고, 공동 프로젝트에 참여하고, 팀으로 일하는 것도 멋집니다. 물론 상상이 현실을 대체해서는 안 됩니다. 그런 뜻이라면 동의합니다.
... 하지만 적어도 독학을 위해서라면 스스로를 프로그래머라고 생각한다면 간단하게 알고 명확하게 사용할 수 있어야 합니다.
그러나 적용된 문제를 해결하기 위해 사용하거나 사용하지 않는 것은 전적으로 귀하의 비즈니스입니다.
누군가가 이 접근 방식으로 나를 이길 때까지 나는 OOP를 프로그래밍하지 않을 것입니다. 그들이 내가 하는 일을 할 때까지, 그러나 훨씬 더 효율적입니다.
실제로 내 메커니즘이 더 효율적인 이유를 이해하고 싶었기 때문에 캔버스에 대해 물었습니다. 이론이나 코드의 아름다움이 아니라 실제로 그렇습니다.
어쨌든, 영감을 주고 지도해 준 Nikolai에게 감사드립니다. ))
동일한 경험과 지능을 가진 두 명의 프로그래머가 경쟁하면 유사한 대규모 프로젝트가 생성됩니다. 그러나 첫 번째는 함수만 사용하고 두 번째는 함수와 클래스를 사용합니다. 확실히 승리는 두 번째 것입니다. 그러나 반복합니다. 이것이 방대한 프로젝트라면 그는 단순히 더 빨리 만들 것입니다. 더 적은 버그와 더 많은 주문이 있을 것입니다. 그리고 두 번째 제품은 더 읽기 쉽고 유지 관리가 쉬우며 더 쉽게 업데이트되고 보충될 것입니다. 제 의견도 아니고 그냥 사실대로 말한겁니다. 삽보다 삽으로 구멍을 파는 것이 더 쉽습니다. 기능뿐만 아니라 클래스에서도 메커니즘을 구현하면 더 효율적일 것입니다. 여기 내 IMHO입니다.
그리고 Peter, 나는 당신의 코드를 간략하게 보았고 당신이 힘과 주와 함께 캔버스를 사용하고 있다는 것을 깨달았습니다 (CCanvas 클래스는 아니지만 차이점은 무엇입니까). 그렇다면 왜 캔버스에 대한 이 모든 질문과 내가 왜 여기에 십자가에 못 박혔습니까? :)).