OOP는 검사 및 승인의 상당 부분을 컴파일러로 이전할 수 있는 메커니즘입니다. 그러나 그것을 사용하려면 추가 노력이 필요합니다.
그러나 이러한 모든 확인과 승인이 필요하지 않다면 OOP는 의미가 없습니다.
예를 들어, 그래픽 코어의 다차원 배열 로 작업하는 것이 두려울 것입니다. 현재 필요하지 않은 추가 요소가 너무 많기 때문입니다. 그것들은 주의를 산만하게 하고 계산하기 어려운 오류를 유발합니다. 간단한 컴팩트 인터페이스에서 액세스할 수 있는 개체 집합으로 대체할 것입니다. 인터페이스를 받은 후 - 아무 것도 기억할 필요가 없음 - 인터페이스 자체가 나를 제한하고 잘못된 필드나 개체를 참조하는 것을 허용하지 않습니다. 그래픽 코어 어레이의 경우 이러한 호소가 매우 가능합니다.
즉, 블록이 인터페이스를 수신하는 경우 컴파일러 자체가 불필요한 모든 엔티티를 "차단"하고 사용자가 실수를 하도록 허용하지 않습니다. 동일한 그래픽 코어 배열을 사용하면 사용자가 쉽게 실수할 수 있는 많은 추가 정보를 갖게 됩니다.
내 자신의 경험을 통해 컴파일러 자체가 현재 블록에서 맞지 않아야 하는 위치에 맞지 않도록 컴파일러 자체가 나를 모니터링하는 것이 훨씬 낫다는 것을 알고 있습니다. 그리고 그래픽 코어 어레이와 함께 - 나는 그것을 기억해야 합니다. 내 시스템의 마이너스는 플러스의 연속입니다. 현재 작업의 범위를 벗어나는 블록에 갑자기 무언가가 필요한 경우 그래픽 코어 배열로 모든 것이 간단합니다. 필요한 데이터를 가져와서 작업합니다. 그러나 OOP 인터페이스를 사용하면 추가 인터페이스에서 필요한 데이터를 요청하거나 (훨씬 더 불쾌한) 기존 인터페이스를 수정해야 합니다.
Nikolai Semko : 그러면 주제가 다르게 들릴 것입니다. "프로그래밍의 새로운 도구" 또는 "새로운 프로그래밍 패러다임"과 같은 것... OOP보다 멋진 걸 만들었다면, 유명해지면 싸인해주실 거죠?
괜찮아요! 친구의 사인은 불쌍하지 않습니다.))))
농담이시겠지만 제 상상으로는 "엄마는 울지 마세요"라는 접근 방식으로 그런 관점이 그려집니다. 시간이 지남에 따라 시스템의 자체 개선 메커니즘을 시작할 수 있을 것 같습니다. 논리적 코어를 만들어 강제로 다양한 메커니즘을 무작위로 생성하게 하면. 그런 다음 선택을 수행하고 올바른 것을 선택하십시오. 그런 다음 그것들을 조금 다듬으세요... 코어 덕분에 놀라운 일을 할 수 있습니다.
OOP는 검사 및 승인의 상당 부분을 컴파일러로 이전할 수 있는 메커니즘입니다. 그러나 그것을 사용하려면 추가 노력이 필요합니다.
그러나 이러한 모든 확인과 승인이 필요하지 않다면 OOP는 의미가 없습니다.
예를 들어, 그래픽 코어의 다차원 배열 로 작업하는 것이 두려울 것입니다. 현재 필요하지 않은 추가 요소가 너무 많기 때문입니다. 그것들은 주의를 산만하게 하고 계산하기 어려운 오류를 유발합니다. 간단한 컴팩트 인터페이스에서 액세스할 수 있는 개체 집합으로 대체할 것입니다. 인터페이스를 받은 후 - 아무 것도 기억할 필요가 없음 - 인터페이스 자체가 나를 제한하고 잘못된 필드나 개체를 참조하는 것을 허용하지 않습니다. 그래픽 코어 어레이의 경우 이러한 호소가 매우 가능합니다.
즉, 블록이 인터페이스를 수신하는 경우 컴파일러 자체가 불필요한 모든 엔티티를 "차단"하고 사용자가 실수를 하도록 허용하지 않습니다. 동일한 그래픽 코어 배열을 사용하면 사용자가 쉽게 실수할 수 있는 많은 추가 정보를 갖게 됩니다.
내 자신의 경험을 통해 컴파일러 자체가 현재 블록에서 맞지 않아야 하는 위치에 맞지 않도록 컴파일러 자체가 나를 모니터링하는 것이 훨씬 낫다는 것을 알고 있습니다. 그리고 그래픽 코어 어레이와 함께 - 나는 그것을 기억해야 합니다. 내 시스템의 마이너스는 플러스의 연속입니다. 현재 작업의 범위를 벗어나는 블록에 갑자기 무언가가 필요한 경우 그래픽 코어 배열로 모든 것이 간단합니다. 필요한 데이터를 가져와서 작업합니다. 그러나 OOP 인터페이스를 사용하면 추가 인터페이스에서 필요한 데이터를 요청하거나 (훨씬 더 불쾌한) 기존 인터페이스를 수정해야 합니다.
핵심에 불필요한 것이 있다고 생각하는 것은 완전히 잘못된 것입니다. 정의를 통해 인간의 언어로 옷을 입기 때문에 본질을 암기하는 것이 매우 쉽습니다. 모든 것이 거기에 수집되지만 이 콘텐츠에는 명확하고 불변하는 순서가 있습니다. 개체, 창, 요소의 속성은 프로그램의 어느 지점에서나 직접 액세스할 수 있습니다. 그리고 사이클의 코어 덕분에 어떤 기적이 일어날 수 있는지 ...
핵심에 불필요한 것이 있다고 생각하는 것은 완전히 잘못된 것입니다. 정의를 통해 인간의 언어로 옷을 입기 때문에 본질을 암기하는 것이 매우 쉽습니다. 모든 것이 거기에 수집되지만 이 콘텐츠에는 명확하고 불변하는 순서가 있습니다. 개체, 창, 요소의 속성은 프로그램의 어느 지점에서나 직접 액세스할 수 있습니다. 그리고 사이클의 코어 덕분에 어떤 기적이 일어날 수 있는지 ...
'커널에 불필요한 것이 있다'는 게 아니라 '현재로서는 필요하지 않다'고 했다. 그래프 선으로 작업하는 경우 창 속성에 액세스할 수 없어야 합니다.
이러한 모든 속성이 프로그램의 어느 지점에서나 직접 액세스할 수 있다는 사실이 접근 방식의 주요 단점입니다. 프로그램의 어느 곳에서든 현재 이 특정 위치에 필요한 요소에만 액세스해야 합니다. 다른 모든 것은 사용할 수 없어야 합니다. 이를 통해 많은 오류를 자동으로 피할 수 있습니다.
내 생각에 "전체 코어의 가용성으로 인해 수행할 수 있는 기적"은 찾기 어려운 버그 및 코드 이해 문제의 잠재적 원인입니다. 우리는 이러한 모든 속임수를 피하려고 노력해야 합니다.
이 접근 방식은 포인터, 증분, 링크가 거친 혼합으로 한 줄에 작성될 때 어리석은 퍼즐을 생각나게 합니다. 아마도 언어의 관점에서 볼 때 정확하지만 완전히 읽을 수는 없습니다. 예, 위에서 자체 기능을 제공했는데 완전히 미친 것처럼 보입니다. 이 경우 컴팩트가 더 중요하다고 생각했습니다.
'커널에 불필요한 것이 있다'는 게 아니라 '현재로서는 필요하지 않다'고 했다. 그래프 선으로 작업하는 경우 창 속성에 액세스할 수 없어야 합니다.
이러한 모든 속성이 프로그램의 어느 지점에서나 직접 액세스할 수 있다는 사실이 접근 방식의 주요 단점입니다. 프로그램의 어느 곳에서든 현재 이 특정 위치에 필요한 요소에만 액세스해야 합니다. 다른 모든 것은 사용할 수 없어야 합니다. 이를 통해 많은 오류를 자동으로 피할 수 있습니다.
내 생각에 "전체 코어의 가용성으로 인해 수행할 수 있는 기적"은 찾기 어려운 버그 및 코드 이해 문제의 잠재적 원인입니다. 우리는 이러한 모든 속임수를 피하려고 노력해야 합니다.
이 접근 방식은 포인터, 증분, 링크가 거친 혼합으로 한 줄에 작성될 때 어리석은 퍼즐을 생각나게 합니다. 아마도 언어의 관점에서 볼 때 정확하지만 완전히 읽을 수는 없습니다. 예, 위에서 자체 기능을 제공했는데 완전히 미친 것처럼 보입니다. 이 경우 컴팩트가 더 중요하다고 생각했습니다.
당신은 당신이 말하는 기술과 관련이 없는 당신의 경험에 기반한 순간적인 이론적인 아이디어를 기반으로 커널에 대해 이야기합니다. 여기에서 액세스, 엔티티 암기에 대한 몇 가지 문제가 있습니다 ...
나는 이 기술에 대한 실질적인 경험을 바탕으로 주장하는 것이며, 접근이나 제한에 그런 문제는 없다고 말씀드립니다. 솔직히 말씀드리면 어떤 종류의 액세스 문제를 말씀하시는지 이해가 되지 않습니다. 그런 문제는 없고 그런 적도 없습니다.
귀하가 의미하는 액세스 문제에 대해 자세히 알려주십시오.
액세스를 제한해야 한다고 결정한 이유는 무엇입니까? 그렇지 않으면 오류가 발생합니까? 저에게 이것은 새로운 것입니다.
절차 코드의 전역 배열에 직접 액세스하면 자체적으로 찾기 어려운 버그가 발생할 수 있습니까?
당신은 당신이 말하는 기술과 관련이 없는 당신의 경험에 기반한 순간적인 이론적인 아이디어를 기반으로 커널에 대해 이야기합니다. 따라서 액세스, 엔티티 기억에 몇 가지 문제가 있습니다 ...
나는 이 기술에 대한 실질적인 경험을 바탕으로 주장하는 것이며, 접근이나 제한에 그런 문제는 없다고 말씀드립니다. 솔직히 말씀드리면 어떤 종류의 액세스 문제를 말씀하시는지 이해가 되지 않습니다. 그런 문제는 없고 그런 적도 없습니다.
그러나 "어디서나 모든 것이 가능하다"고 말한다면 어떻게 "문제없다"가 있을 수 있겠는가?
이것이 주요 문제입니다! 사용할 수 없어야합니다!
결론은 액세스 제어 작업을 컴파일러로 옮기는 것입니다. 그리고 당신에게 - 모든 것이 열려 있고 액세스 제어는 프로그래머가 수행합니다.
모든 것을 기억하기 때문에 어려움은 없었습니다. 이미 익숙합니다. 아무 것도 없습니다. 시간이 지나면서 메모리가 고장나기 시작한다는 것을 알게 될 것입니다. 그런 다음 컴파일러의 액세스 제어 기능을 평가하게 될 것입니다. 기억이 안나네요. 그리고 나는 대다수가 몇 달 전에 작성된 것이 어떻게 작동하는지 주기적으로 잊어 버릴 것이라고 생각합니다. 이러한 조건에서 액세스 제어가 장점이 됩니다.
예를 들어 주문을 담당하는 블록 안에 있으면 주문만 할 수 있습니다. 그리고 당신은 그래프를 그릴 능력이 없습니다. 차트 그리기를 담당하는 블록에 있는 경우 그곳에서 주문할 수 없습니다. 이것은 작업을 크게 단순화합니다. 그리고 차트 그리기 기능에서 갑자기 주문 요청이 표시되면 오랫동안 왜 그렇게 했는지 기억해야 합니다. 왜 그런 결정을 내렸는지에 대한 자세한 설명이 있으면 좋겠지만.. 하지만 이런 목적을 위해 특별히 설계된 한 블록에 주문을 하면 더 좋다.
그러나 "어디서나 모든 것이 가능하다"고 말한다면 어떻게 "문제없다"가 있을 수 있겠는가?
이것이 주요 문제입니다! 사용할 수 없어야합니다!
결론은 액세스 제어 작업을 컴파일러로 옮기는 것입니다. 그리고 당신에게 - 모든 것이 열려 있고 액세스 제어는 프로그래머가 수행합니다.
모든 것을 기억하기 때문에 어려움은 없었습니다. 이미 익숙합니다. 아무 것도 없습니다. 시간이 지나면서 메모리가 고장나기 시작한다는 것을 알게 될 것입니다. 그런 다음 컴파일러의 액세스 제어 기능을 평가하게 될 것입니다. 기억이 안나네요. 그리고 나는 대다수가 몇 달 전에 작성된 것이 어떻게 작동하는지 주기적으로 잊어 버릴 것이라고 생각합니다. 이러한 조건에서 액세스 제어가 유용합니다.
예를 들어 주문을 담당하는 블록 안에 있으면 주문만 할 수 있습니다. 그리고 당신은 그래프를 그릴 능력이 없습니다. 차트 그리기를 담당하는 블록에 있는 경우 그곳에서 주문할 수 없습니다. 이것은 작업을 크게 단순화합니다. 그리고 차트 그리기 기능에서 갑자기 주문 요청이 표시되면 오랫동안 왜 그렇게 했는지 기억해야 합니다. 왜 그런 결정을 내렸는지에 대한 자세한 설명이 있으면 좋겠지만.. 하지만 이런 목적을 위해 특별히 설계된 한 블록에 주문을 하면 더 좋다.
함수형 절차적 프로그래밍에서는 당신이 설명하는 접근 문제가 존재하지 않습니다. 함수 오버로딩도 없고, 필드와 객체도 없고, 포인터와 다른 것도 없고, 어디에서나 액세스할 수 있는 모든 전역 변수 에 대해 하나의 메모리만 있을 때 어떻게 잘못된 함수를 호출할 수 있습니까? 어떤 액세스 관련 오류가 발생할 수 있습니까? 예, 기억하기가 훨씬 쉽습니다.
예, 생각할 것이 없습니다.
OOP는 검사 및 승인의 상당 부분을 컴파일러로 이전할 수 있는 메커니즘입니다. 그러나 그것을 사용하려면 추가 노력이 필요합니다.
그러나 이러한 모든 확인과 승인이 필요하지 않다면 OOP는 의미가 없습니다.
예를 들어, 그래픽 코어의 다차원 배열 로 작업하는 것이 두려울 것입니다. 현재 필요하지 않은 추가 요소가 너무 많기 때문입니다. 그것들은 주의를 산만하게 하고 계산하기 어려운 오류를 유발합니다. 간단한 컴팩트 인터페이스에서 액세스할 수 있는 개체 집합으로 대체할 것입니다. 인터페이스를 받은 후 - 아무 것도 기억할 필요가 없음 - 인터페이스 자체가 나를 제한하고 잘못된 필드나 개체를 참조하는 것을 허용하지 않습니다. 그래픽 코어 어레이의 경우 이러한 호소가 매우 가능합니다.
즉, 블록이 인터페이스를 수신하는 경우 컴파일러 자체가 불필요한 모든 엔티티를 "차단"하고 사용자가 실수를 하도록 허용하지 않습니다. 동일한 그래픽 코어 배열을 사용하면 사용자가 쉽게 실수할 수 있는 많은 추가 정보를 갖게 됩니다.
내 자신의 경험을 통해 컴파일러 자체가 현재 블록에서 맞지 않아야 하는 위치에 맞지 않도록 컴파일러 자체가 나를 모니터링하는 것이 훨씬 낫다는 것을 알고 있습니다. 그리고 그래픽 코어 어레이와 함께 - 나는 그것을 기억해야 합니다. 내 시스템의 마이너스는 플러스의 연속입니다. 현재 작업의 범위를 벗어나는 블록에 갑자기 무언가가 필요한 경우 그래픽 코어 배열로 모든 것이 간단합니다. 필요한 데이터를 가져와서 작업합니다. 그러나 OOP 인터페이스를 사용하면 추가 인터페이스에서 필요한 데이터를 요청하거나 (훨씬 더 불쾌한) 기존 인터페이스를 수정해야 합니다.
예, 생각할 것이 없습니다.
OOP는 검사 및 승인의 상당 부분을 컴파일러로 이전할 수 있는 메커니즘입니다. 그러나 그것을 사용하려면 추가 노력이 필요합니다.
그러나 이러한 모든 확인과 승인이 필요하지 않다면 OOP는 의미가 없습니다.
왜 그렇게 쉽게 만드십시오. 가시성과 가독성은 어떻습니까? 그리고 오류 감지 및 수정의 단순화? 휴대성은 어떻습니까? 그리고 현대화의 단순화? 등. 등. ....
그러면 주제가 다르게 들릴 것입니다. "프로그래밍의 새로운 도구" 또는 "새로운 프로그래밍 패러다임"과 같은 것...
OOP보다 멋진 걸 만들었다면, 유명해지면 싸인해주실 거죠?
괜찮아요! 친구의 사인은 불쌍하지 않습니다.))))
농담이시겠지만 제 상상으로는 "엄마는 울지 마세요"라는 접근 방식으로 그런 관점이 그려집니다. 시간이 지남에 따라 시스템의 자체 개선 메커니즘을 시작할 수 있을 것 같습니다. 논리적 코어를 만들어 강제로 다양한 메커니즘을 무작위로 생성하게 하면. 그런 다음 선택을 수행하고 올바른 것을 선택하십시오. 그런 다음 그것들을 조금 다듬으세요... 코어 덕분에 놀라운 일을 할 수 있습니다.
왜 그렇게 쉽게 만드십시오. 가시성과 가독성은 어떻습니까? 그리고 오류 감지 및 수정의 단순화? 휴대성은 어떻습니까? 그리고 현대화의 단순화? 등. 등. ....
고귀한 광고 배너 :-) "우리 코끼리를 사세요"
위의 모든 테제는 OOP와 동등하게 관련이 있으며 OOP 및 FP와 일반적으로 어디에서나 관련이 없습니다.
예, 생각할 것이 없습니다.
OOP는 검사 및 승인의 상당 부분을 컴파일러로 이전할 수 있는 메커니즘입니다. 그러나 그것을 사용하려면 추가 노력이 필요합니다.
그러나 이러한 모든 확인과 승인이 필요하지 않다면 OOP는 의미가 없습니다.
예를 들어, 그래픽 코어의 다차원 배열 로 작업하는 것이 두려울 것입니다. 현재 필요하지 않은 추가 요소가 너무 많기 때문입니다. 그것들은 주의를 산만하게 하고 계산하기 어려운 오류를 유발합니다. 간단한 컴팩트 인터페이스에서 액세스할 수 있는 개체 집합으로 대체할 것입니다. 인터페이스를 받은 후 - 아무 것도 기억할 필요가 없음 - 인터페이스 자체가 나를 제한하고 잘못된 필드나 개체를 참조하는 것을 허용하지 않습니다. 그래픽 코어 어레이의 경우 이러한 호소가 매우 가능합니다.
즉, 블록이 인터페이스를 수신하는 경우 컴파일러 자체가 불필요한 모든 엔티티를 "차단"하고 사용자가 실수를 하도록 허용하지 않습니다. 동일한 그래픽 코어 배열을 사용하면 사용자가 쉽게 실수할 수 있는 많은 추가 정보를 갖게 됩니다.
내 자신의 경험을 통해 컴파일러 자체가 현재 블록에서 맞지 않아야 하는 위치에 맞지 않도록 컴파일러 자체가 나를 모니터링하는 것이 훨씬 낫다는 것을 알고 있습니다. 그리고 그래픽 코어 어레이와 함께 - 나는 그것을 기억해야 합니다. 내 시스템의 마이너스는 플러스의 연속입니다. 현재 작업의 범위를 벗어나는 블록에 갑자기 무언가가 필요한 경우 그래픽 코어 배열로 모든 것이 간단합니다. 필요한 데이터를 가져와서 작업합니다. 그러나 OOP 인터페이스를 사용하면 추가 인터페이스에서 필요한 데이터를 요청하거나 (훨씬 더 불쾌한) 기존 인터페이스를 수정해야 합니다.
핵심에 불필요한 것이 있다고 생각하는 것은 완전히 잘못된 것입니다. 정의를 통해 인간의 언어로 옷을 입기 때문에 본질을 암기하는 것이 매우 쉽습니다. 모든 것이 거기에 수집되지만 이 콘텐츠에는 명확하고 불변하는 순서가 있습니다. 개체, 창, 요소의 속성은 프로그램의 어느 지점에서나 직접 액세스할 수 있습니다. 그리고 사이클의 코어 덕분에 어떤 기적이 일어날 수 있는지 ...
핵심에 불필요한 것이 있다고 생각하는 것은 완전히 잘못된 것입니다. 정의를 통해 인간의 언어로 옷을 입기 때문에 본질을 암기하는 것이 매우 쉽습니다. 모든 것이 거기에 수집되지만 이 콘텐츠에는 명확하고 불변하는 순서가 있습니다. 개체, 창, 요소의 속성은 프로그램의 어느 지점에서나 직접 액세스할 수 있습니다. 그리고 사이클의 코어 덕분에 어떤 기적이 일어날 수 있는지 ...
'커널에 불필요한 것이 있다'는 게 아니라 '현재로서는 필요하지 않다'고 했다. 그래프 선으로 작업하는 경우 창 속성에 액세스할 수 없어야 합니다.
이러한 모든 속성이 프로그램의 어느 지점에서나 직접 액세스할 수 있다는 사실이 접근 방식의 주요 단점입니다. 프로그램의 어느 곳에서든 현재 이 특정 위치에 필요한 요소에만 액세스해야 합니다. 다른 모든 것은 사용할 수 없어야 합니다. 이를 통해 많은 오류를 자동으로 피할 수 있습니다.
내 생각에 "전체 코어의 가용성으로 인해 수행할 수 있는 기적"은 찾기 어려운 버그 및 코드 이해 문제의 잠재적 원인입니다. 우리는 이러한 모든 속임수를 피하려고 노력해야 합니다.
이 접근 방식은 포인터, 증분, 링크가 거친 혼합으로 한 줄에 작성될 때 어리석은 퍼즐을 생각나게 합니다. 아마도 언어의 관점에서 볼 때 정확하지만 완전히 읽을 수는 없습니다. 예, 위에서 자체 기능을 제공했는데 완전히 미친 것처럼 보입니다. 이 경우 컴팩트가 더 중요하다고 생각했습니다.
왜 그렇게 쉽게 만드십시오. 가시성과 가독성은 어떻습니까? 그리고 오류 감지 및 수정의 단순화? 휴대성은 어떻습니까? 그리고 현대화의 단순화? 등. 등. ....
공상!
1. OOP 이전에는 매우 복잡한 도구를 사용하여 쓸모없는 구성 요소에서 모든 것을 구축했습니다.
2. OOP 이전에는 프로그램이 매우 잘 혼합된 설탕에 절인 과일이었습니다.
3. OOP 이전에는 데이터와 코드의 현지화에 대해 들어본 적이 없으며 이 공포로 인해 유지 관리 중에 우리가 겪은 고통
4. 동일한 프로그램의 서로 다른 부분 간에 데이터를 보호하는 것은 피펫에 불과합니다!
5. OOP 이전에는 아무도 시스템을 확장하지 않았습니다.
그냥 완전한 아웃.
여기 앉아서 내가 70년대 후반에 이 모든 것을 사용했고 프로그래밍 문화와 관련된 훨씬 더 많은 것을 사용했기 때문에 바로 이 OOP가 나에게서 자랐을 수도 있다고 생각합니다.
'커널에 불필요한 것이 있다'는 게 아니라 '현재로서는 필요하지 않다'고 했다. 그래프 선으로 작업하는 경우 창 속성에 액세스할 수 없어야 합니다.
이러한 모든 속성이 프로그램의 어느 지점에서나 직접 액세스할 수 있다는 사실이 접근 방식의 주요 단점입니다. 프로그램의 어느 곳에서든 현재 이 특정 위치에 필요한 요소에만 액세스해야 합니다. 다른 모든 것은 사용할 수 없어야 합니다. 이를 통해 많은 오류를 자동으로 피할 수 있습니다.
내 생각에 "전체 코어의 가용성으로 인해 수행할 수 있는 기적"은 찾기 어려운 버그 및 코드 이해 문제의 잠재적 원인입니다. 우리는 이러한 모든 속임수를 피하려고 노력해야 합니다.
이 접근 방식은 포인터, 증분, 링크가 거친 혼합으로 한 줄에 작성될 때 어리석은 퍼즐을 생각나게 합니다. 아마도 언어의 관점에서 볼 때 정확하지만 완전히 읽을 수는 없습니다. 예, 위에서 자체 기능을 제공했는데 완전히 미친 것처럼 보입니다. 이 경우 컴팩트가 더 중요하다고 생각했습니다.
당신은 당신이 말하는 기술과 관련이 없는 당신의 경험에 기반한 순간적인 이론적인 아이디어를 기반으로 커널에 대해 이야기합니다. 여기에서 액세스, 엔티티 암기에 대한 몇 가지 문제가 있습니다 ...
나는 이 기술에 대한 실질적인 경험을 바탕으로 주장하는 것이며, 접근이나 제한에 그런 문제는 없다고 말씀드립니다. 솔직히 말씀드리면 어떤 종류의 액세스 문제를 말씀하시는지 이해가 되지 않습니다. 그런 문제는 없고 그런 적도 없습니다.
귀하가 의미하는 액세스 문제에 대해 자세히 알려주십시오.
액세스를 제한해야 한다고 결정한 이유는 무엇입니까? 그렇지 않으면 오류가 발생합니까? 저에게 이것은 새로운 것입니다.
절차 코드의 전역 배열에 직접 액세스하면 자체적으로 찾기 어려운 버그가 발생할 수 있습니까?
당신은 당신이 말하는 기술과 관련이 없는 당신의 경험에 기반한 순간적인 이론적인 아이디어를 기반으로 커널에 대해 이야기합니다. 따라서 액세스, 엔티티 기억에 몇 가지 문제가 있습니다 ...
나는 이 기술에 대한 실질적인 경험을 바탕으로 주장하는 것이며, 접근이나 제한에 그런 문제는 없다고 말씀드립니다. 솔직히 말씀드리면 어떤 종류의 액세스 문제를 말씀하시는지 이해가 되지 않습니다. 그런 문제는 없고 그런 적도 없습니다.
그러나 "어디서나 모든 것이 가능하다"고 말한다면 어떻게 "문제없다"가 있을 수 있겠는가?
이것이 주요 문제입니다! 사용할 수 없어야합니다!
결론은 액세스 제어 작업을 컴파일러로 옮기는 것입니다. 그리고 당신에게 - 모든 것이 열려 있고 액세스 제어는 프로그래머가 수행합니다.
모든 것을 기억하기 때문에 어려움은 없었습니다. 이미 익숙합니다. 아무 것도 없습니다. 시간이 지나면서 메모리가 고장나기 시작한다는 것을 알게 될 것입니다. 그런 다음 컴파일러의 액세스 제어 기능을 평가하게 될 것입니다. 기억이 안나네요. 그리고 나는 대다수가 몇 달 전에 작성된 것이 어떻게 작동하는지 주기적으로 잊어 버릴 것이라고 생각합니다. 이러한 조건에서 액세스 제어가 장점이 됩니다.
예를 들어 주문을 담당하는 블록 안에 있으면 주문만 할 수 있습니다. 그리고 당신은 그래프를 그릴 능력이 없습니다. 차트 그리기를 담당하는 블록에 있는 경우 그곳에서 주문할 수 없습니다. 이것은 작업을 크게 단순화합니다. 그리고 차트 그리기 기능에서 갑자기 주문 요청이 표시되면 오랫동안 왜 그렇게 했는지 기억해야 합니다. 왜 그런 결정을 내렸는지에 대한 자세한 설명이 있으면 좋겠지만.. 하지만 이런 목적을 위해 특별히 설계된 한 블록에 주문을 하면 더 좋다.
그러나 "어디서나 모든 것이 가능하다"고 말한다면 어떻게 "문제없다"가 있을 수 있겠는가?
이것이 주요 문제입니다! 사용할 수 없어야합니다!
결론은 액세스 제어 작업을 컴파일러로 옮기는 것입니다. 그리고 당신에게 - 모든 것이 열려 있고 액세스 제어는 프로그래머가 수행합니다.
모든 것을 기억하기 때문에 어려움은 없었습니다. 이미 익숙합니다. 아무 것도 없습니다. 시간이 지나면서 메모리가 고장나기 시작한다는 것을 알게 될 것입니다. 그런 다음 컴파일러의 액세스 제어 기능을 평가하게 될 것입니다. 기억이 안나네요. 그리고 나는 대다수가 몇 달 전에 작성된 것이 어떻게 작동하는지 주기적으로 잊어 버릴 것이라고 생각합니다. 이러한 조건에서 액세스 제어가 유용합니다.
예를 들어 주문을 담당하는 블록 안에 있으면 주문만 할 수 있습니다. 그리고 당신은 그래프를 그릴 능력이 없습니다. 차트 그리기를 담당하는 블록에 있는 경우 그곳에서 주문할 수 없습니다. 이것은 작업을 크게 단순화합니다. 그리고 차트 그리기 기능에서 갑자기 주문 요청이 표시되면 오랫동안 왜 그렇게 했는지 기억해야 합니다. 왜 그런 결정을 내렸는지에 대한 자세한 설명이 있으면 좋겠지만.. 하지만 이런 목적을 위해 특별히 설계된 한 블록에 주문을 하면 더 좋다.