위에서 언급한 것이 사실입니다. 접근 방식은 Pascal의 TurboVision과 유사합니다. 그러나 유형 제어 및 캡슐화 제한이 모두 이 라이브러리에 이미 설정되어 있습니다.
나는 Pascal을 보았고 심지어 Turbovision도 교실에서 두어 번 연결하는 것을 보았기 때문에 기억했습니다. 매우 불쾌한 기억, Turbovision이 그것을 어떻게 꼬아도 기억나는 것은 여전히 출력에서 Norton Commander만 얻을 수 있습니다. 매우 전문화되어 있습니다. 제가 틀리지 않았다면 Pascal 6.0에는 OOP가 없었습니다.
나는 Pascal을 보았고 심지어 Turbovision도 교실에서 두어 번 연결하는 것을 보았기 때문에 기억했습니다. 매우 불쾌한 기억, Turbovision이 그것을 어떻게 꼬아도 기억나는 것은 여전히 출력에서 Norton Commander만 얻을 수 있습니다. 매우 전문화되어 있습니다. 제가 틀리지 않았다면 Pascal 6.0에는 OOP가 없었습니다.
내가 기억하는 대로 TurboVision은 최초의 OOP 라이브러리(당시에는 불완전한 이데올로기 지원이 있었지만 여전히)였으며 Pascal 6.0에 등장했습니다.
В 1997 г. Borland открыла исходные тексты Turbo Vision на C++ и на их основе сторонние разработчики стали создавать свои реализации библиотеки. Исходные тексты Pascal-версии Turbo Vision 1.0 поставлялись в комплекте с Turbo Pascal 6.0, а исходники Turbo Vision 2.0 включались в Borland Pascal 7.0 и Turbo Pascal 7.0. В комплекты поставок также...
파스칼을 위한 본격적인 OOP는 델파이에서 처음 등장했습니다. Turbo Vision은 Ms-DOS에서 텍스트 기반 GUI를 독점적으로 처리했습니다.
글쎄, 그것이 내가 말하는 것입니다 - "불완전한 지원으로". 여섯 번째 파스칼은 "물체가 있는 파스칼"이었습니다. 맞습니다. TurboVision은 독점적으로 창 인터페이스였습니다. 글쎄, Peter가 당신의 관심을 끄는 것에 대해.
사실, Peter의 창조물은 꽤 흥미롭습니다. 질문은 적용 가능성에 관한 것입니다. 전 세계적으로 액세스할 수 있는 개체와 만능 코드 캡슐화가 없다는 사실을 이미 알게 되었고, 많은 오류를 방지하고 버그를 지원하고 수정하는 데 도움이 되는 순수 가상 인터페이스를 통해서만 작업했습니다. 실제로 Peter는 "프로그래머의 편의에 따라"라고 정확하게 지적했습니다.
모든 기능 의 배열에 대한 전체 액세스 - 이론적으로 인터페이스 래퍼, 유형 제어 및 변환, 객체 액세스를 위한 프로토콜 준수에 대한 오버헤드 비용이 없기 때문에 실제로 더 큰 효율성을 달성할 수 있습니다... 그러나 모든 이것은 프로그래머 자신이 기억하고 고려해야 하는 이러한 모든 사실 때문에 시간으로 달성됩니다.
이 접근 방식을 사용하면 가능한 모든 방법으로 작업을 컴퓨터로 옮기는 대신 스스로 수행하게 됩니다. 기억의 거인인 피터는 이에 부담을 느끼지 않는다. 하지만 다른 사람들에게는 매우 스트레스가 될 것 같습니다. 그리고 당신은 단지 몇 가지 큰 이점을 위해 이것에 동의할 수 있습니다. 아아, 나는 그들을 볼 수 없습니다. 특히 Peter가 자동 거래가 아닌 수동 거래에 중점을 둔 점을 고려하면.
따라서 나는 OOP의 이점과 OOP가 없는 이점을 얻습니다. 그리고 당신은 OOP의 장점일 뿐입니다.
당신이 보고 있는 것을 말하기는 어렵지만, 우리가 기성 클래스를 수강하고 해당 메소드와 필드를 글로벌 가시성 수준(확장)으로 가져오면 귀하의 접근 방식을 얻을 수 있다고 말할 것입니다. 코어와 엔진 필드는 ... 처음부터 작성할 수 있지만 수정할 수는 없는 비관리 코드를 얻습니다.
추신:
OOP가 흥미로운 이유는 무엇입니까? - 예, 적어도 프로그래머가 새로운 변수 이름을 끊임없이 생각해내기 위해 증기 목욕을 하지 않는다는 사실! - 기본 클래스를 만들고 작성했습니다. 현재 보고 있는 모든 것이 거기에 있습니다. 때가 되었습니다. 상속을 완료했습니다. - 기본 클래스에서 즉시 많은 변수를 받았고 상속이 필요하지 않습니다. 방금 클래스의 인스턴스를 만들었습니다(예, 적어도 클래스 배열!) - 그리고 즉시 각 개체(클래스)에 대해 분할된 모든 변수를 얻었습니다... OOP는 적어도 실용적이고 실행 속도입니다. .. 글쎄, 우리는 항상 프로세서 레지스터로 직접 작업하거나 고급 언어를 사용합니다. 일반적으로 모든 것을 편리하게 작성할 수 있는 충분한 컴퓨팅 성능이 있습니다. 용량이 충분하지 않으면 코드의 문제 영역을 프로파일링하고 다시 작성하기 시작합니다. 이것을 하는 사람은 거의 없다
당신이 보고 있는 것을 말하기는 어렵지만, 우리가 기성 클래스를 수강하고 해당 메소드와 필드를 글로벌 가시성 수준(확장)으로 가져오면 귀하의 접근 방식을 얻을 수 있다고 말할 것입니다. 코어와 엔진 필드는 ... 처음부터 작성할 수 있지만 수정할 수는 없는 비관리 코드를 얻습니다.
추신:
OOP가 흥미로운 이유는 무엇입니까? - 예, 적어도 프로그래머가 새로운 변수 이름을 끊임없이 생각해내기 위해 증기 목욕을 하지 않는다는 사실! - 기본 클래스를 만들고 작성했습니다. 현재 보고 있는 모든 것이 거기에 있습니다. 때가 되었습니다. 상속을 완료했습니다. - 기본 클래스에서 즉시 많은 변수를 받았고 상속이 필요하지 않습니다. 방금 클래스의 인스턴스를 만들었습니다(예, 적어도 클래스 배열!) - 그리고 즉시 각 개체(클래스)에 대해 분할된 모든 변수를 얻었습니다... OOP는 적어도 실용적이고 실행 속도입니다. .. 글쎄, 우리는 항상 프로세서 레지스터로 직접 작업하거나 고급 언어를 사용합니다. 일반적으로 모든 것을 편리하게 작성할 수 있는 충분한 컴퓨팅 성능이 있습니다. 용량이 충분하지 않으면 코드의 문제 영역을 프로파일링하고 다시 작성하기 시작합니다. 소수의 사람들이 이것을
엄격한 코드 작성 형식은 OOP에서 저를 거부합니다. 보시다시피 저는 큰 데이터 테이블을 만드는 경향이 있으며 이것이 매우 실용적입니다. OOP에서는 개인적으로 나를 많이 속박하는 여러 규칙을 준수해야 합니다.
요컨대, 나는 다른 OOP로 프로그래밍하고 있습니다. 그의. 규칙은 적고 자유는 많습니다. 기능 자체는 큰 블록으로 구성되고 데이터는 코어에서 구성됩니다. 일부러 구조를 생각하지도 않는다. 모든 것은 스스로 발전합니다. 직관적인 수준에서.
위에서 언급한 것이 사실입니다. 접근 방식은 Pascal의 TurboVision과 유사합니다. 그러나 유형 제어 및 캡슐화 제한이 모두 이 라이브러리에 이미 설정되어 있습니다.
나는 Pascal을 보았고 심지어 Turbovision도 교실에서 두어 번 연결하는 것을 보았기 때문에 기억했습니다. 매우 불쾌한 기억, Turbovision이 그것을 어떻게 꼬아도 기억나는 것은 여전히 출력에서 Norton Commander만 얻을 수 있습니다. 매우 전문화되어 있습니다. 제가 틀리지 않았다면 Pascal 6.0에는 OOP가 없었습니다.
나는 Pascal을 보았고 심지어 Turbovision도 교실에서 두어 번 연결하는 것을 보았기 때문에 기억했습니다. 매우 불쾌한 기억, Turbovision이 그것을 어떻게 꼬아도 기억나는 것은 여전히 출력에서 Norton Commander만 얻을 수 있습니다. 매우 전문화되어 있습니다. 제가 틀리지 않았다면 Pascal 6.0에는 OOP가 없었습니다.
내가 기억하는 대로 TurboVision은 최초의 OOP 라이브러리(당시에는 불완전한 이데올로기 지원이 있었지만 여전히)였으며 Pascal 6.0에 등장했습니다.
위키피디아 를 살펴보았다. 그녀는 내 말에 동의하는 것 같다.
내가 기억하는 대로 TurboVision은 최초의 OOP 라이브러리(당시에는 불완전한 이데올로기 지원이 있었지만 여전히)였으며 Pascal 6.0에 등장했습니다.
위키피디아 를 살펴보았다. 그녀는 내 말에 동의하는 것 같다.
아아, 나는 어떻게 든 훈련에서이 순간을 성공적으로 통과했습니다. OOP는 C ++로만 표시되었으며 5 년 후에는 스스로 Delphi로 전환했습니다. Pascal은 절차 적 프로그래밍 언어로 내 비전에 남아있었습니다.
내가 기억하는 것처럼 TurboVision은 최초의 OOP 라이브러리(당시에는 불완전한 이데올로기 지원이 있었지만 여전히)였으며 Pascal 6.0에 등장했습니다.
위키피디아 를 살펴보았다. 그녀는 내 말에 동의하는 것 같다.
파스칼을 위한 본격적인 OOP는 델파이에서 처음 등장했습니다. Turbo Vision은 Ms-DOS에서 텍스트 기반 GUI를 독점적으로 처리했습니다.
파스칼을 위한 본격적인 OOP는 델파이에서 처음 등장했습니다. Turbo Vision은 Ms-DOS에서 텍스트 기반 GUI를 독점적으로 처리했습니다.
글쎄, 그것이 내가 말하는 것입니다 - "불완전한 지원으로". 여섯 번째 파스칼은 "물체가 있는 파스칼"이었습니다. 맞습니다. TurboVision은 독점적으로 창 인터페이스였습니다. 글쎄, Peter가 당신의 관심을 끄는 것에 대해.
사실, Peter의 창조물은 꽤 흥미롭습니다. 질문은 적용 가능성에 관한 것입니다. 전 세계적으로 액세스할 수 있는 개체와 만능 코드 캡슐화가 없다는 사실을 이미 알게 되었고, 많은 오류를 방지하고 버그를 지원하고 수정하는 데 도움이 되는 순수 가상 인터페이스를 통해서만 작업했습니다. 실제로 Peter는 "프로그래머의 편의에 따라"라고 정확하게 지적했습니다.
모든 기능 의 배열에 대한 전체 액세스 - 이론적으로 인터페이스 래퍼, 유형 제어 및 변환, 객체 액세스를 위한 프로토콜 준수에 대한 오버헤드 비용이 없기 때문에 실제로 더 큰 효율성을 달성할 수 있습니다... 그러나 모든 이것은 프로그래머 자신이 기억하고 고려해야 하는 이러한 모든 사실 때문에 시간으로 달성됩니다.
이 접근 방식을 사용하면 가능한 모든 방법으로 작업을 컴퓨터로 옮기는 대신 스스로 수행하게 됩니다. 기억의 거인인 피터는 이에 부담을 느끼지 않는다. 하지만 다른 사람들에게는 매우 스트레스가 될 것 같습니다. 그리고 당신은 단지 몇 가지 큰 이점을 위해 이것에 동의할 수 있습니다. 아아, 나는 그들을 볼 수 없습니다. 특히 Peter가 자동 거래가 아닌 수동 거래에 중점을 둔 점을 고려하면.
기억하는 비결은 생각이 구조화되어야 한다는 것입니다. OOP의 프리즘을 통해 코드를 살펴보아야 하지만 동시에 OOP 자체를 사용해서는 안 됩니다. 이것이 제가하는 것입니다. 당신은 프로그램에 OOP가 있고, 나는 그것을 내 머리에 가지고 있습니다.
따라서 나는 OOP의 이점과 OOP가 없는 이점을 얻습니다. 그리고 당신은 OOP의 장점일 뿐입니다.
기억하는 비결은 생각이 구조화되어야 한다는 것입니다. OOP의 프리즘을 통해 코드를 살펴보아야 하지만 동시에 OOP 자체를 사용해서는 안 됩니다. 이것이 제가하는 것입니다. 당신은 프로그램에 OOP가 있고, 나는 그것을 내 머리에 가지고 있습니다.
따라서 나는 OOP의 이점과 OOP가 없는 이점을 얻습니다. 그리고 당신은 OOP의 유일한 혜택입니다.
알림:
따라서 나는 OOP의 이점과 OOP가 없는 이점을 얻습니다. 그리고 당신은 OOP의 장점일 뿐입니다.
당신이 보고 있는 것을 말하기는 어렵지만, 우리가 기성 클래스를 수강하고 해당 메소드와 필드를 글로벌 가시성 수준(확장)으로 가져오면 귀하의 접근 방식을 얻을 수 있다고 말할 것입니다. 코어와 엔진 필드는 ... 처음부터 작성할 수 있지만 수정할 수는 없는 비관리 코드를 얻습니다.
추신:
OOP가 흥미로운 이유는 무엇입니까? - 예, 적어도 프로그래머가 새로운 변수 이름을 끊임없이 생각해내기 위해 증기 목욕을 하지 않는다는 사실! - 기본 클래스를 만들고 작성했습니다. 현재 보고 있는 모든 것이 거기에 있습니다. 때가 되었습니다. 상속을 완료했습니다. - 기본 클래스에서 즉시 많은 변수를 받았고 상속이 필요하지 않습니다. 방금 클래스의 인스턴스를 만들었습니다(예, 적어도 클래스 배열!) - 그리고 즉시 각 개체(클래스)에 대해 분할된 모든 변수를 얻었습니다... OOP는 적어도 실용적이고 실행 속도입니다. .. 글쎄, 우리는 항상 프로세서 레지스터로 직접 작업하거나 고급 언어를 사용합니다. 일반적으로 모든 것을 편리하게 작성할 수 있는 충분한 컴퓨팅 성능이 있습니다. 용량이 충분하지 않으면 코드의 문제 영역을 프로파일링하고 다시 작성하기 시작합니다. 이것을 하는 사람은 거의 없다
당신이 보고 있는 것을 말하기는 어렵지만, 우리가 기성 클래스를 수강하고 해당 메소드와 필드를 글로벌 가시성 수준(확장)으로 가져오면 귀하의 접근 방식을 얻을 수 있다고 말할 것입니다. 코어와 엔진 필드는 ... 처음부터 작성할 수 있지만 수정할 수는 없는 비관리 코드를 얻습니다.
추신:
OOP가 흥미로운 이유는 무엇입니까? - 예, 적어도 프로그래머가 새로운 변수 이름을 끊임없이 생각해내기 위해 증기 목욕을 하지 않는다는 사실! - 기본 클래스를 만들고 작성했습니다. 현재 보고 있는 모든 것이 거기에 있습니다. 때가 되었습니다. 상속을 완료했습니다. - 기본 클래스에서 즉시 많은 변수를 받았고 상속이 필요하지 않습니다. 방금 클래스의 인스턴스를 만들었습니다(예, 적어도 클래스 배열!) - 그리고 즉시 각 개체(클래스)에 대해 분할된 모든 변수를 얻었습니다... OOP는 적어도 실용적이고 실행 속도입니다. .. 글쎄, 우리는 항상 프로세서 레지스터로 직접 작업하거나 고급 언어를 사용합니다. 일반적으로 모든 것을 편리하게 작성할 수 있는 충분한 컴퓨팅 성능이 있습니다. 용량이 충분하지 않으면 코드의 문제 영역을 프로파일링하고 다시 작성하기 시작합니다. 소수의 사람들이 이것을
엄격한 코드 작성 형식은 OOP에서 저를 거부합니다. 보시다시피 저는 큰 데이터 테이블을 만드는 경향이 있으며 이것이 매우 실용적입니다. OOP에서는 개인적으로 나를 많이 속박하는 여러 규칙을 준수해야 합니다.
요컨대, 나는 다른 OOP로 프로그래밍하고 있습니다. 그의. 규칙은 적고 자유는 많습니다. 기능 자체는 큰 블록으로 구성되고 데이터는 코어에서 구성됩니다. 일부러 구조를 생각하지도 않는다. 모든 것은 스스로 발전합니다. 직관적인 수준에서.