Alexey Navoykov : 현재 작업 중인 프로젝트의 모든 것을 기억합니다. 과거 코드는 어떻습니까? 당신은 1년 전에 썼던 것만큼 철저하게 기억하고 있습니까? 어디가 바뀌는지 등등 다음은 이전 코드를 약간 수정하거나 수정하는 작업입니다.
그리고 이 모든 것은 OOP와 아무 관련이 없습니다. 코드가 전역 변수에 대한 공개 액세스를 기반으로 구축된 경우 이는 모든 패러다임, 절차적 또는 OOP에서 허용되지 않으며 기능적으로는 더욱 그렇습니다. 그러므로 나는 당신의 "쿵푸"를 OOP에 반대할 이유가 없다고 생각합니다.
모든 것은 Peter의 놀라운 기억에 달려 있습니다.
그리고 나는 동의합니다 . 프로젝트 전체에서 사용하는 모든 변수를 기억한다면 언제 어디서 수정되는지, 잘못된 수정을 위한 장소를 쉽게 찾을 수 있습니다. 그러면 사실 바로 이 OOP의 의미가 손실됩니다. Peter는 사실 "어셈블러 수준"에서 일합니다. OOP 프릴과 디자인 패턴이 무엇이든 결국 모든 데이터 액세스는 일반 메모리 주소이며 프로세스에 할당된 주소 공간 내에서 모든 메모리 주소에 완전히 액세스할 수 있습니다. 프로세서 자체는 캡슐화에 대해 아무것도 모릅니다.
Alexey Navoykov : 그렇다면 그가 항상 작업하는 동일한 프로젝트에 관한 현상은 무엇입니까? 당연히 모든 프로그래머는 항상 이 모든 것을 머릿속에 가지고 있을 것입니다.
이제, 시간이 지나면 이 코드를 명확하게 기억할 수 있다면 또 다른 대화가 이어집니다.
글쎄요, 그럼 저는 아무나 아닙니다. 저도 주로 하나의 프로젝트 를 진행하지만, 핵심만 기억합니다. 어떤 절차에서 어떤 절차가 수정되고 있는지와 같은 미묘함 - 직접 개발할 때만 봅니다. 그런 다음 이 섹션으로 돌아가면 왜 여기 있고 다른 곳에서는 없는지 이해하려고 많은 시간을 할애합니다. 결과적으로 나는 전면적인 "권리할례"의 지지자이므로 이상적으로는 프로그램의 어느 곳에서나 이 곳에서 해야 할 일만 가능합니다.
Alexey Navoykov : 현재 작업 중인 프로젝트의 모든 것을 기억합니다. 과거 코드는 어떻습니까? 당신은 1년 전에 썼던 것만큼 철저하게 기억하고 있습니까? 어디가 바뀌는지 등등 다음은 이전 코드를 약간 수정하거나 수정하는 작업입니다.
그리고 이 모든 것은 OOP와 아무 관련이 없습니다. 코드가 전역 변수에 대한 공개 액세스를 기반으로 구축된 경우 이는 모든 패러다임, 절차적 또는 OOP에서 허용되지 않으며 기능적으로는 더욱 그렇습니다. 그러므로 나는 당신의 "쿵푸"를 OOP에 반대할 이유가 없다고 생각합니다.
예, 나는 오래된 코드를 매우 빨리 기억하고 이해합니다. 프로젝트 가 너무 커서 몇 달 또는 몇 년 동안 일부 부분이 변경되지 않고 무언가(예: 고대 목록)를 개선해야 할 때 모든 세부 사항을 짧은 시간에 이해하고 어떻게 작업했는지 기억을 새로 고칩니다. 소스에 거의 없는 주석 없이 작동합니다. 베어 코드를 본 기억이 있습니다. 그리고 어떤 이유에서인지 모든 사람이 할 수 있는 것 같습니다.
그리고 이 모든 것은 OOP와 아무 관련이 없습니다. 코드가 전역 변수에 대한 공개 액세스를 기반으로 구축된 경우 이는 모든 패러다임, 절차적 또는 OOP에서 허용되지 않으며 기능적으로는 더욱 그렇습니다. 그러므로 나는 당신의 "쿵푸"를 OOP에 반대할 이유가 없다고 봅니다.
아니요, 쿵푸는 여기에서 OOP입니다. 많은 움직임과 트릭이 있으며 그 중 10%는 싸움에서 유용할 것입니다. 그러나 얼마나 아름다운 스타일입니까! 그리고 용, 원숭이, 그리고 두꺼비와 플라밍고 ... 특정 삼보가 있습니다. Rubanul 결과를 얻었습니다.
아니요, 쿵푸는 여기에서 OOP입니다. 많은 움직임과 트릭이 있으며 그 중 10%는 싸움에서 유용할 것입니다. 그러나 얼마나 아름다운 스타일입니까! 그리고 용, 원숭이, 그리고 두꺼비와 플라밍고 ... 특정 삼보가 있습니다. Rubanul 결과를 얻었습니다.
이것은 사실이 아닙니다.
캡슐화의 유용성과 권리 제한에 대해 - 이미 백 번 말했습니다.
상속과 다형성의 유용성은 공통 가상 인터페이스가 있는 요소 목록에 대한 작업이 있는 경우 명확하게 볼 수 있지만 구현은 크게 다릅니다.
여기에서 내가 이번 주에 문자 그대로 접한 가장 간단한 상황은 구조체 목록이며, 필드 중 하나는 이중 값입니다. LSM의 도움으로 이러한 값을 근사화하는 아이디어가 있었습니다.
OOP가 없으면 해당 SLAE를 생성하고 해결하는 완전한 절차를 작성해야 합니다. 또는 값 배열로 작업하기 위한 그러한 프로그램이 이미 있는 경우 그러한 배열을 생성하고 라이브러리 함수에 전달하는 프로시저를 작성하십시오.
OOP 사용 - CLSMCore 클래스에서 상속하고 포인트 값을 반환하는 가상 함수 를 오버로드합니다. 근사 다항식의 계수를 즉시 얻을 수 있습니다.
즉, 동일한 조건(라이브러리 함수 또는 클래스가 있는 경우)에서 - OOP가 없으면 추가 중간 배열을 가짐으로써 잃게 됩니다. 정확히 어떻게 작성해야 하는지 알아야 한다는 사실은 말할 것도 없습니다. (값을 얻기 위한 함수 - OOP가 있는 경우와 없는 경우 모두 작성해야 함). 제 생각에 가장 중요한 장점은 지원 및 수정의 단순성입니다. OOP와 함께 - 덜 이해하기 위해. 게다가 처음에는 OOP를 사용하지 않고 라이브러리 근사화 함수에 썼던 것만큼 CLSMCore 클래스를 작성하는 데 절대적으로 많은 노력을 기울였습니다.
상속과 다형성의 유용성은 공통 가상 인터페이스가 있는 요소 목록에 대한 작업이 있는 경우 명확하게 볼 수 있지만 구현은 크게 다릅니다.
여기에서 내가 이번 주에 문자 그대로 접한 가장 간단한 상황은 구조체 목록이며, 필드 중 하나는 이중 값입니다. LSM의 도움으로 이러한 값을 근사화하는 아이디어가 있었습니다.
OOP가 없으면 해당 SLAE를 생성하고 해결하는 완전한 절차를 작성해야 합니다. 또는 값 배열로 작업하기 위한 그러한 프로그램이 이미 있는 경우 그러한 배열을 생성하고 라이브러리 함수에 전달하는 프로시저를 작성하십시오.
OOP 사용 - CLSMCore 클래스에서 상속하고 포인트 값을 반환하는 가상 함수 를 오버로드합니다. 근사 다항식의 계수를 즉시 얻을 수 있습니다.
즉, 동일한 조건(라이브러리 함수 또는 클래스가 있는 경우)에서 - OOP가 없으면 추가 중간 배열을 가짐으로써 잃게 됩니다. 정확히 어떻게 작성해야 하는지 알아야 한다는 사실은 말할 것도 없습니다. (값을 얻기 위한 함수 - OOP가 있는 경우와 없는 경우 모두 작성해야 함). 제 생각에 가장 중요한 장점은 지원 및 수정의 단순성입니다. OOP와 함께 - 덜 이해합니다. 게다가 처음에는 OOP를 사용하지 않고 라이브러리 근사화 함수에 썼던 것만큼 CLSMCore 클래스를 작성하는 데 절대적으로 많은 노력을 기울였습니다.
예를 들어, 함수 오버로딩이 필요한 이유를 결코 이해하지 못했습니다. 결국 이것은 일종의 터무니없는 일입니다 ... 우리는 매개 변수가없는 함수를 만들고 내부에서 오버로드 된 함수의 모든 계산을 작성하고 변수를 전역으로 만들고 다른 함수의 결과에 액세스 할 수 있습니다. 글쎄, 그것은 아름다움입니다!
하지만! 모든 계산을 이름은 같지만 매개변수가 다른 함수로 나눕니다. 그리고 우리는 각 함수에 대한 많은 입력 매개변수를 만들 것입니다. 아니요. 충분하지 않다. 매개변수의 이름도 읽을 수 없도록 합시다. 그리고 그들 사이에 산재되어 모든 종류의 배열이 전송되었습니다. 그리고 우리는 각각에 대해 더 오래 생각하기 위해 그러한 기능을 수십 개 만들 것입니다. 그리고 그들에 대한 액세스는 암호화되었습니다. 구문을 더 과시하기 위해. 이제는 전문성이다!
미안해 조지. 삶은 것.
추신. 10개의 오버로드된 함수의 결과를 위한 하나의 전역 배열과 해당 작업을 수행하는 하나의 매개변수 없는 함수. 뭐가 더 나빠? 구문이 10배 적습니다.
예를 들어, 함수 오버로딩이 필요한 이유를 결코 이해하지 못했습니다. 결국 이것은 일종의 터무니없는 일입니다 ... 우리는 매개 변수가없는 함수를 만들고 내부에서 오버로드 된 함수의 모든 계산을 작성하고 변수를 전역으로 만들고 다른 함수의 결과에 액세스 할 수 있습니다. 글쎄, 그것은 아름다움입니다!
하지만! 모든 계산을 이름은 같지만 매개변수가 다른 함수로 나눕니다. 그리고 우리는 각 함수에 대한 많은 입력 매개변수를 만들 것입니다. 아니요. 충분하지 않다. 매개변수의 이름도 읽을 수 없도록 합시다. 그리고 그것들과 혼합되어 모든 종류의 배열이 전송되었습니다. 그리고 우리는 각각에 대해 더 오래 생각하기 위해 그러한 기능을 수십 개 만들 것입니다. 그리고 그들에 대한 액세스는 암호화되었습니다. 구문을 더 과시하기 위해. 이제는 전문성이다!
미안해 조지. 삶은 것.
추신. 10개의 오버로드된 함수의 결과를 위한 하나의 전역 배열과 해당 작업을 수행하는 하나의 매개변수 없는 함수. 뭐가 더 나빠? 구문이 10배 적습니다.
여기에서 이 기능에 대해 더 자세히 설명합니다. 당신에게는 열 가지 필요한 기능 중 하나를 선택하는 거대한 크기 스위치가 있습니다. 이러한 스위치에서 실수로 분기 중 하나와 관련된 코드를 잘못된 위치에 작성하여 실수를 범하기 쉽습니다.
과부하 - 모든 것이 훨씬 쉽습니다. 우리는 10개의 다른 자손을 가지고 있고, 우리가 하나의 클래스로 작업할 때마다 하나의 오버로드된 기능이 있습니다. 완전히 다른 파일을 열어야 하기 때문에 실수로 다른 클래스에 쓸 수 없습니다.
게다가 - 이 매우 거대한 스위치에 있는 시험 자체 - 제 생각에는 하나의 필요한 수업을 개설한 다음 하나의 기능만 있는 시험을 여는 것보다 훨씬 더 스트레스가 많습니다.
사실, 어셈블러 코드에서 이 모든 오버로드는 this 포인터에 따라 어떤 경우에도 동일한 스위치로 귀결됩니다. 그러나 OOP의 경우 이 모든 것이 프로그래머에게 숨겨져 있으며 그의 작업에 방해가 되지 않습니다. OOP가 없으면 처리해야 합니다.
대략적으로 말하자면, 걸을 때 근육을 움직이게 하는 특정 순서로 신호를 근육에 보내게 됩니다. 그러나 의식 수준에서는 어떤 움직임이 필요한지 기억하기만 하면 됩니다. 여기서 OOP는 바로 "메모리, 어떤 움직임이 필요한가"입니다. 당신은 "많은 근육과 신경이 연결되어 있다면 왜 그 움직임을 기억하는지 이해하지 못합니다." 음... 기억의 거인을 위해 이미 여러 번 말했지만 실제로 걷기 위해 어떤 근육을 어떤 순서로 긴장시켜야 하는지 기억하는 것으로 충분합니다. 이 운동을 전체적으로 기억하는 것은 의미가 없습니다. 그렇게 많이 기억하지 못하는 나머지 사람들에게는 전체 움직임과 근육의 상태, 근육이 조이는 순서와 정도를 정확히 기억하는 것이 훨씬 더 합리적입니다. 의식에서 숨기는 것이 더 합리적입니다.
예를 들어, 함수 오버로딩이 필요한 이유를 결코 이해하지 못했습니다. 결국 이것은 일종의 터무니없는 일입니다 ... 우리는 매개 변수가없는 함수를 만들고 내부에서 오버로드 된 함수의 모든 계산을 작성하고 변수를 전역으로 만들고 다른 함수의 결과에 액세스 할 수 있습니다. 글쎄, 그것은 아름다움입니다!
Tin, 일반적으로 받아 들여지는 접근 방식에 대한 적절한 연구 없이 일종의 자전거 제작을 하고 있습니다. Piotr, 좋은 책, 아마도 Stroustrup을 찾으세요. 그가 텍스트 편집기를 쓴 책에서 실제 문제에 대해 무언가를 그릴 수 있습니다. 내용은 기억나지 않지만 그는 나쁜 것을 가르칠 것 같지 않습니다.
그는 심각하다!
바로 지금 내 개념에 특허를 낼 것입니다. 투자자들이 있습니다. 그래서 모든 것이 심각합니다.
어젯밤에 나는 꿈이 올 것이라는 주제를 읽었습니다 .... 어떤 이유에서인지 길고 긴 Windows 개발자 목록을 발표했습니다. 글쎄요, Star Wars 크레딧에서처럼요!
그리고 목록의 끝에 - 큰 글자 Peter Konow!
@Peter Konow 그런 텍스트 스프라이트를 할 수 있습니까? ;)현재 작업 중인 프로젝트의 모든 것을 기억합니다. 과거 코드는 어떻습니까? 당신은 1년 전에 썼던 것만큼 철저하게 기억하고 있습니까? 어디가 바뀌는지 등등 다음은 이전 코드를 약간 수정하거나 수정하는 작업입니다.
모든 것은 Peter의 놀라운 기억에 달려 있습니다.
그리고 나는 동의합니다 . 프로젝트 전체에서 사용하는 모든 변수를 기억한다면 언제 어디서 수정되는지, 잘못된 수정을 위한 장소를 쉽게 찾을 수 있습니다. 그러면 사실 바로 이 OOP의 의미가 손실됩니다. Peter는 사실 "어셈블러 수준"에서 일합니다. OOP 프릴과 디자인 패턴이 무엇이든 결국 모든 데이터 액세스는 일반 메모리 주소이며 프로세스에 할당된 주소 공간 내에서 모든 메모리 주소에 완전히 액세스할 수 있습니다. 프로세서 자체는 캡슐화에 대해 아무것도 모릅니다.
그게 바로 Peter가 하는 일입니다. 나 자신도 어셈블러를 좋아했던 때가 있었습니다.
유일한 질문은 기억 능력에서 프로세서와 경쟁하는 방법입니다.
모든 것은 Peter의 놀라운 기억에 달려 있습니다.
...
유일한 질문은 기억 능력에서 프로세서와 경쟁하는 방법입니다.
그렇다면 그가 항상 작업하는 동일한 프로젝트에 관한 현상은 무엇입니까? 당연히 모든 프로그래머는 항상 이 모든 것을 머릿속에 가지고 있을 것입니다.
글쎄요, 그럼 저는 아무나 아닙니다. 저도 주로 하나의 프로젝트 를 진행하지만, 핵심만 기억합니다. 어떤 절차에서 어떤 절차가 수정되고 있는지와 같은 미묘함 - 직접 개발할 때만 봅니다. 그런 다음 이 섹션으로 돌아가면 왜 여기 있고 다른 곳에서는 없는지 이해하려고 많은 시간을 할애합니다. 결과적으로 나는 전면적인 "권리할례"의 지지자이므로 이상적으로는 프로그램의 어느 곳에서나 이 곳에서 해야 할 일만 가능합니다.
현재 작업 중인 프로젝트의 모든 것을 기억합니다. 과거 코드는 어떻습니까? 당신은 1년 전에 썼던 것만큼 철저하게 기억하고 있습니까? 어디가 바뀌는지 등등 다음은 이전 코드를 약간 수정하거나 수정하는 작업입니다.
Alexey Navoykov :
...
아니요, 쿵푸는 여기에서 OOP입니다. 많은 움직임과 트릭이 있으며 그 중 10%는 싸움에서 유용할 것입니다. 그러나 얼마나 아름다운 스타일입니까! 그리고 용, 원숭이, 그리고 두꺼비와 플라밍고 ... 특정 삼보가 있습니다. Rubanul 결과를 얻었습니다.
아니요, 쿵푸는 여기에서 OOP입니다. 많은 움직임과 트릭이 있으며 그 중 10%는 싸움에서 유용할 것입니다. 그러나 얼마나 아름다운 스타일입니까! 그리고 용, 원숭이, 그리고 두꺼비와 플라밍고 ... 특정 삼보가 있습니다. Rubanul 결과를 얻었습니다.
이것은 사실이 아닙니다.
캡슐화의 유용성과 권리 제한에 대해 - 이미 백 번 말했습니다.
상속과 다형성의 유용성은 공통 가상 인터페이스가 있는 요소 목록에 대한 작업이 있는 경우 명확하게 볼 수 있지만 구현은 크게 다릅니다.
여기에서 내가 이번 주에 문자 그대로 접한 가장 간단한 상황은 구조체 목록이며, 필드 중 하나는 이중 값입니다. LSM의 도움으로 이러한 값을 근사화하는 아이디어가 있었습니다.
OOP가 없으면 해당 SLAE를 생성하고 해결하는 완전한 절차를 작성해야 합니다. 또는 값 배열로 작업하기 위한 그러한 프로그램이 이미 있는 경우 그러한 배열을 생성하고 라이브러리 함수에 전달하는 프로시저를 작성하십시오.
OOP 사용 - CLSMCore 클래스에서 상속하고 포인트 값을 반환하는 가상 함수 를 오버로드합니다. 근사 다항식의 계수를 즉시 얻을 수 있습니다.
즉, 동일한 조건(라이브러리 함수 또는 클래스가 있는 경우)에서 - OOP가 없으면 추가 중간 배열을 가짐으로써 잃게 됩니다. 정확히 어떻게 작성해야 하는지 알아야 한다는 사실은 말할 것도 없습니다. (값을 얻기 위한 함수 - OOP가 있는 경우와 없는 경우 모두 작성해야 함). 제 생각에 가장 중요한 장점은 지원 및 수정의 단순성입니다. OOP와 함께 - 덜 이해하기 위해. 게다가 처음에는 OOP를 사용하지 않고 라이브러리 근사화 함수에 썼던 것만큼 CLSMCore 클래스를 작성하는 데 절대적으로 많은 노력을 기울였습니다.
이것은 사실이 아닙니다.
캡슐화의 유용성과 권리 제한에 대해 - 이미 백 번 말했습니다.
상속과 다형성의 유용성은 공통 가상 인터페이스가 있는 요소 목록에 대한 작업이 있는 경우 명확하게 볼 수 있지만 구현은 크게 다릅니다.
여기에서 내가 이번 주에 문자 그대로 접한 가장 간단한 상황은 구조체 목록이며, 필드 중 하나는 이중 값입니다. LSM의 도움으로 이러한 값을 근사화하는 아이디어가 있었습니다.
OOP가 없으면 해당 SLAE를 생성하고 해결하는 완전한 절차를 작성해야 합니다. 또는 값 배열로 작업하기 위한 그러한 프로그램이 이미 있는 경우 그러한 배열을 생성하고 라이브러리 함수에 전달하는 프로시저를 작성하십시오.
OOP 사용 - CLSMCore 클래스에서 상속하고 포인트 값을 반환하는 가상 함수 를 오버로드합니다. 근사 다항식의 계수를 즉시 얻을 수 있습니다.
즉, 동일한 조건(라이브러리 함수 또는 클래스가 있는 경우)에서 - OOP가 없으면 추가 중간 배열을 가짐으로써 잃게 됩니다. 정확히 어떻게 작성해야 하는지 알아야 한다는 사실은 말할 것도 없습니다. (값을 얻기 위한 함수 - OOP가 있는 경우와 없는 경우 모두 작성해야 함). 제 생각에 가장 중요한 장점은 지원 및 수정의 단순성입니다. OOP와 함께 - 덜 이해합니다. 게다가 처음에는 OOP를 사용하지 않고 라이브러리 근사화 함수에 썼던 것만큼 CLSMCore 클래스를 작성하는 데 절대적으로 많은 노력을 기울였습니다.
예를 들어, 함수 오버로딩이 필요한 이유를 결코 이해하지 못했습니다. 결국 이것은 일종의 터무니없는 일입니다 ... 우리는 매개 변수가없는 함수를 만들고 내부에서 오버로드 된 함수의 모든 계산을 작성하고 변수를 전역으로 만들고 다른 함수의 결과에 액세스 할 수 있습니다. 글쎄, 그것은 아름다움입니다!
하지만! 모든 계산을 이름은 같지만 매개변수가 다른 함수로 나눕니다. 그리고 우리는 각 함수에 대한 많은 입력 매개변수를 만들 것입니다. 아니요. 충분하지 않다. 매개변수의 이름도 읽을 수 없도록 합시다. 그리고 그들 사이에 산재되어 모든 종류의 배열이 전송되었습니다. 그리고 우리는 각각에 대해 더 오래 생각하기 위해 그러한 기능을 수십 개 만들 것입니다. 그리고 그들에 대한 액세스는 암호화되었습니다. 구문을 더 과시하기 위해. 이제는 전문성이다!
미안해 조지. 삶은 것.
추신. 10개의 오버로드된 함수의 결과를 위한 하나의 전역 배열과 해당 작업을 수행하는 하나의 매개변수 없는 함수. 뭐가 더 나빠? 구문이 10배 적습니다.
예를 들어, 함수 오버로딩이 필요한 이유를 결코 이해하지 못했습니다. 결국 이것은 일종의 터무니없는 일입니다 ... 우리는 매개 변수가없는 함수를 만들고 내부에서 오버로드 된 함수의 모든 계산을 작성하고 변수를 전역으로 만들고 다른 함수의 결과에 액세스 할 수 있습니다. 글쎄, 그것은 아름다움입니다!
하지만! 모든 계산을 이름은 같지만 매개변수가 다른 함수로 나눕니다. 그리고 우리는 각 함수에 대한 많은 입력 매개변수를 만들 것입니다. 아니요. 충분하지 않다. 매개변수의 이름도 읽을 수 없도록 합시다. 그리고 그것들과 혼합되어 모든 종류의 배열이 전송되었습니다. 그리고 우리는 각각에 대해 더 오래 생각하기 위해 그러한 기능을 수십 개 만들 것입니다. 그리고 그들에 대한 액세스는 암호화되었습니다. 구문을 더 과시하기 위해. 이제는 전문성이다!
미안해 조지. 삶은 것.
추신. 10개의 오버로드된 함수의 결과를 위한 하나의 전역 배열과 해당 작업을 수행하는 하나의 매개변수 없는 함수. 뭐가 더 나빠? 구문이 10배 적습니다.
여기에서 이 기능에 대해 더 자세히 설명합니다. 당신에게는 열 가지 필요한 기능 중 하나를 선택하는 거대한 크기 스위치가 있습니다. 이러한 스위치에서 실수로 분기 중 하나와 관련된 코드를 잘못된 위치에 작성하여 실수를 범하기 쉽습니다.
과부하 - 모든 것이 훨씬 쉽습니다. 우리는 10개의 다른 자손을 가지고 있고, 우리가 하나의 클래스로 작업할 때마다 하나의 오버로드된 기능이 있습니다. 완전히 다른 파일을 열어야 하기 때문에 실수로 다른 클래스에 쓸 수 없습니다.
게다가 - 이 매우 거대한 스위치에 있는 시험 자체 - 제 생각에는 하나의 필요한 수업을 개설한 다음 하나의 기능만 있는 시험을 여는 것보다 훨씬 더 스트레스가 많습니다.
사실, 어셈블러 코드에서 이 모든 오버로드는 this 포인터에 따라 어떤 경우에도 동일한 스위치로 귀결됩니다. 그러나 OOP의 경우 이 모든 것이 프로그래머에게 숨겨져 있으며 그의 작업에 방해가 되지 않습니다. OOP가 없으면 처리해야 합니다.
대략적으로 말하자면, 걸을 때 근육을 움직이게 하는 특정 순서로 신호를 근육에 보내게 됩니다. 그러나 의식 수준에서는 어떤 움직임이 필요한지 기억하기만 하면 됩니다. 여기서 OOP는 바로 "메모리, 어떤 움직임이 필요한가"입니다. 당신은 "많은 근육과 신경이 연결되어 있다면 왜 그 움직임을 기억하는지 이해하지 못합니다." 음... 기억의 거인을 위해 이미 여러 번 말했지만 실제로 걷기 위해 어떤 근육을 어떤 순서로 긴장시켜야 하는지 기억하는 것으로 충분합니다. 이 운동을 전체적으로 기억하는 것은 의미가 없습니다. 그렇게 많이 기억하지 못하는 나머지 사람들에게는 전체 움직임과 근육의 상태, 근육이 조이는 순서와 정도를 정확히 기억하는 것이 훨씬 더 합리적입니다. 의식에서 숨기는 것이 더 합리적입니다.
Реter Konow :
예를 들어, 함수 오버로딩이 필요한 이유를 결코 이해하지 못했습니다. 결국 이것은 일종의 터무니없는 일입니다 ... 우리는 매개 변수가없는 함수를 만들고 내부에서 오버로드 된 함수의 모든 계산을 작성하고 변수를 전역으로 만들고 다른 함수의 결과에 액세스 할 수 있습니다. 글쎄, 그것은 아름다움입니다!
Tin, 일반적으로 받아 들여지는 접근 방식에 대한 적절한 연구 없이 일종의 자전거 제작을 하고 있습니다. Piotr, 좋은 책, 아마도 Stroustrup을 찾으세요. 그가 텍스트 편집기를 쓴 책에서 실제 문제에 대해 무언가를 그릴 수 있습니다. 내용은 기억나지 않지만 그는 나쁜 것을 가르칠 것 같지 않습니다.