프로그래밍에서 개체의 표현.

[Реter Konow]

이 주제는 글로벌 프로그래밍 문제에 관심이 있는 사람들에게 흥미로울 것입니다.

나는 " 왜 표준 OOP 개념에서 잘 알려진 객체 모델이 표준입니까? "라는 질문에 괴로워합니다. 내 말은, 개체는 사람들이 단어를 말할 때마다 단어로 설명하는 개체입니다. 프로그래밍의 출현으로 코드로 개체를 설명하려는 시도가 논리적으로 연결되어 특수 기능이 발명되었습니다. 기술 이지만 질문은 왜 하나뿐입니까? 마치 첫 번째 언어가 다른 언어를 완전히 대체하고 발전을 허용하지 않는 것처럼. 고대에는 불가능한 일이지만 세계화와 선전의 시대에는 가능합니다. 그리고 그렇게 일이 일어났습니다. 객체의 한 표현이 세계를 정복하고 다른 아이디어의 방향을 차단했습니다.

내가 (철학자로서) 그것에 대해 불만이 없었더라면 나는 오래 전에 대상의 표준 개념을 받아들였을 것입니다.

1. 첫째, 서문: 프로그래밍의 진화 단계는 주요 논문이 승인되었을 때 이루어졌습니다. 프로그래밍은 "객체"를 기본으로 삼고 모든 프로그램은 논리적으로 분할되어야 합니다. 즉 - 우리는 더 이상 알고리즘(연산 순서)을 작성하지 않고 "엔티티"를 만듭니다. 우리는 알고리즘을 구조에 배치하여 상호 작용의 일반적인 "앙상블"의 일부가 되도록 합니다. 왜요? - 더 효율적으로 일합니다. 그러나 여기에 질문 이 있습니다. "공식적으로 등록된" 객체의 철학적 개념은 어디에 있습니까? 아아, 그러한 것은 오늘날까지 존재하지 않으며 존재할 수도 없습니다.

이것은 OOP 개념의 작성자가 자신의 철학적 아이디어의 "무류성"에 의존하여 자의적으로 행동했음을 의미합니다.

2. 다음은 내 불만 사항 중 일부입니다.

(1) 표준 개념에 " 상태 " 도구가 없는 이유는 무엇입니까? 객체에는 상태가 없습니까? 상태 를 구조로 설명할 수 있지만 이는 불편합니다. 표준 개념은 개체 상태에 맞게 조정되지 않았습니다. 예: 나는 특별한 구조, 개체의 매개 변수 나열, 해당 부분(선택한 매개 변수) 복사, 이름 지정, 이 부분을 상태 로 정의하고 개체의 특정 상태에 해당하는 값을 씁니다. 그런 다음 개체의 주요 구조와 연결합니다.

(2) " 이벤트 " 도구가 없습니다. 내 말은, 이벤트 는 표준 개념에서 "부동"하지만 열거형, 클래스 또는 함수로 설명할 수 없습니다. 프로그래밍에서 이벤트에 대한 간단한 설명은 매우 유용합니다. 예를 들어, 우리는 그것을 구조로 설명하지만 그 안에서 우리 는 환경과 물체의 "배경" 상태를 가리키고 다른 변경 체인의 시작을 위한 트리거인 주요 변경을 가리킵니다. 다시 - OOP는 이벤트에 대한 간결한 설명에 초점을 맞추지 않고 이름이 없고 "어디에나" 위치하는 여러 조건에서 이벤트를 설명하는 것을 제안합니다.

(3) 또한 매개변수 는 독립된 객체가 아닙니다. 사실, 이것은 모든 시스템의 복사본과 수정에서 템플릿화되고 조합될 수 있는 가장 중요한 개체입니다. 이것은 아니다...

더 많이 나열할 수 있지만 내 메시지는 이미 분명합니다. 자신의 OOP를 조각하고 더 멋진 것을 발명할 수 있습니다. 아무도 진지하게 시도한 적이 없기 때문입니다. 그리고 표준 개념은 물리학이나 수학이 아닌 주관적인 시각이며 수정될 수 있습니다.))

[Andrei Trukhanovich]

상태라고 하는 디자인 패턴이 있습니다

관찰자 패턴이 있습니다

패턴 바이크가 있습니다. 피터가 좋아하는 패턴.

[Igor Makanu]

C# 및 Delphi에는 https://docs.microsoft.com/ru-ru/dotnet/csharp/programming-guide/classes-and-structs/properties 속성이 있습니다.

그리고 사건은 오랫동안 호기심이 아닙니다.

그러나 제 생각에는 단어에 대한 또 다른 주제, 꽤 좋은 노래 "Fairy"- YazheVika .... 당신은 가고, 나는 요정입니다! ....

[transcendreamer]

일반적으로 대상을 정의할 때 주제도 정의해야 합니다. 그렇지 않으면 세계에 대한 불완전한 설명입니다. 또한 현대 철학 개념에는 객체와 주체.

[Dmitry Fedoseev]

Peter, 항목이 다시 잘못된 쪽에 있습니다. 도구를 명시해야 하는 이유는 무엇입니까? 국가는 과거에도 그랬고 어디에도 사라지지 않았으며 다른 모든 것보다 훨씬 더 기본적입니다. 그리고 예 - 이벤트는 상태가 아니므로 설명되지 않지만 등록됩니다.

[Dmitry Fedoseev]

Реter Konow :

... 그리고 객체의 "공식적으로 등록된" 철학적 개념은 어디에 있습니까? 아아, 그러한 것은 오늘날까지 존재하지 않으며 존재할 수도 없습니다. ...

철학에 전혀 의존하지 않기 때문입니다. 프로그래밍에서 객체는 숭고하거나 신비롭거나 상상할 수 있는 것이 아닙니다. 함수와 변수의 결합일 뿐입니다.

[Vladimir]

Реter Konow :

이 주제는 글로벌 프로그래밍 문제에 관심이 있는 사람들에게 흥미로울 것입니다.

나는 " 왜 표준 OOP 개념에서 잘 알려진 객체 모델이 표준입니까? "라는 질문에 괴로워합니다.

두 개의 대문자 O가 먼저 오기 때문에 개념은 객체 지향이므로 개념의 주요 본질입니다. 절차적 프로그래밍의 개념에서와 마찬가지로 프로시저가 주요 본질이고 SQL에서 쿼리는 실행 방식을 무시하고 핵심입니다. 등등. 에센스가 아니라 캐논. 이 포럼에서는 다른 접근 방식에 반대하는 PLO의 정식화가 활발히 진행되고 있기 때문에 이러한 인상이 형성됩니다.

[Aleksey Nikolayev]

자체 제작 자전거를 발명하는 대신 기능 언어(예: Haskell)로 프로그래밍할 때 유형 이론 을 연구하고 응용 프로그램을 연습할 가치가 있습니다.

철학적이고 논리적인 기초를 이해하기 위해 Bertrand Russell을 읽을 수 있습니다.

[Koldun Zloy]

Реter Konow :

이 주제는 글로벌 프로그래밍 문제에 관심이 있는 사람들에게 흥미로울 것입니다.

ㅋ ㅋ ㅋ ㅋ ㅋ ㅋ.

이 모든 것은 OOP나 프로그래밍과 아무 관련이 없습니다.

더 나은 이름: "바늘 끝에 몇 개의 물건이 들어갈까요?"

[Реter Konow]

Vladimir :

두 개의 대문자 O가 먼저 오기 때문에 개념은 객체 지향이므로 개념의 주요 본질입니다. 절차적 프로그래밍의 개념에서와 마찬가지로 프로시저가 주요 본질이고 SQL에서 쿼리는 실행 방식을 무시하고 핵심입니다. 등등. 에센스가 아니라 캐논. 이 포럼에서는 다른 접근 방식에 반대하는 PLO의 정식화가 활발히 진행되고 있기 때문에 이러한 인상이 형성됩니다.

나는 결국 "객체에 대한 설명과 구성의 기준이 하나인 이유는 무엇인가?"라는 질문을 던졌습니다.

내 질문이 "OOP가 캐논인 이유"라고 결정하셨습니다.

프로그래밍 구조의 개체 지향, 작업 확장 및 구현. 그녀에 대한 질문은 없습니다. 그런데 왜 하나의 형식만 있습니까?

[Реter Konow]

Dmitry Fedoseev :

철학에 전혀 의존하지 않기 때문입니다. 프로그래밍에서 객체는 숭고하거나 신비롭거나 상상할 수 있는 어떤 것이 아닙니다. 함수와 변수의 결합일 뿐입니다.

여기서 철학적 개념 없이는 불가능합니다. 객체의 사려 깊은 "그림"을 따르지 않고 함수와 변수를 결합하기만 하면 됩니까? 클래스, 구조, 액세스 수정자 등의 특정 도구가 제공되지만 상태, 선택, 바인딩과 같은 다른 도구가 있을 수 있습니다. 왜 안 될까요? 제 요점은 OOP 형식과 툴킷이 버전을 가질 수 있다는 것입니다...

그리고 어떤 경우에는 다른 버전의 개체 설명 형식이 더 효율적일 수 있습니다.