OOP는 매우 유연한 방법론이므로 "코어" 개념과 같은 선험적 아이디어가 없습니다. 그러나 OOP를 사용하면 여기에서 논의되는 커널 모델을 아주 잘 구축할 수 있습니다. 따라서 그 진술은 완전히 정확하지 않습니다.
예, 저는 제 자신을 보고 놀랐습니다. Peter는 OOP를 먹는 방법을 설명합니다.
그러나 내가 이해하는 바에 따르면 Peter는 미덕으로서 Core의 모든 속성과 메서드에 대한 전체 액세스 권한을 갖는 사용자의 능력을 제거합니다. 그리고 OOP 스타일은 모든 가능한 방법으로 액세스 권한이 제한되는 캡슐화입니다.
나는 어렸을 때 보호 모드에서 컴퓨터의 모든 메모리를 사용할 수 없다는 사실에 몹시 분개했던 것을 기억합니다. 일부 프로그램은 어떻게 실행되지만 메모리에 액세스할 수 없습니다 ... 액세스할 수 없는 다른 프로세스의 메모리 내용을 가져오는 경우에도 DMA 컨트롤러를 프로그래밍하여 "해결 방법"을 특별히 구축했습니다. (단, 이를 위해서는 PDP 컨트롤러의 포트에 접근하기 위한 명령어를 사용해야 하고, 윈도우 멀티태스킹 환경에서는 이 자체가 쉽지 않기 때문에 저는 특별한 드라이버를 사용했습니다.)
그리고 그제서야 보호 모드, 액세스 공유(그리고 캡슐화만 수행)가 나에게 필요한 매우 중요한 것임을 깨달았습니다. 올라갈 수 없는 곳에 실수로 올라가지 않도록. 그래서 저는 "프로그램의 어느 위치에서든 프로세스는 지금 필요한 리소스, 속성 및 메서드에만 액세스할 수 있어야 합니다"라는 입장에 확고히 서 있습니다.
지나갈 수 없었습니다... 그리고 코드의 이러한 수평 "풋웨어"를 보려면 어떤 모니터 해상도가 필요합니까?
에디터를 들여다보고 스크롤바 를 앞뒤로 움직여 코드를 편집하거나 보는 것은 다소 불편합니다))))
그래서.
내 접근 방식의 첫 번째 이점은 간결함 입니다. 더 적은 단어 - 더 많은 숫자. 객체 는 벡터입니다. 요소 는 행렬 내 벡터의 복소수입니다. 요소의 복합체 - 창. 창의 복합체 - 핵심.
결론은 개체가 그래픽일 필요는 없다는 것입니다. 요소는 개념 이 될 수 있으며 더 적은 수의 개체와 속성이 부여됩니다. 그리고 엔진은 이러한 개념(요소)으로 작업하는 논리적 기계가 될 것입니다.
OOP는 매우 유연한 방법론이므로 "코어" 개념과 같은 선험적 아이디어가 없습니다. 그러나 OOP를 사용하면 여기에서 논의되는 커널 모델을 아주 잘 구축할 수 있습니다. 따라서 그 진술은 완전히 정확하지 않습니다.
예, 저는 제 자신을 보고 놀랐습니다. Peter는 OOP를 먹는 방법을 설명합니다.
그러나 내가 이해하는 바에 따르면 Peter는 미덕으로서 Core의 모든 속성과 메서드에 대한 전체 액세스 권한을 갖는 사용자의 능력을 제거합니다. 그리고 OOP 스타일은 모든 가능한 방법으로 액세스 권한이 제한되는 캡슐화입니다.
나는 어렸을 때 보호 모드에서 컴퓨터의 모든 메모리를 사용할 수 없다는 사실에 몹시 분개했던 것을 기억합니다. 일부 프로그램은 어떻게 실행되지만 메모리에 액세스할 수 없습니다 ... 액세스할 수 없는 다른 프로세스의 메모리 내용을 가져오는 경우에도 DMA 컨트롤러를 프로그래밍하여 "해결 방법"을 특별히 구축했습니다. (단, 이를 위해서는 PDP 컨트롤러의 포트에 접근하기 위한 명령어를 사용해야 하고, 윈도우 멀티태스킹 환경에서는 이 자체가 쉽지 않기 때문에 저는 특별한 드라이버를 사용했습니다.)
그리고 그제서야 보호 모드, 액세스 공유(그리고 캡슐화만 수행)가 나에게 필요한 매우 중요한 것임을 깨달았습니다. 올라갈 수 없는 곳에 실수로 올라가지 않도록. 그래서 저는 "프로그램의 어느 위치에서든 프로세스는 지금 필요한 리소스, 속성 및 메서드에만 액세스할 수 있어야 합니다"라는 입장에 확고히 서 있습니다.
그러나 Peter는 내가 이해하는 것처럼 캡슐화를 지지하는 사람이 아닙니다.
지나갈 수 없었습니다... 그리고 코드의 이러한 수평 "풋웨어"를 보려면 어떤 모니터 해상도가 필요합니까?
어떻게 든 편집기를 들여다보고 스크롤바를 앞뒤로 움직여 코드를 편집하거나 보는 것이 불편합니다))))
내가 말했듯이, 편의성은 내 접근 방식에서 중요한 것이 아닙니다. 가장 중요한 것은 개발 및 적용의 효율성과 잠재력입니다.
내가 말했듯이, 편의성은 내 접근 방식에서 중요한 것이 아닙니다. 가장 중요한 것은 개발 및 적용의 효율성과 잠재력입니다.
좋아요, 더 많은 코드 예제를 기다리겠습니다. 하지만 지금까지는 읽을 수 없는 코드 가 보입니다. 나중에 뭔가 명확해질 것입니다.
OOP는 매우 유연한 방법론이므로 "코어" 개념과 같은 선험적 아이디어가 없습니다. 그러나 OOP를 사용하면 여기에서 논의되는 커널 모델을 아주 잘 구축할 수 있습니다. 따라서 그 진술은 완전히 정확하지 않습니다.
조건부 커널을 구축할 수 있습니다. 나는 진지한 프로그램이 이것을 한다고 생각한다. 그러나 나는 모든 것이 "물리적" 핵심에 구축되어 있습니다.
좋아요, 더 많은 코드 예제를 기다리겠습니다. 하지만 지금까지는 읽을 수 없는 코드 가 보입니다. 나중에 뭔가 명확해질 것입니다.
보다. 표시된 것은 일반적인 예일 뿐입니다. 여기에 더 명확한 버전이 있습니다.
그래서 각각 하나의 버튼 객체의 속성을 가지고 있는 3개의 벡터로 구성된 행렬을 만들었습니다.
그런 다음 이 행렬을 프로토타입으로 사용할 수 있습니다. 다른 모든 버튼이 생성될 템플릿입니다. 최종 버전에서 개체의 일부 값을 변경하기만 하면 새 버튼이 생성됩니다.
원칙적으로 OOP에서도 동일한 작업을 수행할 수 있습니다. 그러나 클래스는 템플릿으로 사용됩니다. 배열을 템플릿으로 사용합니다.
그것이 모든 차이점입니다.
내가 말했듯이, 편의성은 내 접근 방식에서 중요한 것이 아닙니다. 가장 중요한 것은 개발 및 적용의 효율성과 잠재력입니다.
이러한 "풋웨어"( # 9 ) 확인하다?