여기에서 이 기능에 대해 더 자세히 설명합니다. 당신에게는 열 가지 필요한 기능 중 하나를 선택하는 거대한 크기 스위치가 있습니다. 이러한 스위치에서 실수로 분기 중 하나와 관련된 코드를 잘못된 위치에 작성하여 실수를 범하기 쉽습니다.
과부하 - 모든 것이 훨씬 쉽습니다. 우리는 10개의 다른 자손을 가지고 있고, 우리가 하나의 클래스로 작업할 때마다 하나의 오버로드된 기능이 있습니다. 완전히 다른 파일을 열어야 하기 때문에 실수로 다른 클래스에 쓸 수 없습니다.
게다가 - 이 매우 거대한 스위치에 있는 시험 자체 - 제 생각에는 하나의 필요한 수업을 개설한 다음 하나의 기능만 있는 시험을 여는 것보다 훨씬 더 스트레스가 많습니다.
사실, 어셈블러 코드에서 이 모든 오버로드는 this 포인터에 따라 어떤 경우에도 동일한 스위치로 귀결됩니다. 그러나 OOP의 경우 이 모든 것이 프로그래머에게 숨겨져 있으며 그의 작업에 방해가 되지 않습니다. OOP가 없으면 처리해야 합니다.
대략적으로 말하자면, 걸을 때 근육을 움직이게 하는 특정 순서로 신호를 근육에 보내게 됩니다. 그러나 의식 수준에서는 어떤 움직임이 필요한지 기억하기만 하면 됩니다. 여기서 OOP는 바로 "메모리, 어떤 움직임이 필요한가"입니다. 당신은 "많은 근육과 신경이 연결되어 있다면 왜 그 움직임을 기억하는지 이해하지 못합니다." 음... 기억의 거인을 위해 이미 여러 번 말했지만 실제로 걷기 위해 어떤 근육을 어떤 순서로 긴장시켜야 하는지 기억하는 것으로 충분합니다. 이 운동을 전체적으로 기억하는 것은 의미가 없습니다. 너무 많이 기억할 수없는 나머지 사람들에게는 전체 움직임을 전체적으로 기억하는 것이 훨씬 더 합리적이지만 근육에 무엇이 있는지, 어떤 순서로 긴장되고 얼마나 많은지 - 그것을 숨기는 것이 더 합리적입니다. 의식.
네, 조지, 당신의 주장은 합리적이고 논리적입니다. 실제로 내 접근 방식은 프로그램의 모든 것을 기억하고 알아야 합니다. 이것은 좋기도 하고 나쁘기도 합니다. 지식은 코드 및 솔루션의 신속한 개발, 적은 구문 및 많은 기능을 보장하기 때문에 좋지만 모든 블록의 전역 상호 연결로 인해 코드의 일부가 다른 프로그램으로 이식되지 않기 때문에 나쁜 것입니다.
우리의 구어 역시 결국 전역 기억을 사용합니다. 우리는 현재 대화 주제에 속하는 단어뿐만 아니라 모든 단어를 알고 기억합니다. 우리 마음속에는 모든 것이 뒤섞여 있습니다. 그것이 마음이 작동하는 방식이고 내 접근 방식이 작동하는 방식입니다. 기능 블록의 모든 중요한 출력은 보편적으로 사용 가능합니다. 따라서 그 안에는 거의 인간 용어가 있습니다. 나는 일반 언어처럼 코드로 말한다. 그것은 매우 편안합니다. 하지만 기억해야 할 것이 많습니다. 사실이야
추신. 그건 그렇고, 거대한 스위치는 파일로 분할되어 내용을 숨길 수 있습니다. 모든 것을 전체적으로 볼 수 있어 편합니다.
Tin, 일반적으로 받아 들여지는 접근 방식에 대한 적절한 연구 없이 일종의 자전거 제작을 하고 있습니다. Piotr, 좋은 책, 아마도 Stroustrup을 찾으세요. 그가 텍스트 편집기를 쓴 책에서 실제 문제에 대해 무언가를 그릴 수 있습니다. 내용은 기억나지 않지만 그는 나쁜 것을 가르칠 것 같지 않습니다.
물론 감사합니다. 그러나 지난 6년 동안 무수히 많은 문제를 풀었기 때문에 특정 작업이 무언가에 눈을 뜨게 할 것 같지는 않습니다. 정말 헤아릴 수 없습니다. 그러므로 나는 내가 무슨 말을 하는지 압니다.
이제 효율성으로 넘어갑니다. 스위치 - 결국 무엇입니까? 이것은 매개변수와 상수를 순차적으로 비교하는 것입니다. 피터, 일관성에주의를 기울이십시오. 즉, 원하는 상수가 100500번째이면 이러한 모든 비교가 프로세서에서 수행됩니다. 오버로드된 함수/메서드란 머신 코드에서 컴파일 후 자체 진입점이 있는 완전히 다른 코드 블록입니다. 그렇다면 어느 것이 더 효율적일까요?
Vladimir Simakov : 이제 효율성으로 넘어갑니다. 스위치 - 결국 무엇입니까? 이것은 매개변수와 상수를 순차적으로 비교하는 것입니다. 피터, 일관성에주의를 기울이십시오. 즉, 원하는 상수가 100500번째이면 이러한 모든 비교가 프로세서에서 수행됩니다. 오버로드된 함수/메서드란 머신 코드에서 컴파일 후 자체 진입점이 있는 완전히 다른 코드 블록입니다. 그렇다면 어느 것이 더 효율적일까요?
아아, 피할 수 없는 오버헤드. 이것에서 나는 지고, 다른 것에서 나는 이긴다.
예: 거대한 스위치가 있는 동일한 기능은 요소의 개체 위치와 창의 요소 위치를 정렬합니다. 크기를 계산합니다. 한 번 호출하면 모든 요소와 모든 개체가 바인딩에 따라 해당 위치에 배치됩니다. 서로에 대한 크기와 위치가 계산됩니다. 숨길 요소, 필요한 캔버스 크기 등 결정... 한 번의 호출로 많은 작업이 수행됩니다. 동일한 블록은 천 개 중 하나의 창 요소의 크기나 위치를 계산할 수 있습니다. 한 블록. 호출 - Object();
그렇게 많은 문제를 풀기 위해 OOP에서 얼마나 많은 클래스와 함수를 작성해야 합니까? 상상하기가 두렵다.
예: 거대한 스위치가 있는 동일한 기능은 요소의 개체 위치와 창의 요소 위치를 정렬합니다. 한 번 호출하면 모든 요소와 모든 개체가 바인딩에 따라 해당 위치에 배치됩니다. 크기와 위치가 계산됩니다. 숨길 요소, 필요한 캔버스 크기 등 결정... 한 번의 호출로 많은 작업이 수행됩니다. 동일한 블록은 천 개 중 하나의 창 요소의 크기나 위치를 계산할 수 있습니다. 한 블록.
그렇게 많은 문제를 풀기 위해 OOP에서 얼마나 많은 클래스와 함수를 작성해야 합니까? 상상하기가 두렵다.
여기에서 이 기능에 대해 더 자세히 설명합니다. 당신에게는 열 가지 필요한 기능 중 하나를 선택하는 거대한 크기 스위치가 있습니다. 이러한 스위치에서 실수로 분기 중 하나와 관련된 코드를 잘못된 위치에 작성하여 실수를 범하기 쉽습니다.
과부하 - 모든 것이 훨씬 쉽습니다. 우리는 10개의 다른 자손을 가지고 있고, 우리가 하나의 클래스로 작업할 때마다 하나의 오버로드된 기능이 있습니다. 완전히 다른 파일을 열어야 하기 때문에 실수로 다른 클래스에 쓸 수 없습니다.
게다가 - 이 매우 거대한 스위치에 있는 시험 자체 - 제 생각에는 하나의 필요한 수업을 개설한 다음 하나의 기능만 있는 시험을 여는 것보다 훨씬 더 스트레스가 많습니다.
사실, 어셈블러 코드에서 이 모든 오버로드는 this 포인터에 따라 어떤 경우에도 동일한 스위치로 귀결됩니다. 그러나 OOP의 경우 이 모든 것이 프로그래머에게 숨겨져 있으며 그의 작업에 방해가 되지 않습니다. OOP가 없으면 처리해야 합니다.
대략적으로 말하자면, 걸을 때 근육을 움직이게 하는 특정 순서로 신호를 근육에 보내게 됩니다. 그러나 의식 수준에서는 어떤 움직임이 필요한지 기억하기만 하면 됩니다. 여기서 OOP는 바로 "메모리, 어떤 움직임이 필요한가"입니다. 당신은 "많은 근육과 신경이 연결되어 있다면 왜 그 움직임을 기억하는지 이해하지 못합니다." 음... 기억의 거인을 위해 이미 여러 번 말했지만 실제로 걷기 위해 어떤 근육을 어떤 순서로 긴장시켜야 하는지 기억하는 것으로 충분합니다. 이 운동을 전체적으로 기억하는 것은 의미가 없습니다. 너무 많이 기억할 수없는 나머지 사람들에게는 전체 움직임을 전체적으로 기억하는 것이 훨씬 더 합리적이지만 근육에 무엇이 있는지, 어떤 순서로 긴장되고 얼마나 많은지 - 그것을 숨기는 것이 더 합리적입니다. 의식.
네, 조지, 당신의 주장은 합리적이고 논리적입니다. 실제로 내 접근 방식은 프로그램의 모든 것을 기억하고 알아야 합니다. 이것은 좋기도 하고 나쁘기도 합니다. 지식은 코드 및 솔루션의 신속한 개발, 적은 구문 및 많은 기능을 보장하기 때문에 좋지만 모든 블록의 전역 상호 연결로 인해 코드의 일부가 다른 프로그램으로 이식되지 않기 때문에 나쁜 것입니다.
우리의 구어 역시 결국 전역 기억을 사용합니다. 우리는 현재 대화 주제에 속하는 단어뿐만 아니라 모든 단어를 알고 기억합니다. 우리 마음속에는 모든 것이 뒤섞여 있습니다. 그것이 마음이 작동하는 방식이고 내 접근 방식이 작동하는 방식입니다. 기능 블록의 모든 중요한 출력은 보편적으로 사용 가능합니다. 따라서 그 안에는 거의 인간 용어가 있습니다. 나는 일반 언어처럼 코드로 말한다. 그것은 매우 편안합니다. 하지만 기억해야 할 것이 많습니다. 사실이야
추신. 그건 그렇고, 거대한 스위치는 파일로 분할되어 내용을 숨길 수 있습니다. 모든 것을 전체적으로 볼 수 있어 편합니다.
Tin, 일반적으로 받아 들여지는 접근 방식에 대한 적절한 연구 없이 일종의 자전거 제작을 하고 있습니다. Piotr, 좋은 책, 아마도 Stroustrup을 찾으세요. 그가 텍스트 편집기를 쓴 책에서 실제 문제에 대해 무언가를 그릴 수 있습니다. 내용은 기억나지 않지만 그는 나쁜 것을 가르칠 것 같지 않습니다.
물론 감사합니다. 그러나 지난 6년 동안 무수히 많은 문제를 풀었기 때문에 특정 작업이 무언가에 눈을 뜨게 할 것 같지는 않습니다. 정말 헤아릴 수 없습니다. 그러므로 나는 내가 무슨 말을 하는지 압니다.
많은 작업이 있지만 여전히 과부하의 유용성을 이해하지 못했습니다. 함수가 템플릿화되고 int, double 또는 사용자 정의 유형이 인수를 전달할 수 있고 abs()를 통해 절대값 을 찾고 싶다고 상상해보십시오. 어떻게 오버로드 없이?
프로젝트가 성장함에 따라 이러한 배열 주위의 목발을 살펴보겠습니다. 우리는 자동차 바퀴 -> 4개의 휠체어가 있는 자동차 -> 100대의 자동차가 있는 도로를 모델링합니다.
이제 효율성으로 넘어갑니다. 스위치 - 결국 무엇입니까? 이것은 매개변수와 상수를 순차적으로 비교하는 것입니다. 피터, 일관성에주의를 기울이십시오.
아니요, 스위치는 다르게 작동합니다. 원하는 상수로 즉시 전환이 수행되는 테이블입니다. 이것이 if 블록과의 본질적인 차이점입니다.
이제 효율성으로 넘어갑니다. 스위치 - 결국 무엇입니까? 이것은 매개변수와 상수를 순차적으로 비교하는 것입니다. 피터, 일관성에주의를 기울이십시오. 즉, 원하는 상수가 100500번째이면 이러한 모든 비교가 프로세서에서 수행됩니다. 오버로드된 함수/메서드란 머신 코드에서 컴파일 후 자체 진입점이 있는 완전히 다른 코드 블록입니다. 그렇다면 어느 것이 더 효율적일까요?
아아, 피할 수 없는 오버헤드. 이것에서 나는 지고, 다른 것에서 나는 이긴다.
예: 거대한 스위치가 있는 동일한 기능은 요소의 개체 위치와 창의 요소 위치를 정렬합니다. 크기를 계산합니다. 한 번 호출하면 모든 요소와 모든 개체가 바인딩에 따라 해당 위치에 배치됩니다. 서로에 대한 크기와 위치가 계산됩니다. 숨길 요소, 필요한 캔버스 크기 등 결정... 한 번의 호출로 많은 작업이 수행됩니다. 동일한 블록은 천 개 중 하나의 창 요소의 크기나 위치를 계산할 수 있습니다. 한 블록. 호출 - Object();
그렇게 많은 문제를 풀기 위해 OOP에서 얼마나 많은 클래스와 함수를 작성해야 합니까? 상상하기가 두렵다.
아아, 피할 수 없는 오버헤드. 이것에서 나는 지고, 다른 것에서 나는 이긴다.
예: 거대한 스위치가 있는 동일한 기능은 요소의 개체 위치와 창의 요소 위치를 정렬합니다. 한 번 호출하면 모든 요소와 모든 개체가 바인딩에 따라 해당 위치에 배치됩니다. 크기와 위치가 계산됩니다. 숨길 요소, 필요한 캔버스 크기 등 결정... 한 번의 호출로 많은 작업이 수행됩니다. 동일한 블록은 천 개 중 하나의 창 요소의 크기나 위치를 계산할 수 있습니다. 한 블록.
그렇게 많은 문제를 풀기 위해 OOP에서 얼마나 많은 클래스와 함수를 작성해야 합니까? 상상하기가 두렵다.
아니요, 스위치는 다르게 작동합니다. 원하는 상수로 즉시 전환이 수행되는 테이블입니다. 이것이 if 블록과의 본질적인 차이점입니다.
매개변수 없이 함수를 만들고, 내부에서 오버로드된 함수의 모든 계산을 작성하고, 변수를 전역으로 만들고, 다른 함수의 결과에 액세스할 수 있습니다. 글쎄, 그것은 아름다움입니다!