버킷에 무엇이든, 특히 특정 객체와 관련된 것을 기록해야 하는 이유는 무엇입니까? 객체 자체에는 자신에 대한 정보가 저장되지만 버킷에는 객체에 대한 포인터만 포함됩니다.
표준 OOP에 개체의 큰 "캡슐"(클래스)이 있는 이유를 생각해 본 적이 있습니까? 결국, 객체를 포인터 노드로 바꾸고 객체의 내용을 클래스 외부에 저장하는 것이 더 쉽습니다. 그러면 객체를 모델링하기 쉽습니다. 결합해야 하는 재료에 대한 포인터를 변경하기만 하면 개체가 다른 것으로 "전환"됩니다. 개체의 내용은 클래스(캡슐)의 "성분"이 아니라 포인터에 따라 달라집니다. 따라서 Object 형태로 Core에 저장하는 것은 바로 그러한 번들입니다. 그리고 재료 자체는 코어 외부에 있습니다. 따라서 객체 간의 링크와 해당 콘텐츠는 쉽고 빠르게 변경할 수 있으며 이러한 "노달" 객체로 구성된 시스템은 쉽게 수정할 수 있습니다.
글쎄요, 하지만 접근 방식에 이름이 있습니까? 어쩌면 IOOP - 핵 객체 지향 프로그래밍. 무기, 원자력 발전소와 관련하여 견고하게 들립니다. "나는 최선을 다해 핵심에 담았다!"라는 일종의 슬로건을 생각해 낼 수 있습니다. 좋아, 피터, 계속 해봐, 난 기분 좋게 놀랐어.
Реter Konow : 표준 OOP에 개체의 큰 "캡슐"(클래스)이 있는 이유를 생각해 본 적이 있습니까? 결국, 객체를 포인터 노드로 바꾸고 객체의 내용을 클래스 외부에 저장하는 것이 더 쉽습니다. 그러면 객체를 모델링하기 쉽습니다. 결합해야 하는 재료에 대한 포인터를 변경하기만 하면 개체가 다른 것으로 "전환"됩니다. 개체의 내용은 클래스(캡슐)의 "성분"이 아니라 포인터에 따라 달라집니다. 따라서 Object 형태로 Core에 저장하는 것은 바로 그러한 번들입니다. 그리고 재료 자체는 코어 외부에 있습니다. 따라서 객체 간의 링크와 해당 콘텐츠는 쉽고 빠르게 변경할 수 있으며 이러한 "노달" 객체로 구성된 시스템은 쉽게 수정할 수 있습니다.
Vict : 글쎄요, 하지만 접근 방식에 이름이 있습니까? 어쩌면 IOOP - 핵 객체 지향 프로그래밍. 무기, 원자력 발전소와 관련하여 견고하게 들립니다. "나는 최선을 다해 핵심에 담았다!"라는 일종의 슬로건을 생각해 낼 수 있습니다. 좋아, 피터, 계속 해봐, 난 기분 좋게 놀랐어.
두뇌 내부를 살펴보십시오. 그것은 연결 센터(뉴런)로 채워져 있으며 별도의 닫힌 복합체가 아닙니다. 뇌는 각 개체의 전체 내용이 아니라 연결을 캡슐화합니다.
이러한 관계를 "객체 구성/집계"라고 하지만 지속적으로 커널로 되돌아갑니다. 원하는대로 링크를 추가하십시오. 여기에는 새로운 것이 없습니다.
추신: 나는 비디오를 대각선으로 보았지만 그다지 많지는 않았을 것입니다.
https://habr.com/en/post/354046/
훨씬 더 명확합니다.
//----------------------------------------
컴포지션은 공통 연관 체인에 있는 개체를 연결합니다. 방-벽-가구. 문제는 연관 체인이 너무 불안정하고 불확실하다는 것입니다. 이는 클래스 수준의 링크가 실수임을 의미합니다. 방은 어린이, 새장, 하이퍼큐브 또는 지하세계와 연관될 수 있으며 이에 따라 콘텐츠가 배치될 수 있습니다. 표준 OOP 클래스는 컴포지션 내에서 링크를 쉽게 변경할 수 없지만 핵심은 제공합니다.
Нередко случается, что решив разобраться с какой-то новой темой, понятием, инструментом программирования, я читаю одну за другой статьи на различных сайтах в интернете. И, если тема сложная, то эти статьи могут не на шаг не приблизить меня к понимаю. И вдруг встречается статья, которая моментально дает озарение и все паззлы складываются...
Все объекты, используемые в техническом анализе, имеют привязку на графиках по координатам цены и времени – трендовая линия, каналы, инструменты Фибоначчи и т.д. Но есть ряд вспомогательных объектов, предназначенных для улучшения интерфейса, которые имеют привязку к видимой всегда части графика (основное окно графика или подокна индикаторов...
" OOP의 새로운 개념 " - 목표가 명확하지 않습니다. 왜 이런 짓을하는?
나는 내가 평생 동안 관심을 가지고 있었던 몇 가지를 이해하고 싶습니다.
1. 자체 개발 시스템을 만드는 것이 가능한가요?
2. 많은 시스템이 상호 작용하고 변화하고 발전하는 프로세스를 만드는 것이 가능합니까?
3. 처음에 정해진 개념 없이 어떤 것이 일어날 수 있습니까?
4. 상속 및 개체 캡슐화와 함께 코어 및 표준 OOP의 개체 표현을 교차하면 어떻게 됩니까? 복잡한 시스템의 생성을 단순화할 수 있습니까?
... 버킷의 인스턴스에 대해 작업합니다. :)
버킷에 무엇이든, 특히 특정 객체와 관련된 것을 기록해야 하는 이유는 무엇입니까? 객체 자체에는 자신에 대한 정보가 저장되지만 버킷에는 객체에 대한 포인터만 포함됩니다.
표준 OOP에 개체의 큰 "캡슐"(클래스)이 있는 이유를 생각해 본 적이 있습니까? 결국, 객체를 포인터 노드로 바꾸고 객체의 내용을 클래스 외부에 저장하는 것이 더 쉽습니다. 그러면 객체를 모델링하기 쉽습니다. 결합해야 하는 재료에 대한 포인터를 변경하기만 하면 개체가 다른 것으로 "전환"됩니다. 개체의 내용은 클래스(캡슐)의 "성분"이 아니라 포인터에 따라 달라집니다. 따라서 Object 형태로 Core에 저장하는 것은 바로 그러한 번들입니다. 그리고 재료 자체는 코어 외부에 있습니다. 따라서 객체 간의 링크와 해당 콘텐츠는 쉽고 빠르게 변경할 수 있으며 이러한 "노달" 객체로 구성된 시스템은 쉽게 수정할 수 있습니다.
.
글쎄요, 하지만 접근 방식에 이름이 있습니까? 어쩌면 IOOP - 핵 객체 지향 프로그래밍. 무기, 원자력 발전소와 관련하여 견고하게 들립니다. "나는 최선을 다해 핵심에 담았다!"라는 일종의 슬로건을 생각해 낼 수 있습니다. 좋아, 피터, 계속 해봐, 난 기분 좋게 놀랐어.
두뇌 내부를 살펴보십시오. 그것은 연결 센터(뉴런)로 채워져 있으며 별도의 닫힌 복합체가 아닙니다. 뇌는 각 개체의 전체 내용이 아니라 연결을 캡슐화합니다.
이러한 관계를 "객체 구성/집계"라고 하지만 지속적으로 커널로 되돌아갑니다. 원하는대로 링크를 추가하십시오. 여기에는 새로운 것이 없습니다.
추신: 나는 비디오를 대각선으로 보았지만 그다지 많지는 않았을 것입니다.이러한 관계를 "객체 구성/집계"라고 하지만 지속적으로 커널로 되돌아갑니다. 원하는대로 링크를 추가하십시오. 여기에는 새로운 것이 없습니다.
추신: 나는 비디오를 대각선으로 보았지만 그다지 많지는 않았을 것입니다.https://habr.com/en/post/354046/
훨씬 더 명확합니다.
//----------------------------------------
컴포지션은 공통 연관 체인에 있는 개체를 연결합니다. 방-벽-가구. 문제는 연관 체인이 너무 불안정하고 불확실하다는 것입니다. 이는 클래스 수준의 링크가 실수임을 의미합니다. 방은 어린이, 새장, 하이퍼큐브 또는 지하세계와 연관될 수 있으며 이에 따라 콘텐츠가 배치될 수 있습니다. 표준 OOP 클래스는 컴포지션 내에서 링크를 쉽게 변경할 수 없지만 핵심은 제공합니다.
이러한 관계를 "객체 구성/집계"라고 하지만 지속적으로 커널로 되돌아갑니다. 원하는대로 링크를 추가하십시오. 여기에는 새로운 것이 없습니다.
추신: 나는 비디오를 대각선으로 보았지만 그다지 많지는 않았을 것입니다.머리를 자르려면 5-10 루블을 보내십시오.)
커널이 구성(객체의 내용)을 쉽게 변경할 수 있는 이유는 무엇입니까? - 엔티티의 핵심에는 변수가 있는 메모리 셀이기 때문입니다. 클래스는 편집기 수준에서 개체에 대한 설명입니다 . 코드 수준에서.
코드는 편집기를 통해 변경됩니다. 메모리는 인터페이스나 프로그램 자체를 통해 변경됩니다. 즉, 클래스(객체 캡슐)가 코드에서 배열(코어)로 배치되면 처리 및 수정이 100배 더 빠르고 유연해집니다.