그러나 더 깊이 갈 수 있습니다. 단세포 / 다세포가 있으며 이것이 모두 살아있는 것입니다. 그러나 무생물도 있습니다. 이는 모두 기본 개체의 속성을 찾고 이미 상속해야 하는 작업에 따라 다릅니다.
만약 당신이 정말로 머리를 부딪친다면, 당신은 원자에 도달할 수 있고 기본적인 부모 개체를 찾기 위해 원자를 시작하고 구성요소로 나눌 수 있습니다(주의 깊게 - 핵분열 반응은 연쇄 반응이 될 수 있고, 당신은 세계의 절반을 파괴할 것입니다 :))
권리. 언뜻 보기에 OOP의 개념은 계층 구조를 구축하는 데 이상적입니다. 그러나 OOP를 통해 구성된 계층 구조로 작업하는 방법은 무엇입니까? 이것은 클래스 및 해당 콘텐츠에 대한 액세스 권한으로 인한 링크 간 전환으로 인한 구문과 복잡성의 바다입니다. 클래스로 나눈 결과로 오버헤드가 시작됩니다. 한편으로 OOP를 사용하면 계층 구조를 구축할 수 있지만 다른 한편으로는 OOP로 작업하기가 매우 어렵습니다.
Реter Konow : 권리. 언뜻 보기에 OOP의 개념은 계층 구조를 구축하는 데 이상적입니다. 그러나 OOP를 통해 구성된 계층 구조로 작업하는 방법은 무엇입니까? 이것은 클래스 및 해당 콘텐츠에 대한 액세스 권한으로 인한 링크 간 전환으로 인한 구문과 복잡성의 바다입니다. 여기에서 클래스 분할의 결과로 오버헤드가 시작됩니다. 한편으로 OOP를 사용하면 계층 구조를 구축할 수 있지만 다른 한편으로는 OOP로 작업하기가 매우 어렵습니다.
음 ... 아니. Just OOP는 모든 위치에 있는 계층 구조의 모든 구성원에 대한 매우 간단한 액세스를 제공합니다.
먼저 최소한의 필수 속성이 있는 기본 개체를 찾습니다.
다른 개체는 여기에서 상속합니다. 바퀴를 재발명하지 않으려면 기본 개체가 표준 라이브러리의 CObject 클래스 에서 상속되어야 합니다. 이렇게 하면 목록의 발명으로 인해 주의가 분산되지 않고 개체의 고유한 계층 구조를 만들 수 있습니다.
CObject --> CBaseObject --> 필요한 계층.
CBaseObject에는 이 개체를 반환하는 가상 메서드가 있어야 합니다. 그런 다음 각 상속인은 각각 이 메서드를 가지며 정확히 자식 개체를 반환합니다. 기본 클래스 CObject에는 이미 Type() 과 같은 메서드가 있습니다. 따라서 CBaseObject에 동일한 가상 메서드가 있고 객체의 유형을 반환하는 경우 이 유형으로 어떤 객체에 액세스했는지 알 수 있습니다.
그것은 모든 개체의 기본 기초와 같습니다. 그리고 그것들은 모두 자신의 목록에 저장되어야 합니다. 각 목록에는 물고기, 동물, 사람, 신 등 한 가지 유형의 개체만 포함됩니다.
즉, 각 하위 유형에 대한 목록이 있어야 합니다. 그리고 계층 구조에서 다음 목록이 배치될 하나의 목록이 있어야 합니다. 이러한 각 목록에는 계층 구조의 다음 목록도 있어야 합니다. 등.
즉, 필요한 목록을 배치할 기본 목록의 개체도 필요합니다. 그리고 이 기본 목록에는 Type() 메서드가 있어야 하며 인덱스로 저장된 개체를 반환할 수 있는 메서드가 있어야 합니다. 그런 다음 이것이 완료되면 목록에 필요한 개체를 반환하는 메서드가 자동으로 생성됩니다.
일반적으로 기초 개체를 먼저 생각한 다음 목록 개체를 생각합니다. 목록 개체를 만들 필요도 없습니다. 이미 존재합니다 .
그리고 나서 - 기술의 문제입니다. 그리고 찾고자 하는 개체의 유형만 알면 됩니다. 계층 구조에는 많은 유형이 있으며 각각은 사용자가 알고 있으며 요청하고 수신할 수 있습니다.
Peter에는 어떤 키로 올바른 것을 찾기 위해 배열의 모든 객체가 열거되어 있습니다. 그리고 클래스를 사용하는 것과 배열을 사용하는 것, 선언된 객체를 많이 사용하는 것에는 차이가 없습니다.
OOP를 사용하면 개체 목록을 가질 수 있으며, 각 개체 에는 GetColor() 메서드가 있으며 사용자는 같은 방식으로 원하는 색상을 찾기 위해 모든 개체를 반복합니다. 그러나 OOP가 없는 경우 - 필요한 위치에서 색상을 얻기 위해 사용자가 알아야 하는 동일한 구조의 배열이 있는 경우 OOP를 사용하는 경우 - 사용자는 색상이 정확히 어떻게 그리고 어디에 있는지 알 필요가 없습니다. stored - 객체 자체의 GetColor() 메서드는 색상을 가져올 위치를 알고 있습니다.
즉, OOP의 경우 사용자는 개체의 색상이 저장되는 방법과 위치를 알 필요가 없습니다. 따라서 색상이 점으로 인코딩된 "맹인을 위한 개체"를 갑자기 추가해야 하는 경우 어려움 없이 이 개체를 목록에 추가하고 GetColor() 메서드만 변경합니다. 점에서 "점자"가 색상 코드를 얻고 정상적인 방법으로 반환합니다. 목록 사용자의 경우 - 아무 것도 변경되지 않습니다.
OOP의 이점은 CObject에서 상속한 다음 CArrayObj 개체의 배열을 만든 다음 비교 함수만 작성하고 즉시 빠르게 정렬하고 이진 검색할 수 있는 기능을 사용할 때 분명히 볼 수 있습니다.
대략적으로 말하면, 위의 예에서 색상을 사용하여 - OOP의 경우 - GetColor()를 통해 색상을 가져오는 비교 함수를 작성하고, 객체의 절반이 실제 색상을 가지고 있다는 사실조차 모른 채 색상별로 객체를 정렬할 수 있습니다. 그리고 반 - "점자 점". 그리고 우리가 새로운 색상 코딩을 가진 객체를 추가하고 싶다면 - 다시, 우리는 색상 표현을 표준으로 가져오는 GetColor() 함수만 작성하면 됩니다 - 그 후에는 이미 작성된 정렬 및 검색 알고리즘 이 승인합니다 아무 문제 없이 이 새로운 개체.
즉, 실제로 OOP를 사용하면 색상이 정확히 어떻게 표현되고 어떻게 저장되는지 결정하기 전에 아직 작성되지 않은 개체를 정렬하고 검색하는 알고리즘을 사용할 수 있었습니다.
Реter Konow : 이것은 클래스 및 해당 콘텐츠에 대한 액세스 권한으로 인한 링크 간 전환으로 인한 구문과 복잡성의 바다입니다. 클래스로 나눈 결과로 오버헤드가 시작됩니다. 한편으로 OOP를 사용하면 계층 구조를 구축할 수 있지만 다른 한편으로는 OOP로 작업하기가 매우 어렵습니다.
액세스 수정자를 사용하면 컴파일 시간에 오류를 감지할 수 있습니다.
일반적으로이 모든 것이 클래스 작업을 어렵게 만들지 않고 사용하지 말고 모든 것을 공개적으로 작성하십시오. , 그러면 더 쉽게 알아낼 수 있습니다.
추신: OOP에 대한 많은 아름다운 문구, 캡슐화, 상속 ... 다 좋지만 다른 프로그래밍 스타일에 비해 OOP의 가장 중요한 장점은 모든 데이터(클래스 필드) 및 이 데이터 작업을 위한 함수의 저장입니다. (클래스 메소드) 한 곳에서 (클래스) - 책에 따르면 이것은 캡슐화입니다. 또한 OOP의 사용은 작업에 따라 다릅니다. 작업에서 클래스를 확장할 수 있는 경우 계층 구조가 필요하고 기본 클래스와 상속인이 있습니다. 사용 여부는 사용자에 따라 다릅니다.
나는 OOP의 개념에서 "객체"가 내 "핵심"보다 더 넓은 맥락에서 제시된다는 것을 인정해야 합니다. 그러나 지금까지 그래픽만 다루었고 OOP는 광범위한 문제를 해결하는 데 사용되기 때문에 이것은 놀라운 일이 아닙니다. 내 개체 "메뉴"는 매우 빈약하며 "레이블", "요소", "창"을 제외하고는 다른 것이 거의 없을 것입니다. 하지만 그래픽 인터페이스의 경우 더 이상 필요하지 않습니다.
그러나 이제 "오브젝트"의 개념을 확장하고 계층 구조를 구축하는 문제가 발생했습니다. 단순한 2차원 코어는 다양한 지식 기반 개체를 모두 수용할 수 없으므로 다른 개체에 대해 서로 다른 코어를 생성하거나 OOP 개념의 경로를 따라야 합니다.
본질적으로 이것은 순전히 기술적인 문제입니다. 더 효율적인 것, 더 빠른 것, 더 읽기 쉬운 것 등...
실제로 모든 개체는 속성 목록으로 배열에 보관할 수 있으며 그 중에는 다른 배열, 다른 개체 등에 대한 포인터가 있습니다. 또는 명시적으로 OOP를 사용 합니다. 객체 지향은 항상 두 접근 방식 모두에 존재하며 구현 방법만 다릅니다. 같은 메모리, 같은 포인터, 같은 객체, 같은 분류. 코드만 다를뿐...
생물.
동식물
아종
보다
가족
등.
그래서 당신이 원하는?
글쎄, 이것은 기본 개체 "Creature"에서 간단한 상속입니다.
그러나 더 깊이 갈 수 있습니다. 단세포 / 다세포가 있으며 이것이 모두 살아있는 것입니다. 그러나 무생물도 있습니다. 이는 모두 기본 개체의 속성을 찾고 이미 상속해야 하는 작업에 따라 다릅니다.
만약 당신이 정말로 머리를 부딪친다면, 당신은 원자에 도달할 수 있고 기본적인 부모 개체를 찾기 위해 원자를 시작하고 구성요소로 나눌 수 있습니다(주의 깊게 - 핵분열 반응은 연쇄 반응이 될 수 있고, 당신은 세계의 절반을 파괴할 것입니다 :))
권리. 언뜻 보기에 OOP의 개념은 계층 구조를 구축하는 데 이상적입니다. 그러나 OOP를 통해 구성된 계층 구조로 작업하는 방법은 무엇입니까? 이것은 클래스 및 해당 콘텐츠에 대한 액세스 권한으로 인한 링크 간 전환으로 인한 구문과 복잡성의 바다입니다. 여기에서 클래스 분할의 결과로 오버헤드가 시작됩니다. 한편으로 OOP를 사용하면 계층 구조를 구축할 수 있지만 다른 한편으로는 OOP로 작업하기가 매우 어렵습니다.
음 ... 아니. Just OOP는 모든 위치에 있는 계층 구조의 모든 구성원에 대한 매우 간단한 액세스를 제공합니다.
먼저 최소한의 필수 속성이 있는 기본 개체를 찾습니다.
다른 개체는 여기에서 상속합니다. 바퀴를 재발명하지 않으려면 기본 개체가 표준 라이브러리의 CObject 클래스 에서 상속되어야 합니다. 이렇게 하면 목록의 발명으로 인해 주의가 분산되지 않고 개체의 고유한 계층 구조를 만들 수 있습니다.
CObject --> CBaseObject --> 필요한 계층.
CBaseObject에는 이 개체를 반환하는 가상 메서드가 있어야 합니다. 그런 다음 각 상속인은 각각 이 메서드를 가지며 정확히 자식 개체를 반환합니다. 기본 클래스 CObject에는 이미 Type() 과 같은 메서드가 있습니다. 따라서 CBaseObject에 동일한 가상 메서드가 있고 객체의 유형을 반환하는 경우 이 유형으로 어떤 객체에 액세스했는지 알 수 있습니다.
그것은 모든 개체의 기본 기초와 같습니다. 그리고 그것들은 모두 자신의 목록에 저장되어야 합니다. 각 목록에는 물고기, 동물, 사람, 신 등 한 가지 유형의 개체만 포함됩니다.
즉, 각 하위 유형에 대한 목록이 있어야 합니다. 그리고 계층 구조에서 다음 목록이 배치될 하나의 목록이 있어야 합니다. 이러한 각 목록에는 계층 구조의 다음 목록도 있어야 합니다. 등.
즉, 필요한 목록을 배치할 기본 목록의 개체도 필요합니다. 그리고 이 기본 목록에는 Type() 메서드가 있어야 하며 인덱스로 저장된 개체를 반환할 수 있는 메서드가 있어야 합니다. 그런 다음 이것이 완료되면 목록에 필요한 개체를 반환하는 메서드가 자동으로 생성됩니다.
일반적으로 기초 개체를 먼저 생각한 다음 목록 개체를 생각합니다. 목록 개체를 만들 필요도 없습니다. 이미 존재합니다 .
그리고 나서 - 기술의 문제입니다. 그리고 찾고자 하는 개체의 유형만 알면 됩니다. 계층 구조에는 많은 유형이 있으며 각각은 사용자가 알고 있으며 요청하고 수신할 수 있습니다.
내가 보기에 - 이 경우 OOP는 그것과 아무 관련이 없습니다.
Peter에는 어떤 키로 올바른 것을 찾기 위해 배열의 모든 객체가 열거되어 있습니다. 그리고 클래스를 사용하는 것과 배열을 사용하는 것, 선언된 객체를 많이 사용하는 것에는 차이가 없습니다.
OOP를 사용하면 개체 목록을 가질 수 있으며, 각 개체 에는 GetColor() 메서드가 있으며 사용자는 같은 방식으로 원하는 색상을 찾기 위해 모든 개체를 반복합니다. 그러나 OOP가 없는 경우 - 필요한 위치에서 색상을 얻기 위해 사용자가 알아야 하는 동일한 구조의 배열이 있는 경우 OOP를 사용하는 경우 - 사용자는 색상이 정확히 어떻게 그리고 어디에 있는지 알 필요가 없습니다. stored - 객체 자체의 GetColor() 메서드는 색상을 가져올 위치를 알고 있습니다.
즉, OOP의 경우 사용자는 개체의 색상이 저장되는 방법과 위치를 알 필요가 없습니다. 따라서 색상이 점으로 인코딩된 "맹인을 위한 개체"를 갑자기 추가해야 하는 경우 어려움 없이 이 개체를 목록에 추가하고 GetColor() 메서드만 변경합니다. 점에서 "점자"가 색상 코드를 얻고 정상적인 방법으로 반환합니다. 목록 사용자의 경우 - 아무 것도 변경되지 않습니다.
배열만 있으면 거기에 "점자 점"을 넣을 수 없습니다. 우리는 그런 분야가 없습니다.
OOP의 이점은 CObject에서 상속한 다음 CArrayObj 개체의 배열을 만든 다음 비교 함수만 작성하고 즉시 빠르게 정렬하고 이진 검색할 수 있는 기능을 사용할 때 분명히 볼 수 있습니다.
대략적으로 말하면, 위의 예에서 색상을 사용하여 - OOP의 경우 - GetColor()를 통해 색상을 가져오는 비교 함수를 작성하고, 객체의 절반이 실제 색상을 가지고 있다는 사실조차 모른 채 색상별로 객체를 정렬할 수 있습니다. 그리고 반 - "점자 점". 그리고 우리가 새로운 색상 코딩을 가진 객체를 추가하고 싶다면 - 다시, 우리는 색상 표현을 표준으로 가져오는 GetColor() 함수만 작성하면 됩니다 - 그 후에는 이미 작성된 정렬 및 검색 알고리즘 이 승인합니다 아무 문제 없이 이 새로운 개체.
즉, 실제로 OOP를 사용하면 색상이 정확히 어떻게 표현되고 어떻게 저장되는지 결정하기 전에 아직 작성되지 않은 개체를 정렬하고 검색하는 알고리즘을 사용할 수 있었습니다.
OOP의 이점은 CObject에서 상속한 다음 CArrayObj 개체의 배열을 만든 다음 비교 함수만 작성하고 즉시 빠르게 정렬하고 이진 검색할 수 있는 기능을 사용할 때 명확하게 볼 수 있습니다.
이것은 클래스 및 해당 콘텐츠에 대한 액세스 권한으로 인한 링크 간 전환으로 인한 구문과 복잡성의 바다입니다. 클래스로 나눈 결과로 오버헤드가 시작됩니다. 한편으로 OOP를 사용하면 계층 구조를 구축할 수 있지만 다른 한편으로는 OOP로 작업하기가 매우 어렵습니다.
액세스 수정자를 사용하면 컴파일 시간에 오류를 감지할 수 있습니다.
일반적으로이 모든 것이 클래스 작업을 어렵게 만들지 않고 사용하지 말고 모든 것을 공개적으로 작성하십시오. , 그러면 더 쉽게 알아낼 수 있습니다.
추신: OOP에 대한 많은 아름다운 문구, 캡슐화, 상속 ... 다 좋지만 다른 프로그래밍 스타일에 비해 OOP의 가장 중요한 장점은 모든 데이터(클래스 필드) 및 이 데이터 작업을 위한 함수의 저장입니다. (클래스 메소드) 한 곳에서 (클래스) - 책에 따르면 이것은 캡슐화입니다. 또한 OOP의 사용은 작업에 따라 다릅니다. 작업에서 클래스를 확장할 수 있는 경우 계층 구조가 필요하고 기본 클래스와 상속인이 있습니다. 사용 여부는 사용자에 따라 다릅니다.
나는 OOP의 개념에서 "객체"가 내 "핵심"보다 더 넓은 맥락에서 제시된다는 것을 인정해야 합니다. 그러나 지금까지 그래픽만 다루었고 OOP는 광범위한 문제를 해결하는 데 사용되기 때문에 이것은 놀라운 일이 아닙니다. 내 개체 "메뉴"는 매우 빈약하며 "레이블", "요소", "창"을 제외하고는 다른 것이 거의 없을 것입니다. 하지만 그래픽 인터페이스의 경우 더 이상 필요하지 않습니다.
그러나 이제 "오브젝트"의 개념을 확장하고 계층 구조를 구축하는 문제가 발생했습니다. 단순한 2차원 코어는 다양한 지식 기반 개체를 모두 수용할 수 없으므로 다른 개체에 대해 서로 다른 코어를 생성하거나 OOP 개념의 경로를 따라야 합니다.
본질적으로 이것은 순전히 기술적인 문제입니다. 더 효율적인 것, 더 빠른 것, 더 읽기 쉬운 것 등...
실제로 모든 개체는 속성 목록으로 배열에 보관할 수 있으며 그 중에는 다른 배열, 다른 개체 등에 대한 포인터가 있습니다. 또는 명시적으로 OOP를 사용 합니다. 객체 지향은 항상 두 접근 방식 모두에 존재하며 구현 방법만 다릅니다. 같은 메모리, 같은 포인터, 같은 객체, 같은 분류. 코드만 다를뿐...
나는 Peter가 그에게 제안한 데이터 스토리지의 개념을 이해했을 때 이에 대해 말하고 싶었습니다.
나는 데이터를 저장하고 작업하는 이 개념을 이해하려고 노력할 것입니다.
좋은. 개인적인 대화를 나눌 수 있습니다. 또는 Skype를 선택하십시오. 이 주제의 주제에 관한 것이 아니라 여기에서 내가 이해하는 바에 따라 일반적인 질문만 하겠습니다.