내 접근 방식. 코어 - 엔진. - 페이지 5

새 코멘트
 
우리는 무엇에 대해 이야기하고 있습니까? 코어에 창, 버튼 등의 구조/클래스 배열이 포함될 수 없는 이유는 무엇입니까? (수사학적).
TV 대신 라디오 부품 한 버킷을 구입하시겠습니까? 마찬가지로 커널은 세부 사항에 신경 쓸 필요가 없습니다. 그러나 그것이 편리한 경우 - 글쎄, 그것은 당신에게 달려 있습니다.
 

엔진은 내가 " Element Focus "라고 부르는 기술을 사용하여 Core와 함께 작동합니다(아주 좋은 이름은 아닐 수도 있음).

결론은 이렇습니다.

차트에서 커서를 이동하여 사용자는 개체의 경계를 넘습니다. 각 요소는 차트 공간에서 고유한 영역을 갖습니다. 특수 기능은 커서의 좌표를 추적하고 커서가 있는 창 및 요소 영역에 대한 메모를 유지합니다.

Core의 Window 및 Element의 번호는 전역 변수 에 기록됩니다. 또한 이를 통해 엔진은 Core에 액세스하여 커서가 위치한 Window, Element 및 Object의 속성에 대한 현재 값을 모두 받습니다.

어떤 이벤트(클릭, 해제, 더블 클릭 등)가 발생하면 이 이벤트를 처리하는 블록에서 이 이벤트가 발생한 창과 요소를 즉시 알 수 있습니다.

Window, Element 및 Object의 주요 속성은 이미 초점이 맞춰져 있으며(즉, 이미 전역 변수에 작성되어 있음) 코드에서 즉시 사용됩니다.

매우 효율적입니다.

그렇기 때문에 커널은 단순한 전역 배열이어야 합니다.
 
Реter Konow :

...

그렇기 때문에 커널은 단순한 전역 배열이어야 합니다.

본질적으로 포인터 배열은 오랫동안 알려져 왔습니다.

자전거의 발명에 많은 노력을 기울였습니다... 모든 것이 훨씬 더 나은 방식으로 오랫동안 존재해 왔습니다.

재미있는 것은 OOP입니다. 사람들에게는 심리적 저항이 많이 있습니다. 클래스를 작성할 필요는 없지만 클래스를 사용하기 위해서만 사용하는 경우에도 마찬가지입니다.

왜 자신을 하나의 코어로 제한합니까? 그러한 핵 접근 방식의 관점에서 OOP는 단지 광포한 커널 생성기일 뿐입니다.

 
Dmitry Fedoseev :

본질적으로 포인터 배열은 오랫동안 알려져 왔습니다.

자전거를 발명하기 위해 많은 노력을 기울였습니다...

이 모든 것이 추가 사용을 수반한다는 것을 이해합니다. 실제로 필요하지 않은 구문입니다. 솔루션에는 이 구문 및 추가가 필요하지 않습니다. 도구.

솔루션은 원시주의 에 간단할 수 있지만 매우 효과적입니다. 그게 바로 내가 하려고 하는 일입니다.

 
Dmitry Fedoseev :

왜 자신을 하나의 코어로 제한합니까? 그러한 핵 접근 방식의 관점에서 OOP는 단지 광포한 커널 생성기일 뿐입니다.

솔루션에 OOP가 필요하지 않은 경우 OOP가 여기에 있는 이유는 무엇입니까?

Windows, 요소, 개체는 Core에서 표현되고 구성됩니다. 배열 인덱스 또는 요소의 초점을 통해 액세스합니다.

솔루션이 이미 존재한다면 왜 포인터, 참조, 클래스, 생성자, 소멸자 및 백만 가지가 더 있습니까?

그것은 간단하고 자급 자족합니다.


OOP는 완전히 다른 것을 위해 필요합니다. 다른 개발자 팀과 함께 이 기술을 만들고 우리 각자가 작업의 일부만 수행했다면 OOP가 필요할 것입니다.

 
Реter Konow :

OOP는 완전히 다른 것을 위해 필요합니다. 다른 개발자 팀과 함께 이 기술을 만들고 우리 각자가 작업의 일부만 수행했다면 OOP가 필요할 것입니다.

자외선 TS 글쎄요, 코드에서 우리 생각의 예를 보겠습니다. OOP가 "악"이라는 사실은 나중에 논의할 것입니다... 그들이 말하는 대로, 스튜디오에 코드입니다! )))

 
  1. OOP는 동일한 프로그램에서 작업하는 개발자 팀의 잘 조정된 상호 작용에 필요합니다.
  2. 개발팀이 작성한 코드를 이해하고 변경하기 위해서는 OOP가 필요합니다.

그러나, - 한 프로그래머가 작업하고 그의 작업 에 OOP를 사용할 필요가 없는 경우에는 OOP 가 필요하지 않습니다.

 
예, 무언가를 끝내려고 할 때 두 달 간의 휴식 후에 기술에 익사하게 될 것입니다. 그리고 스케일링의 복잡성이 명확하지 않았기 때문에 생성자는 분명히 충분히 복잡하지 않습니다.
 
Igor Makanu :

자외선 TS 글쎄요, 코드에서 우리 생각의 예를 보겠습니다. OOP가 "악"이라는 사실은 나중에 논의할 것입니다... 그들이 말하는 대로 스튜디오에 코드입니다! )))

네, 간단한 예시를 준비하겠습니다.

 
Реter Konow :
  1. OOP는 동일한 프로그램에서 작업하는 개발자 팀의 잘 조정된 상호 작용에 필요합니다.
  2. 개발팀이 작성한 코드를 이해하고 변경하기 위해서는 OOP가 필요합니다.

그러나, - 한 프로그래머가 작업하고 그의 작업 에 OOP를 사용할 필요가 없는 경우에는 OOP 가 필요하지 않습니다.

둘 다 거짓입니다.

123456789101112...184
새 코멘트