Реter Konow : 여기서 철학적 개념 없이는 불가능합니다. 객체의 사려 깊은 "그림"을 따르지 않고 함수와 변수를 결합하기만 하면 됩니까? 클래스, 구조, 액세스 수정자 등의 특정 도구가 제공되지만 상태, 선택, 바인딩과 같은 다른 도구가 있을 수 있습니다. 왜 안 될까요? 제 요점은 OOP 형식과 툴킷이 버전을 가질 수 있다는 것입니다...
"최적의 충분성"이라는 것이 있습니다.
왜 인간은 두 개의 다리와 두 개의 팔을 가지고 있습니까? 개는 왜 다리가 5개일까요? 따라서 질문이 생깁니다. 왜 Frankenstein을 발명하고 있습니까? 그리고 영구적으로. 가려움? 그들이 그들의 흔적을 남기기 위해 발명하지 않았다면 그들은 오래전에 떠났을 것입니다. 즉, 잘못된 방향으로 노력하고 있습니다.
Реter Konow : 여기서 철학적 개념 없이는 불가능합니다. 객체의 사려 깊은 "그림"을 따르지 않고 함수와 변수를 결합하기만 하면 됩니까? 클래스, 구조, 액세스 수정자 등의 특정 도구가 제공되지만 상태, 선택, 바인딩과 같은 다른 도구가 있을 수 있습니다. 왜 안 될까요? 제 요점은 OOP 형식과 툴킷이 버전을 가질 수 있다는 것입니다...
왜 인간은 두 개의 다리와 두 개의 팔을 가지고 있습니까? 개는 왜 다리가 5개일까요? 따라서 질문이 생깁니다. 왜 Frankenstein을 발명하고 있습니까? 그리고 영구적으로. 가려움? 그들이 그들의 흔적을 남기기 위해 발명하지 않았다면 그들은 오래전에 떠났을 것입니다. 즉, 잘못된 방향으로 노력하고 있습니다.
객체 지향 프로그래밍(OOP)은 프로그램 을 객체의 컬렉션으로 표현하는 데 기반을 둔프로그래밍 방법론 입니다 . 각 객체는 특정클래스 의 인스턴스 이고 클래스는 상속 계층 구조를 형성합니다[1].
이것은 순수한 철학입니다. 그래서 프로그래밍에 철학이 없다고 믿는 사람들은 착각하는 것입니다. 객체 프로그래밍은 철학적 기반 위에 구축되므로 프로그래머는 추상적이고 철학적으로 생각할 수 있어야 합니다. 예를 들어, 나는 개념에 대해 철학적인 질문을 할 수 있습니다. 이것은 논리적이고 자연스러운 일입니다. 프랑켄슈타인은 없습니다. 나는 "지구가 평평하지 않다면?"
OOP는 이데올로기의 발전으로 생겨난 처리를 위한 데이터와 서브루틴(절차, 기능)이 공식적으로 관련되지 않는 절차적 프로그래밍 . 객체 지향 프로그래밍의 추가 개발을 위해 이벤트 개념(소위 이벤트 기반 프로그래밍 ) 및 구성 요소( 구성 요소 프로그래밍 , COP).
개체는 다음을 통해 상호 작용합니다. 메시지 . OOP의 추가 개발 결과는 분명히 다음과 같습니다. 에이전트 지향 프로그래밍 , 여기서 에이전트 는 실행 수준에서 독립적인 코드 조각입니다. 에이전트는 변경하여 상호 작용합니다. 그들이 있는 환경 .
구조적으로 객체와 직접적으로 관련되지는 않지만 객체의 안전( 예외적 상황 , 확인) 및 효율적인 작동을 위해 객체를 수반하는 언어 구성은 객체로부터 측면(inspect)으로 캡슐화됩니다. 측면 지향 프로그래밍 ). 객체 지향 프로그래밍 개체의 보다 통합되고 독립적인 상호 작용을 제공하여 개체의 개념을 확장합니다. 독립적인 상호 작용 측면에서 OOP와 에이전트 프로그래밍 사이의 전환 단계가 될 수 있습니다.
기본 개념이 제안된 최초의 프로그래밍 언어는 이후 패러다임으로 발전했습니다. Simula , 그러나 "객체 지향"이라는 용어는 해당 언어의 사용 맥락에서 사용되지 않았습니다. 에 출연했을 당시 1967년 사물, 계급, 가상 메서드 그리고 다른 사람들, 그러나 이 모든 것은 동시대인들에 의해 장엄한 것으로 인식되지 않았습니다. 사실 Simula는 "클래스가 있는 Algol"로 표현을 단순화했습니다. 절차적 프로그래밍 많은 복잡한 개념. Simula에서 클래스의 개념은 Algol 구조의 구성을 통해 완전히 정의될 수 있습니다(즉, Simula의 클래스는 프리미티브를 통해 설명되는 복잡한 것입니다).
"새로운 각도에서"(절차적 이외의) 프로그래밍에 대한 견해는 다음과 같이 제안되었습니다. 앨런 케이 그리고 댄 잉걸스 언어로 잡담 . 여기에서 클래스의 개념은 다른 모든 언어 구성에 대한 기본 아이디어가 되었습니다(즉, Smalltalk의 클래스는 더 복잡한 구성이 설명되는 기본 개념입니다). 처음으로 널리 퍼진 사람은 바로 그 사람이었습니다. 객체 지향 프로그래밍 언어 .
현재 객체지향 패러다임을 구현하는 응용 프로그래밍 언어(언어 목록 )는 다른 패러다임에 비해 가장 많다. 업계에서 가장 많이 사용되는 언어(C++, Delphi, C#, Java 등)는 Simula 객체 모델을 구현합니다. Smoltok 모델을 기반으로 하는 언어의 예로는 Objective-C, Python, Ruby가 있습니다.
OOP는 40년 이상의 역사를 가지고 있지만 그럼에도 불구하고 이 기술에 대해 일반적으로 인정되는 명확한 정의는 아직 없습니다[14]. 첫 번째 대상 언어 및 시스템에 명시된 기본 원칙은 많은 후속 구현과 함께 상당한 변경(또는 왜곡) 및 추가를 거쳤습니다. 또한, 1980년대 중반부터"객체 지향"이라는 용어가유행 하게 되었고, 결과적으로 조금 더 일찍 "구조적"이라는 용어( 구조화의 확산 이후 유행이 된)와 같은 일이 발생했습니다.프로그래밍 기술 ) - 매력적으로 만들기 위해 모든 새로운 개발에 인위적으로 "부착"되었습니다.Björn Stroustrup은1988년 에 무언가의 "객체 지향"에 대한 정당화가 대부분의 경우 잘못된 삼단논법으로 귀결된다고 썼습니다 . "X는 좋습니다. 객체 지향성이 좋습니다.따라서X는 객체 지향입니다."
따라서 프로그램은 상태와 동작을 가진 개체 집합입니다. 객체는 메시지를 통해 통신합니다. 개체의 계층 구조는 자연스럽게 구축됩니다. 프로그램 전체가 개체이며, 그 기능을 수행하기 위해 포함된 개체를 참조하고, 차례로 프로그램의 다른 개체를 참조하여 요청된 작업을 수행합니다. 당연히 호출에서 끝없는 재귀 를 피하기 위해 개체는 특정 단계에서 자신에게 지정된 메시지를 프로그래밍 언어 및 환경에서 제공하는 표준 시스템 개체에 대한 메시지로 변환합니다.
시스템의 안정성과 제어 가능성은 객체의 명확한 책임 분할(특정 객체는 각 작업에 대한 책임이 있음), 객체 간 상호 작용을 위한 인터페이스의 명확한 정의, 객체의 내부 구조를 다음과 완전히 분리함으로써 보장됩니다. 외부 환경(캡슐화).
객체 지향 프로그래밍(OOP)은 프로그램 을 객체의 컬렉션으로 표현하는 데 기반을 둔프로그래밍 방법론 입니다 . 각 객체는 특정클래스 의 인스턴스 이고 클래스는 상속 계층 구조를 형성합니다[1].
이것은 순수한 철학입니다. 그래서 프로그래밍에 철학이 없다고 믿는 사람들은 착각하는 것입니다. 객체 프로그래밍은 철학적 기반 위에 구축되므로 프로그래머는 추상적이고 철학적으로 생각할 수 있어야 합니다. 예를 들어, 나는 개념에 대해 철학적인 질문을 할 수 있습니다. 이것은 논리적이고 자연스러운 일입니다. 프랑켄슈타인은 없습니다. 나는 "지구가 평평하지 않으면 어떻게 될까?"라는 질문에 따라 움직입니다.
내 예측이 틀릴 수 있지만 개념이 계속 발전하면 조립에 훨씬 적은 노력이 필요한 새로운 개체 모델 이 나타날 것이므로 시스템이 더 빨리 성장할 것입니다. 이것은 프로그래밍 프로세스의 폐지와 기초가 된 많은 언어의 소멸로 이어질 것입니다. 이 미래는 논리적이기 때문에 가능성이 높습니다.
다음은 그러한 결론으로 이어지는 몇 가지 사항입니다.
1. 프로그래밍은 객체에서 주체(AI)로 진행됩니다.
2. AI를 작성하려면 프로그래밍 프로세스의 속도를 크게 높이고 인건비를 줄여야 합니다.
3. 새로운 기술과 새로운 객체 표현 덕분에 프로그래밍은 키보드를 넘어 훨씬 더 상호 작용할 수 있습니다.
진화가 계속된다면, 우리는 필연적으로 전체 직업과 전문화의 소멸을 포함한 글로벌 재분배를 견뎌야 할 것입니다. 그리고 새로운 것들의 등장.
여기서 철학적 개념 없이는 불가능합니다. 객체의 사려 깊은 "그림"을 따르지 않고 함수와 변수를 결합하기만 하면 됩니까? 클래스, 구조, 액세스 수정자 등의 특정 도구가 제공되지만 상태, 선택, 바인딩과 같은 다른 도구가 있을 수 있습니다. 왜 안 될까요? 제 요점은 OOP 형식과 툴킷이 버전을 가질 수 있다는 것입니다...
"최적의 충분성"이라는 것이 있습니다.
왜 인간은 두 개의 다리와 두 개의 팔을 가지고 있습니까? 개는 왜 다리가 5개일까요? 따라서 질문이 생깁니다. 왜 Frankenstein을 발명하고 있습니까? 그리고 영구적으로. 가려움? 그들이 그들의 흔적을 남기기 위해 발명하지 않았다면 그들은 오래전에 떠났을 것입니다. 즉, 잘못된 방향으로 노력하고 있습니다.
일반적으로 대상을 정의할 때 주제도 정의해야 합니다. 그렇지 않으면 세계에 대한 불완전한 설명입니다. 또한 현대 철학 개념에는 객체와 주체.
여기서 철학적 개념 없이는 불가능합니다. 객체의 사려 깊은 "그림"을 따르지 않고 함수와 변수를 결합하기만 하면 됩니까? 클래스, 구조, 액세스 수정자 등의 특정 도구가 제공되지만 상태, 선택, 바인딩과 같은 다른 도구가 있을 수 있습니다. 왜 안 될까요? 제 요점은 OOP 형식과 툴킷이 버전을 가질 수 있다는 것입니다...
OOP는 언어마다 기능이 다릅니다.
"최적의 충분성"이라는 것이 있습니다.
왜 인간은 두 개의 다리와 두 개의 팔을 가지고 있습니까? 개는 왜 다리가 5개일까요? 따라서 질문이 생깁니다. 왜 Frankenstein을 발명하고 있습니까? 그리고 영구적으로. 가려움? 그들이 그들의 흔적을 남기기 위해 발명하지 않았다면 그들은 오래전에 떠났을 것입니다. 즉, 잘못된 방향으로 노력하고 있습니다.
Wikipedia의 다음 정의가 정말 마음에 들었습니다.
객체 지향 프로그래밍(OOP) 은 프로그램 을 객체 의 컬렉션으로 표현하는 데 기반을 둔 프로그래밍 방법론 입니다 . 각 객체는 특정 클래스 의 인스턴스 이고 클래스는 상속 계층 구조를 형성합니다 [1] .
이것은 순수한 철학입니다. 그래서 프로그래밍에 철학이 없다고 믿는 사람들은 착각하는 것입니다. 객체 프로그래밍은 철학적 기반 위에 구축되므로 프로그래머는 추상적이고 철학적으로 생각할 수 있어야 합니다. 예를 들어, 나는 개념에 대해 철학적인 질문을 할 수 있습니다. 이것은 논리적이고 자연스러운 일입니다. 프랑켄슈타인은 없습니다. 나는 "지구가 평평하지 않다면?"
전체 기사는 다음과 같습니다.
https://ru.wikipedia.org/wiki/Object-oriented_programming
확고한 철학.
위키에서:
역사 [ 편집 ] | 코드 편집 ]
OOP는 이데올로기의 발전으로 생겨난 처리를 위한 데이터와 서브루틴(절차, 기능)이 공식적으로 관련되지 않는 절차적 프로그래밍 . 객체 지향 프로그래밍의 추가 개발을 위해 이벤트 개념(소위 이벤트 기반 프로그래밍 ) 및 구성 요소( 구성 요소 프로그래밍 , COP).
개체는 다음을 통해 상호 작용합니다. 메시지 . OOP의 추가 개발 결과는 분명히 다음과 같습니다. 에이전트 지향 프로그래밍 , 여기서 에이전트 는 실행 수준에서 독립적인 코드 조각입니다. 에이전트는 변경하여 상호 작용합니다. 그들이 있는 환경 .
구조적으로 객체와 직접적으로 관련되지는 않지만 객체의 안전( 예외적 상황 , 확인) 및 효율적인 작동을 위해 객체를 수반하는 언어 구성은 객체로부터 측면(inspect)으로 캡슐화됩니다. 측면 지향 프로그래밍 ). 객체 지향 프로그래밍 개체의 보다 통합되고 독립적인 상호 작용을 제공하여 개체의 개념을 확장합니다. 독립적인 상호 작용 측면에서 OOP와 에이전트 프로그래밍 사이의 전환 단계가 될 수 있습니다.
기본 개념이 제안된 최초의 프로그래밍 언어는 이후 패러다임으로 발전했습니다. Simula , 그러나 "객체 지향"이라는 용어는 해당 언어의 사용 맥락에서 사용되지 않았습니다. 에 출연했을 당시 1967년 사물, 계급, 가상 메서드 그리고 다른 사람들, 그러나 이 모든 것은 동시대인들에 의해 장엄한 것으로 인식되지 않았습니다. 사실 Simula는 "클래스가 있는 Algol"로 표현을 단순화했습니다. 절차적 프로그래밍 많은 복잡한 개념. Simula에서 클래스의 개념은 Algol 구조의 구성을 통해 완전히 정의될 수 있습니다(즉, Simula의 클래스는 프리미티브를 통해 설명되는 복잡한 것입니다).
"새로운 각도에서"(절차적 이외의) 프로그래밍에 대한 견해는 다음과 같이 제안되었습니다. 앨런 케이 그리고 댄 잉걸스 언어로 잡담 . 여기에서 클래스의 개념은 다른 모든 언어 구성에 대한 기본 아이디어가 되었습니다(즉, Smalltalk의 클래스는 더 복잡한 구성이 설명되는 기본 개념입니다). 처음으로 널리 퍼진 사람은 바로 그 사람이었습니다. 객체 지향 프로그래밍 언어 .
현재 객체지향 패러다임을 구현하는 응용 프로그래밍 언어(언어 목록 )는 다른 패러다임에 비해 가장 많다. 업계에서 가장 많이 사용되는 언어(C++, Delphi, C#, Java 등)는 Simula 객체 모델을 구현합니다. Smoltok 모델을 기반으로 하는 언어의 예로는 Objective-C, Python, Ruby가 있습니다.
Wikipedia 기사에서 위의 발췌문은 OOP의 아이디어가 어떻게 발전했는지 알려줍니다. 처음에는 개념이 그냥 앉아서 생각해 낸 사람이라고 생각했습니다. 내가 틀렸어. 그것은 진화의 과정이었다.
아마도 개념은 계속 발전할 것입니다. 왜 안 돼?
개념의 주관성을 확인하는 Wiki의 또 다른 발췌문:
OOP는 40년 이상의 역사를 가지고 있지만 그럼에도 불구하고 이 기술에 대해 일반적으로 인정되는 명확한 정의는 아직 없습니다 [14] . 첫 번째 대상 언어 및 시스템에 명시된 기본 원칙은 많은 후속 구현과 함께 상당한 변경(또는 왜곡) 및 추가를 거쳤습니다. 또한, 1980년대 중반부터 " 객체 지향"이라는 용어가 유행 하게 되었고, 결과적으로 조금 더 일찍 "구조적"이라는 용어( 구조화 의 확산 이후 유행이 된)와 같은 일이 발생했습니다. 프로그래밍 기술 ) - 매력적으로 만들기 위해 모든 새로운 개발에 인위적으로 "부착"되었습니다. Björn Stroustrup 은 1988년 에 무언가의 "객체 지향"에 대한 정당화가 대부분의 경우 잘못된 삼단논법 으로 귀결된다고 썼습니다 . "X는 좋습니다. 객체 지향성이 좋습니다. 따라서 X는 객체 지향입니다."
따라서 프로그램은 상태와 동작을 가진 개체 집합입니다. 객체는 메시지를 통해 통신합니다. 개체의 계층 구조는 자연스럽게 구축됩니다. 프로그램 전체가 개체이며, 그 기능을 수행하기 위해 포함된 개체를 참조하고, 차례로 프로그램의 다른 개체를 참조하여 요청된 작업을 수행합니다. 당연히 호출에서 끝없는 재귀 를 피하기 위해 개체는 특정 단계에서 자신에게 지정된 메시지를 프로그래밍 언어 및 환경에서 제공하는 표준 시스템 개체에 대한 메시지로 변환합니다.
시스템의 안정성과 제어 가능성은 객체의 명확한 책임 분할(특정 객체는 각 작업에 대한 책임이 있음), 객체 간 상호 작용을 위한 인터페이스의 명확한 정의, 객체의 내부 구조를 다음과 완전히 분리함으로써 보장됩니다. 외부 환경(캡슐화).
OOP는 다른 많은 방법으로 정의될 수 있습니다.
//------------------------------------------------ ----------------------
견적 끝.
Wikipedia의 다음 정의가 정말 마음에 들었습니다.
객체 지향 프로그래밍(OOP) 은 프로그램 을 객체 의 컬렉션으로 표현하는 데 기반을 둔 프로그래밍 방법론 입니다 . 각 객체는 특정 클래스 의 인스턴스 이고 클래스는 상속 계층 구조를 형성합니다 [1] .
이것은 순수한 철학입니다. 그래서 프로그래밍에 철학이 없다고 믿는 사람들은 착각하는 것입니다. 객체 프로그래밍은 철학적 기반 위에 구축되므로 프로그래머는 추상적이고 철학적으로 생각할 수 있어야 합니다. 예를 들어, 나는 개념에 대해 철학적인 질문을 할 수 있습니다. 이것은 논리적이고 자연스러운 일입니다. 프랑켄슈타인은 없습니다. 나는 "지구가 평평하지 않으면 어떻게 될까?"라는 질문에 따라 움직입니다.
전체 기사는 다음과 같습니다.
https://ru.wikipedia.org/wiki/Object-oriented_programming
확고한 철학.
이것은 결코 철학이 아닙니다. 이것들은 차량 (자동차)을 운전하는 원리이며 톱니 바퀴, 혀, 기어 세트가 더 복잡한 구조를 형성하는 등이 계층 구조의 주요 구조 인 스티어링 사이의 개스킷 바퀴와 좌석
자동차 운전과 프로그래밍이 다르다고 생각하는 사람들이 과감하게 숲속을 헤쳐나갈 수 있도록
개념과 용어를 계속 다루기 위해 동일한 Wiki의 체계화 및/ 또는 분류 개념에 익숙해진 다음 Wiki 기사에서 제안된 링크를 따라가는 것이 좋습니다.
내 예측이 틀릴 수 있지만 개념이 계속 발전하면 조립에 훨씬 적은 노력이 필요한 새로운 개체 모델 이 나타날 것이므로 시스템이 더 빨리 성장할 것입니다. 이것은 프로그래밍 프로세스의 폐지와 기초가 된 많은 언어의 소멸로 이어질 것입니다. 이 미래는 논리적이기 때문에 가능성이 높습니다.
다음은 그러한 결론으로 이어지는 몇 가지 사항입니다.
1. 프로그래밍은 객체에서 주체(AI)로 진행됩니다.
2. AI를 작성하려면 프로그래밍 프로세스의 속도를 크게 높이고 인건비를 줄여야 합니다.
3. 새로운 기술과 새로운 객체 표현 덕분에 프로그래밍은 키보드를 넘어 훨씬 더 상호 작용할 수 있습니다.
진화가 계속된다면, 우리는 필연적으로 전체 직업과 전문화의 소멸을 포함한 글로벌 재분배를 견뎌야 할 것입니다. 그리고 새로운 것들의 등장.