Реter Konow : 함수형 절차적 프로그래밍에서는 당신이 설명하는 접근 문제가 존재하지 않습니다. 함수 오버로딩도 없고, 필드와 객체도 없고, 포인터와 다른 것도 없고, 어디에서나 액세스할 수 있는 모든 전역 변수 에 대해 하나의 메모리만 있을 때 어떻게 잘못된 함수를 호출할 수 있습니까? 어떤 액세스 관련 오류가 발생할 수 있습니까? 그리고 네, 기억하기가 훨씬 쉽습니다.
예, 가장 간단한 실수는 크기에 가까운 값을 포함하는 잘못된 변수를 참조하는 것입니다.
이러한 오류는 오랫동안 감지되지 않을 수 있지만 비열의 법칙에 따르면 이곳에서 오류가 없는 작업이 매우 필요한 시점에 "크롤링"됩니다!
그리고 그것은 계산하기가 너무 어려울 것입니다... 당신은 왜 EA가 좋은 추세로 거래를 마감했는지 이해하려고 노력하고 있습니다. 그때 TS는 – 어떤 식으로든 청산해서는 안 되었고 – 할 수 없었습니다. 모든 것이 올바르게 작동하는 것 같습니다.
이것들은 가장 불쾌한 오류 중 하나일 뿐입니다. 변수의 초기화 취소 또는 잘못된 변수에 대한 액세스이지만 값은 비슷합니다. 그리고 프로그램의 한 부분 또는 다른 부분에서 사용할 수 있는 변수가 많을수록 그러한 오류가 발생할 가능성이 커집니다.
네, 물론, 전 세계적으로 사용 가능한 그래픽 코어가 있고 이 곳에서 주문 작업을 한다면 잘못된 변수에 접근하기가 정말 어렵습니다. 그러나 이전 블록에서 주문을 열어야 할 필요성을 결정하고 지표로 전환하고 아마도 사용자 작업에서 이미 변수를 혼동하는 것이 가능합니다.
시스템의 전체 구조를 메모리에 유지하기만 하면 여기서 문제가 발생하지 않습니다. 더 많은 구조가 있고 중요한 미묘함이 주기적으로 메모리에서 사라지면 전역 액세스가 문제의 원인이며 가능한 모든 방법으로 사용을 피해야한다는 결론에 도달하게됩니다. 그리고 코드는 가능한 한 적게 기억할 필요가 있는 방식으로 작성되어야 합니다. 이상적으로는 메모리에 아무 것도 보관하지 마십시오. 각 블록에는 해당 기능을 나타내는 이름이 있습니다. 입력 시 이 기능에 필요하고 충분한 데이터를 수신하며, 다른 지식을 끌어들이지 않고 기능을 구현하기만 하면 됩니다. "밖에서".
이러한 오류는 오랫동안 감지되지 않을 수 있지만 비열의 법칙에 따르면 이곳에서 오류가 없는 작업이 매우 필요한 시점에 "크롤링"됩니다!
그리고 그것은 계산하기가 너무 어려울 것입니다... 당신은 왜 EA가 좋은 추세로 거래를 마감했는지 이해하려고 노력하고 있습니다. 그때 TS는 – 어떤 식으로든 청산해서는 안 되었고 – 할 수 없었습니다. 모든 것이 올바르게 작동하는 것 같습니다.
이것들은 가장 불쾌한 오류 중 하나일 뿐입니다. 변수의 초기화 취소 또는 잘못된 변수에 대한 액세스이지만 값은 비슷합니다. 그리고 프로그램의 한 부분 또는 다른 부분에서 사용할 수 있는 변수가 많을수록 그러한 오류가 발생할 가능성이 커집니다.
네, 물론, 전 세계적으로 사용 가능한 그래픽 코어가 있고 이 곳에서 주문 작업을 한다면 잘못된 변수에 접근하기가 정말 어렵습니다. 그러나 이전 블록에서 주문을 열어야 할 필요성을 결정하고 지표로 전환하고 아마도 사용자 작업에서 이미 변수를 혼동하는 것이 가능합니다.
시스템의 전체 구조를 메모리에 유지하기만 하면 여기에는 아무런 문제가 없습니다. 더 많은 구조가 있고 중요한 미묘함이 주기적으로 메모리에서 사라지면 전역 액세스가 문제의 원인이며 가능한 모든 방법으로 사용을 피해야한다는 결론에 도달하게됩니다. 그리고 코드는 가능한 한 적게 기억할 필요가 있는 방식으로 작성되어야 합니다. 이상적으로는 메모리에 아무 것도 보관하지 마십시오. 각 블록에는 해당 기능을 나타내는 이름이 있습니다. 입력 시 이 기능에 필요하고 충분한 데이터를 수신하며, 다른 지식을 끌어들이지 않고 기능을 구현하기만 하면 됩니다. "밖에서".
젠장, 모두 다르게 호출되는 경우 잘못된 변수를 어떻게 참조할 수 있습니까? 고유한 이름이 있고 오버로드가 없는 경우 잘못된 함수를 어떻게 호출할 수 있습니까? 커널 배열 내에서 모든 셀 인덱스는 사람의 단어로 정의된 이름이 지정됩니다. 여기서 무엇을 혼동할 수 있습니까? 당신이 말하는 문제는 전혀 존재하지 않는다는 것을 이해하십시오.
메모리에는 아주 간단한 커널 구조만 보관합니다. 또한 개체의 속성 목록을 알고 있습니다. 모든 객체의 속성은 동일하며 값만 다릅니다. 총 140개의 속성이 있지만 가장 중요한 것만 30개 정도만 기억하고 나머지는 필요할 때 기억합니다. 이에 대한 정의가 있는 파일로 이동하여 속성의 전체 목록을 확인합니다. 복잡하지 않습니다. "OBJECT" 또는 "WINDOW"와 같은 집중 전역 변수 는 전혀 외울 필요가 없습니다. 그리고 무엇과도 혼동하는 것은 불가능합니다.
내 변수에는 러시아어로 의미 있는 이름이 있습니다. 폭풍우가 치는 파티 후에 만 \u200b\u200b혼동할 수 있습니다.))
내 전역 변수 는 포커스에서 사용되는 변수로, 커널을 "목표로 삼고" 커서가 이동할 때 커널 위로 이동합니다.
예: 변수 "WINDOW"는 항상 커서가 위치한 창의 번호를 전달합니다. "OBJECT" 변수는 커서가 위치한 개체의 번호입니다.
그것들을 통해 커널에 액세스합니다 - 특정 창, 개체 및 커널의 속성 - G_CORE[WINDOW][OBJECT][_NAME] 또는 G_CORE[WINDOW][OBJECT][_OBJECT_GROUP]. 어떤 함수에서든 객체의 X 좌표가 필요하면 객체의 높이가 G_CORE[WINDOW][OBJECT][_Y_SIZE]인 경우 G_CORE[WINDOW][OBJECT][_X]에서 가져옵니다. 곧...
전체적으로 개별적으로 선언된 전역 변수가 약 100개 있지만 각 배열 셀이 변수이기 때문에 커널 전역 배열에는 수천 개의 전역 변수가 있습니다. 그러나 이 수의 변수를 관리하는 것은 순서가 지정되어 있기 때문에 매우 쉽습니다. 코어의 각 창은 배열 필드이고 각 행은 140개의 속성으로 구성된 하나의 개체입니다. 이 경우 요소는 개체 모음입니다. 각 요소에는 전체 요소의 주요 속성을 포함하는 기본 개체가 있습니다. 특정 요소에 속한 개체는 특수 인덱스에 의해 서로 연결되어 있으므로 개체에 포커스가 있는 모든 개체가 속한 요소에도 포커스가 있습니다. 또한 그것이 그려진 캔버스. 커널의 명확한 아키텍처와 모든 기능에서 직접 액세스할 수 있는 덕분에 커널 배열의 셀인 수천 개의 변수를 관리할 수 있으며 아무 것도 잊어버리지 않고 자유롭게 방향을 지정할 수 있습니다.
완전히 의미 없는 대화: 코드를 "좋음" 또는 "나쁨"으로 분류하는 기준이 없습니다 . 이것이 OOP에 대해 명확하지 않은 이유입니다.
나에게 그러한 기준은 코드의 가시성이며, 이는 작성자 또는 제3자가 오랜 시간 후에 코드를 읽고 수정, 검색에 사용할 수 있다는 사실에서 나타납니다. 버그 .....
위에서 Fedoseev가 OOP 스위치를 교체했습니다. 나에게 성공하지 못할 수도 있는 이 특정 예는 OOP의 사악함에 대한 증거입니다. 100개 위치의 스위치가 있는 설명 코드가 한 줄로 대체됩니다. 이 선을 이해하려면 어딘가로 올라가야 합니다. 저에게는 이것이 용납되지 않습니다.
George Merts 위의 두 번째 예
디버깅 후 설명 코드가 비설명 코드로 대체된 경우. 내 기준에 따르면 고품질 코드(읽기 쉬운)가 잘못된 코드로 대체되었습니다.
따라서 OOP의 모든 지지자에게 질문이 있습니다. OOP를 사용할 때 프로그램이 더 시각적 으로 표시되고 스위치에서 Fedoseev가 제공한 예가 실패하거나 그 반대의 경우도 마찬가지입니다. Fedoseev의 예는 OOP를 매우 정확하게 특성화하고 OOP는 거의 항상 다음으로 이어집니다. 가시성 상실?
SS를 사용하면 모든 것이 명확해집니다. 그의 이해 수준 이상의 모든 것은 사랑입니다. 그러나 그는 문자 R)))))))))))))))
젠장, 글쎄요, 잘못된 변수가 모두 다르게 호출된다면 어떻게 참조할 수 있습니까? 고유한 이름이 있고 오버로드가 없는 경우 잘못된 함수를 어떻게 호출할 수 있습니까? 커널 배열 내에서 모든 셀 인덱스는 사람의 단어로 정의된 이름이 지정됩니다. 여기서 무엇을 혼동할 수 있습니까? 당신이 말하는 문제는 전혀 존재하지 않는다는 것을 이해하십시오.
글쎄요, 저는 그런 경우가 몇 번 있었습니다.
대부분의 경우 이러한 종류의 오류는 현재 블록에 따라 다른 위치에서 코드 조각을 복사하고 "수정"할 때 발생합니다. 전역 액세스 권한이 있는 경우 변수 중 하나를 변경하는 것을 건너뛸 수 있습니다. 이 경우 작업해야 하는 항목에만 액세스할 수 있는 경우 복사 후 컴파일러 자체에서 변경해야 하는 모든 변수 및 위치 목록을 제공합니다.
피터 코노우 :
메모리에는 아주 간단한 커널 구조만 유지합니다. 또한 개체의 속성 목록을 알고 있습니다. 모든 객체의 속성은 동일하며 값만 다릅니다. 총 140개의 속성이 있지만 가장 중요한 것만 30개 정도만 기억하고 나머지는 필요할 때 기억합니다. 이에 대한 정의가 있는 파일로 이동하여 전체 속성 목록을 확인합니다. 복잡하지 않습니다.
30 속성 ??? 글쎄, 이것은 나에게 받아 들일 수 없습니다. 기억하지 못하는 것은 아니지만 기억에 의존하고 싶지는 않다. 각 블록에 항상 이 블록에서 처리되어야 하는 변수가 정확히 있고 다른 블록에 액세스할 수 없는 경우 훨씬 더 좋습니다.
하지만, 기억해야 할 필요가 있다는 것은 저를 귀찮게 합니다... 그리고 당신에게 어렵지 않기 때문에 추가 OOP 제스처를 만드는 것이 의미가 없다는 것은 충분히 이해할 수 있습니다.
대부분의 경우 이러한 종류의 오류는 현재 블록에 따라 다른 위치에서 코드 조각을 복사하고 "수정"할 때 발생합니다. 전역 액세스 권한이 있는 경우 변수 중 하나를 변경하는 것을 건너뛸 수 있습니다. 이 경우 작업해야 하는 것만 사용할 수 있는 경우 복사 후 컴파일러 자체에서 변경해야 하는 모든 변수 및 위치 목록을 제공합니다.
30 속성 ??? 글쎄, 이것은 나를 위해 받아 들일 수 없습니다. 기억하지 못하는 것은 아니지만 기억에 의존하고 싶지는 않다. 각 블록에 항상 이 블록에서 처리되어야 하는 변수가 정확히 있고 다른 블록에 액세스할 수 없는 경우 훨씬 더 좋습니다.
하지만, 기억해야 할 필요가 있다는 것은 저를 귀찮게 합니다... 그리고 당신에게 어렵지 않기 때문에 추가 OOP 제스처를 만드는 것이 의미가 없다는 것은 충분히 이해할 수 있습니다.
글쎄요, 솔직히 말해서, 나는 많은 것을 기억합니다. 객체 바인딩 _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C 등의 약어는 무엇입니까? 각각은 다른 객체에 대한 한 객체의 위치를 정의합니다. 매개변수 A1, B1, C1, A2, B2, C2, A3, B3, C3, A4, B4, C4, A5... 100)에 있습니다. 예를 들어 빌딩 블록에는 수십 개의 함수가 있으며 4000줄 이상의 코드를 차지합니다. 알고 기억해야 할 것이 많습니다. 그러나 암기는 즉시가 아니라 점진적으로 장기간의 연습에서 발생합니다. 예전에는 엔티티의 수와 코드의 크기 때문에 머리가 부풀어 오르더니 모든 것이 뭉개지고 단순해졌습니다.
글쎄요, 솔직히 말해서, 나는 많은 것을 기억합니다. 개체 바인딩 _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C 등의 약어는 무엇입니까? 각각은 한 개체의 특정 위치를 다른 개체에 정의하며 매개변수 A1, B1, C1, A2, B2, C2, A3, B3, C3, A4, B4, C4, A5 ... 나는 또한 수십 개의 범주 이름과 개체의 하위 범주, 수십 개의 창 속성을 기억합니다. 100개). 예를 들어 빌딩 블록에는 수십 개의 함수가 있으며 4000줄 이상의 코드를 차지합니다. 알고 기억해야 할 것이 많습니다. 그러나 암기는 즉시가 아니라 점진적으로 장기간의 연습에서 발생합니다. 예전에는 엔티티의 수와 코드의 크기 때문에 머리가 부풀어 오르더니 모든 것이 뭉개지고 단순해졌습니다.
산만하고 모든 것을 잊고 한 달 동안 휴가를 가고 코드에 대해 생각하지 마십시오. 오시면 이 1, b1 등을 모두 보세요. 히스테리해집니다 :)
이것은 30개 이상의 요소 중 하나에 불과합니다. 게다가 가장 작은 요소 중 하나입니다. 하지만 놀라운 점은 책을 펼쳐놓은 책처럼 읽었다는 것입니다. 무엇인지 설명하는 데 어려움이 없습니다. 또 다른 이상한 점은 유사한 요소가 다른 유사한 요소의 복사-붙여넣기를 사용하고 일부 수정을 사용하여 매우 빠르게 생성된다는 것입니다. 무섭게 보이지만 실제로는 매우 쉽습니다.
함수형 절차적 프로그래밍에서는 당신이 설명하는 접근 문제가 존재하지 않습니다. 함수 오버로딩도 없고, 필드와 객체도 없고, 포인터와 다른 것도 없고, 어디에서나 액세스할 수 있는 모든 전역 변수 에 대해 하나의 메모리만 있을 때 어떻게 잘못된 함수를 호출할 수 있습니까? 어떤 액세스 관련 오류가 발생할 수 있습니까? 그리고 네, 기억하기가 훨씬 쉽습니다.
예, 가장 간단한 실수는 크기에 가까운 값을 포함하는 잘못된 변수를 참조하는 것입니다.
이러한 오류는 오랫동안 감지되지 않을 수 있지만 비열의 법칙에 따르면 이곳에서 오류가 없는 작업이 매우 필요한 시점에 "크롤링"됩니다!
그리고 그것은 계산하기가 너무 어려울 것입니다... 당신은 왜 EA가 좋은 추세로 거래를 마감했는지 이해하려고 노력하고 있습니다. 그때 TS는 – 어떤 식으로든 청산해서는 안 되었고 – 할 수 없었습니다. 모든 것이 올바르게 작동하는 것 같습니다.
이것들은 가장 불쾌한 오류 중 하나일 뿐입니다. 변수의 초기화 취소 또는 잘못된 변수에 대한 액세스이지만 값은 비슷합니다. 그리고 프로그램의 한 부분 또는 다른 부분에서 사용할 수 있는 변수가 많을수록 그러한 오류가 발생할 가능성이 커집니다.
네, 물론, 전 세계적으로 사용 가능한 그래픽 코어가 있고 이 곳에서 주문 작업을 한다면 잘못된 변수에 접근하기가 정말 어렵습니다. 그러나 이전 블록에서 주문을 열어야 할 필요성을 결정하고 지표로 전환하고 아마도 사용자 작업에서 이미 변수를 혼동하는 것이 가능합니다.
시스템의 전체 구조를 메모리에 유지하기만 하면 여기서 문제가 발생하지 않습니다. 더 많은 구조가 있고 중요한 미묘함이 주기적으로 메모리에서 사라지면 전역 액세스가 문제의 원인이며 가능한 모든 방법으로 사용을 피해야한다는 결론에 도달하게됩니다. 그리고 코드는 가능한 한 적게 기억할 필요가 있는 방식으로 작성되어야 합니다. 이상적으로는 메모리에 아무 것도 보관하지 마십시오. 각 블록에는 해당 기능을 나타내는 이름이 있습니다. 입력 시 이 기능에 필요하고 충분한 데이터를 수신하며, 다른 지식을 끌어들이지 않고 기능을 구현하기만 하면 됩니다. "밖에서".
예, 가장 간단한 실수는 값에 가까운 값을 포함하는 잘못된 변수를 참조하는 것입니다.
이러한 오류는 오랫동안 감지되지 않을 수 있지만 비열의 법칙에 따르면 이곳에서 오류가 없는 작업이 매우 필요한 시점에 "크롤링"됩니다!
그리고 그것은 계산하기가 너무 어려울 것입니다... 당신은 왜 EA가 좋은 추세로 거래를 마감했는지 이해하려고 노력하고 있습니다. 그때 TS는 – 어떤 식으로든 청산해서는 안 되었고 – 할 수 없었습니다. 모든 것이 올바르게 작동하는 것 같습니다.
이것들은 가장 불쾌한 오류 중 하나일 뿐입니다. 변수의 초기화 취소 또는 잘못된 변수에 대한 액세스이지만 값은 비슷합니다. 그리고 프로그램의 한 부분 또는 다른 부분에서 사용할 수 있는 변수가 많을수록 그러한 오류가 발생할 가능성이 커집니다.
네, 물론, 전 세계적으로 사용 가능한 그래픽 코어가 있고 이 곳에서 주문 작업을 한다면 잘못된 변수에 접근하기가 정말 어렵습니다. 그러나 이전 블록에서 주문을 열어야 할 필요성을 결정하고 지표로 전환하고 아마도 사용자 작업에서 이미 변수를 혼동하는 것이 가능합니다.
시스템의 전체 구조를 메모리에 유지하기만 하면 여기에는 아무런 문제가 없습니다. 더 많은 구조가 있고 중요한 미묘함이 주기적으로 메모리에서 사라지면 전역 액세스가 문제의 원인이며 가능한 모든 방법으로 사용을 피해야한다는 결론에 도달하게됩니다. 그리고 코드는 가능한 한 적게 기억할 필요가 있는 방식으로 작성되어야 합니다. 이상적으로는 메모리에 아무 것도 보관하지 마십시오. 각 블록에는 해당 기능을 나타내는 이름이 있습니다. 입력 시 이 기능에 필요하고 충분한 데이터를 수신하며, 다른 지식을 끌어들이지 않고 기능을 구현하기만 하면 됩니다. "밖에서".
젠장, 모두 다르게 호출되는 경우 잘못된 변수를 어떻게 참조할 수 있습니까? 고유한 이름이 있고 오버로드가 없는 경우 잘못된 함수를 어떻게 호출할 수 있습니까? 커널 배열 내에서 모든 셀 인덱스는 사람의 단어로 정의된 이름이 지정됩니다. 여기서 무엇을 혼동할 수 있습니까? 당신이 말하는 문제는 전혀 존재하지 않는다는 것을 이해하십시오.
메모리에는 아주 간단한 커널 구조만 보관합니다. 또한 개체의 속성 목록을 알고 있습니다. 모든 객체의 속성은 동일하며 값만 다릅니다. 총 140개의 속성이 있지만 가장 중요한 것만 30개 정도만 기억하고 나머지는 필요할 때 기억합니다. 이에 대한 정의가 있는 파일로 이동하여 속성의 전체 목록을 확인합니다. 복잡하지 않습니다. "OBJECT" 또는 "WINDOW"와 같은 집중 전역 변수 는 전혀 외울 필요가 없습니다. 그리고 무엇과도 혼동하는 것은 불가능합니다.
내 변수에는 러시아어로 의미 있는 이름이 있습니다. 폭풍우가 치는 파티 후에 만 \u200b\u200b혼동할 수 있습니다.))내 전역 변수 는 포커스에서 사용되는 변수로, 커널을 "목표로 삼고" 커서가 이동할 때 커널 위로 이동합니다.
예: 변수 "WINDOW"는 항상 커서가 위치한 창의 번호를 전달합니다. "OBJECT" 변수는 커서가 위치한 개체의 번호입니다.
그것들을 통해 커널에 액세스합니다 - 특정 창, 개체 및 커널의 속성 - G_CORE[WINDOW][OBJECT][_NAME] 또는 G_CORE[WINDOW][OBJECT][_OBJECT_GROUP]. 어떤 함수에서든 객체의 X 좌표가 필요하면 객체의 높이가 G_CORE[WINDOW][OBJECT][_Y_SIZE]인 경우 G_CORE[WINDOW][OBJECT][_X]에서 가져옵니다. 곧...
전체적으로 개별적으로 선언된 전역 변수가 약 100개 있지만 각 배열 셀이 변수이기 때문에 커널 전역 배열에는 수천 개의 전역 변수가 있습니다. 그러나 이 수의 변수를 관리하는 것은 순서가 지정되어 있기 때문에 매우 쉽습니다. 코어의 각 창은 배열 필드이고 각 행은 140개의 속성으로 구성된 하나의 개체입니다. 이 경우 요소는 개체 모음입니다. 각 요소에는 전체 요소의 주요 속성을 포함하는 기본 개체가 있습니다. 특정 요소에 속한 개체는 특수 인덱스에 의해 서로 연결되어 있으므로 개체에 포커스가 있는 모든 개체가 속한 요소에도 포커스가 있습니다. 또한 그것이 그려진 캔버스. 커널의 명확한 아키텍처와 모든 기능에서 직접 액세스할 수 있는 덕분에 커널 배열의 셀인 수천 개의 변수를 관리할 수 있으며 아무 것도 잊어버리지 않고 자유롭게 방향을 지정할 수 있습니다.
완전히 의미 없는 대화: 코드를 "좋음" 또는 "나쁨"으로 분류하는 기준이 없습니다 . 이것이 OOP에 대해 명확하지 않은 이유입니다.
나에게 그러한 기준은 코드의 가시성이며, 이는 작성자 또는 제3자가 오랜 시간 후에 코드를 읽고 수정, 검색에 사용할 수 있다는 사실에서 나타납니다. 버그 .....
위에서 Fedoseev가 OOP 스위치를 교체했습니다. 나에게 성공하지 못할 수도 있는 이 특정 예는 OOP의 사악함에 대한 증거입니다. 100개 위치의 스위치가 있는 설명 코드가 한 줄로 대체됩니다. 이 선을 이해하려면 어딘가로 올라가야 합니다. 저에게는 이것이 용납되지 않습니다.
George Merts 위의 두 번째 예
디버깅 후 설명 코드가 비설명 코드로 대체된 경우. 내 기준에 따르면 고품질 코드(읽기 쉬운)가 잘못된 코드로 대체되었습니다.
따라서 OOP의 모든 지지자에게 질문이 있습니다. OOP를 사용할 때 프로그램이 더 시각적 으로 표시되고 스위치에서 Fedoseev가 제공한 예가 실패하거나 그 반대의 경우도 마찬가지입니다. Fedoseev의 예는 OOP를 매우 정확하게 특성화하고 OOP는 거의 항상 다음으로 이어집니다. 가시성 상실?
SS를 사용하면 모든 것이 명확해집니다. 그의 이해 수준 이상의 모든 것은 사랑입니다. 그러나 그는 문자 R)))))))))))))))
SS를 사용하면 모든 것이 명확해집니다. 그의 이해 수준 이상의 모든 것은 사랑 입니다. 그러나 그는 문자 R))))))))))))))))
나는 또한 OOP에 중국어를 추가 할 것입니다, 아마도 일본어 ...
왜 OOP? 무엇이 더 좋을까?
가시성은 디버깅, 수정을 단순화한 것입니다. 가시성은 세심한 프로그램 설계 에서 OBJECTS보다는 FUNCTIONS로 구조화하는 것에서 나옵니다. 왜냐하면 전 세계는 그 반대가 아니라 객체에 대한 조치를 중심으로 구축되기 때문입니다.
입력 데이터가 출력 데이터로 변환되는 순서에서 기능으로의 분류가 뒤따를 때. 예를 들어 입력에서 BUY|SELL 출력으로 견적을 변환하는 것은 ACTIONS 표시를 통해서만 가능합니다.
이것이 인간의 마음이 작동하는 방식입니다.
추신.
R에 대한 귀하의 의견에 대해
장난을 하시겠습니까?
나는 거의 대답하지 않지만 대답 할 수 있습니다
젠장, 글쎄요, 잘못된 변수가 모두 다르게 호출된다면 어떻게 참조할 수 있습니까? 고유한 이름이 있고 오버로드가 없는 경우 잘못된 함수를 어떻게 호출할 수 있습니까? 커널 배열 내에서 모든 셀 인덱스는 사람의 단어로 정의된 이름이 지정됩니다. 여기서 무엇을 혼동할 수 있습니까? 당신이 말하는 문제는 전혀 존재하지 않는다는 것을 이해하십시오.
글쎄요, 저는 그런 경우가 몇 번 있었습니다.
대부분의 경우 이러한 종류의 오류는 현재 블록에 따라 다른 위치에서 코드 조각을 복사하고 "수정"할 때 발생합니다. 전역 액세스 권한이 있는 경우 변수 중 하나를 변경하는 것을 건너뛸 수 있습니다. 이 경우 작업해야 하는 항목에만 액세스할 수 있는 경우 복사 후 컴파일러 자체에서 변경해야 하는 모든 변수 및 위치 목록을 제공합니다.
피터 코노우 :
메모리에는 아주 간단한 커널 구조만 유지합니다. 또한 개체의 속성 목록을 알고 있습니다. 모든 객체의 속성은 동일하며 값만 다릅니다. 총 140개의 속성이 있지만 가장 중요한 것만 30개 정도만 기억하고 나머지는 필요할 때 기억합니다. 이에 대한 정의가 있는 파일로 이동하여 전체 속성 목록을 확인합니다. 복잡하지 않습니다.
30 속성 ??? 글쎄, 이것은 나에게 받아 들일 수 없습니다. 기억하지 못하는 것은 아니지만 기억에 의존하고 싶지는 않다. 각 블록에 항상 이 블록에서 처리되어야 하는 변수가 정확히 있고 다른 블록에 액세스할 수 없는 경우 훨씬 더 좋습니다.
하지만, 기억해야 할 필요가 있다는 것은 저를 귀찮게 합니다... 그리고 당신에게 어렵지 않기 때문에 추가 OOP 제스처를 만드는 것이 의미가 없다는 것은 충분히 이해할 수 있습니다.
글쎄요, 저는 그런 경우가 몇 번 있었습니다.
대부분의 경우 이러한 종류의 오류는 현재 블록에 따라 다른 위치에서 코드 조각을 복사하고 "수정"할 때 발생합니다. 전역 액세스 권한이 있는 경우 변수 중 하나를 변경하는 것을 건너뛸 수 있습니다. 이 경우 작업해야 하는 것만 사용할 수 있는 경우 복사 후 컴파일러 자체에서 변경해야 하는 모든 변수 및 위치 목록을 제공합니다.
30 속성 ??? 글쎄, 이것은 나를 위해 받아 들일 수 없습니다. 기억하지 못하는 것은 아니지만 기억에 의존하고 싶지는 않다. 각 블록에 항상 이 블록에서 처리되어야 하는 변수가 정확히 있고 다른 블록에 액세스할 수 없는 경우 훨씬 더 좋습니다.
하지만, 기억해야 할 필요가 있다는 것은 저를 귀찮게 합니다... 그리고 당신에게 어렵지 않기 때문에 추가 OOP 제스처를 만드는 것이 의미가 없다는 것은 충분히 이해할 수 있습니다.
글쎄요, 솔직히 말해서, 나는 많은 것을 기억합니다. 객체 바인딩 _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C 등의 약어는 무엇입니까? 각각은 다른 객체에 대한 한 객체의 위치를 정의합니다. 매개변수 A1, B1, C1, A2, B2, C2, A3, B3, C3, A4, B4, C4, A5... 100)에 있습니다. 예를 들어 빌딩 블록에는 수십 개의 함수가 있으며 4000줄 이상의 코드를 차지합니다. 알고 기억해야 할 것이 많습니다. 그러나 암기는 즉시가 아니라 점진적으로 장기간의 연습에서 발생합니다. 예전에는 엔티티의 수와 코드의 크기 때문에 머리가 부풀어 오르더니 모든 것이 뭉개지고 단순해졌습니다.
글쎄요, 솔직히 말해서, 나는 많은 것을 기억합니다. 개체 바인딩 _X2X, Y2Y, B2B, R2R, H2Y, W2X, Y2H, X2W, C2C 등의 약어는 무엇입니까? 각각은 한 개체의 특정 위치를 다른 개체에 정의하며 매개변수 A1, B1, C1, A2, B2, C2, A3, B3, C3, A4, B4, C4, A5 ... 나는 또한 수십 개의 범주 이름과 개체의 하위 범주, 수십 개의 창 속성을 기억합니다. 100개). 예를 들어 빌딩 블록에는 수십 개의 함수가 있으며 4000줄 이상의 코드를 차지합니다. 알고 기억해야 할 것이 많습니다. 그러나 암기는 즉시가 아니라 점진적으로 장기간의 연습에서 발생합니다. 예전에는 엔티티의 수와 코드의 크기 때문에 머리가 부풀어 오르더니 모든 것이 뭉개지고 단순해졌습니다.
산만하고 모든 것을 잊고 한 달 동안 휴가를 가고 코드에 대해 생각하지 마십시오. 오시면 이 1, b1 등을 모두 보세요. 히스테리해집니다 :)
산만하고 모든 것을 잊고 한 달 동안 휴가를 가고 코드에 대해 생각하지 마십시오. 오시면 이 1, b1 등을 모두 보세요. 히스테리해집니다 :)
예를 들어 proto-core의 "checkbox" 요소는 다음과 같습니다.