첫 번째 부분에서 우리는 Object의 구성요소에 대해 이야기했고, 이 부분에서는 서로 간의 관계를 고려할 것입니다. 구성 요소 자체는 완전한 개체가 아니지만 모든 개체 및 시스템의 일부인 일부 "건물" 엔터티를 나타내기 때문에 조건부로 " 프로토 블록 "이라고 합니다. 그들의 초기 목록을 상기시켜 드리겠습니다.
매개변수 는 특정 구조적 집합 또는 값의 명명되고 압축된 표현입니다.
속성 집합 - 개체에 포함된 매개변수 목록입니다.
생성자 함수 는 매개변수 목록을 기반으로 객체를 재생산하는 알고리즘입니다.
모양 - 2차원 또는 3차원에 존재하는 개체에 속하는 집합 유형을 결합합니다.
상태는 개체의 존재에서중요한 "중단점 "입니다. 환경 조건이 변경되거나 독립적인 프로그램 실행 과정에서 Object가 전달하는 매개변수 값입니다.
이벤트는 개체 자체 또는 환경의 중요한 변경 사항입니다.
프로세스 - 변화하는 환경 조건 또는 독립적인 프로그램 실행 의 결과로 객체(들)의 상태를 변경하는 다양한 시퀀스 .
Form, State, Event 및 Process의 매개변수 "본문"에 추가 하여 처리기 함수 (그냥 "처리기"라고 부름)를 추가해 보겠습니다. 이 기능은 프로토블록에서 값을 "전송"하는 것입니다. 개체의 매개변수 집합에. 예: 레이블에는 생성자 함수에 5개의 매개변수가 있고 이 집합은 매개변수 "본문"입니다. 새로운 상태를 생각해내고 초기 매개변수의 다른 값으로 기록했다고 가정하고 Label을 새 상태로 전송해야 하는 순간에 매개변수에서 이를 전송하는 함수를 호출해야 합니다. 레이블의 파라메트릭 "본문"에 대한 상태 구조. 간단히 말해서, 이 핸들러는 proto-block의 값으로 Object의 매개변수를 초기화합니다. Process 와 Form 의 경우 유사한 원칙이 Object의 본문으로 값을 전송하는 데 적용되지만 구현은 다릅니다. 그러나 이벤트 를 처리하기 위해 값을 전송할 필요가 없습니다. 값을 확인할 필요가 있습니다. 즉, 조건 연산자가 핸들러로 적합하다는 의미입니다.
내 개념에는 많은 핸들러가 있으며 별도의 분류가 필요하지만 이것은 프레젠테이션을 너무 복잡하게 만들므로 조건부로 여러 그룹으로 나누어 피상적으로 만질 것입니다.
" Transporters " - proto-block에서 Object로 값을 전송하는 핸들러입니다(예: State, Form, Process에서 Object의 대상 매개변수로).
" 연결됨 " - 시스템에서 관련(종속) 매개변수의 값을 변경하는 처리기(예: 이동의 포물선 궤적은 좌표 값의 동기적 변경을 의미하며 이는 x,y를 연결하는 처리기에 의해 구현됩니다. 매개변수). 매개변수 링크의 종속성은 수식으로 표현하거나 핸들러 본문에 포함된 조건으로 정의할 수 있습니다.
" 어셈블러 " - 객체의 매개변수 본문에서 "압축을 풀고" 중요한 현재 값으로 저장하거나 다른 프로토블록을 부분적으로 또는 전체적으로 "복제"하여 새 프로토블록을 "빌드"하고 사본에 필요한 변경. 이 프로세스에서 테이블 또는 계층 구조는 저장되는 특수 "모듈" 내에서 정렬된 프로토 블록에서 형성됩니다.
"모듈식" - 프로토 블록을 저장하는 다양한 유형 의 모듈용 핸들러입니다. *(프로토 블록의 "모듈"은 나중에 논의됩니다).
이것은 완전한 목록이 아니며 핸들러 유형의 이름은 임의적이지만 전문화의 구분은 일반적으로 다음과 같습니다.
핸들러 함수 이후에 개념에 추가되는 다음 항목은 " 모듈 "입니다. 생성된 프로토 블록은 어딘가에 저장되고 정렬되어야 한다고 가정하는 것이 논리적이며, 혼란을 피하고 핸들러가 개체의 증가하는 내용 내에서 쉽게 "방향"을 지정합니다. 따라서 우리는 "창고"를 만들거나 훨씬 더 아름답기 때문에 프로토 블록의 " 모듈 "을 만듭니다. 객체의 상태, 프로세스, 이벤트 및 형식에 대해 프로토 블록이 다음과 같은 자체 모듈이 생성됩니다.
순서대로 저장합니다.
곱하다.
필요한 경우 핸들러에서 검색합니다.
다른 모듈의 프로토 블록에 대한 링크.
네 번째 요점 - 서로 다른 유형의 프로토 블록 "바인딩"은 서로에 대한 "구조적 포함"을 기반으로 합니다. 첫 번째 부분에서 설명했습니다. 프로세스에는 상태가 포함됩니다. ... 이벤트에는 상태가 포함됩니다. ... 프로세스 포함 이벤트, ... 상태는 양식 등을 포함할 수 있습니다... 예를 들어, 별도의 모듈에서 이벤트 모델을 빌드하면 해당 조건의 계층 구조에는 "이벤트"에 저장된 이벤트가 포함됩니다. 모듈 및 이러한 이벤트는 차례로 상태 모듈에 저장된 상태를 포함합니다. 따라서 우리는 프로토 블록의 효율적인 저장 및 사용 순서를 생성할 뿐만 아니라 모듈 간의 링크를 통해 서로 연결함으로써 "구조적 포함"을 구현합니다. 임의로 또는 신중하게 연결을 변경하여 기존 블록에서 새로운 프로토 블록을 생성하고 객체의 "동작"에서 이벤트 또는 논리적 모델을 변경할 수 있습니다. 논리적 모델 수준에서 링크를 변경하면(다시 자체 모듈에 저장됨) 프로그램을 완전히 변경할 수 있으며 동시에 코드에서 아무 것도 다시 작성할 필요가 없습니다. 이것에서 나는 프로토 블록의 모듈식 분할의 장점을 봅니다.
그리고 "응용 프로그램"은 무엇에 쓰여 있습니까?
응용 언어에서.
2 부.
첫 번째 부분에서 우리는 Object의 구성요소에 대해 이야기했고, 이 부분에서는 서로 간의 관계를 고려할 것입니다. 구성 요소 자체는 완전한 개체가 아니지만 모든 개체 및 시스템의 일부인 일부 "건물" 엔터티를 나타내기 때문에 조건부로 " 프로토 블록 "이라고 합니다. 그들의 초기 목록을 상기시켜 드리겠습니다.
Form, State, Event 및 Process의 매개변수 "본문"에 추가 하여 처리기 함수 (그냥 "처리기"라고 부름)를 추가해 보겠습니다. 이 기능은 프로토블록에서 값을 "전송"하는 것입니다. 개체의 매개변수 집합에. 예: 레이블에는 생성자 함수에 5개의 매개변수가 있고 이 집합은 매개변수 "본문"입니다. 새로운 상태를 생각해내고 초기 매개변수의 다른 값으로 기록했다고 가정하고 Label을 새 상태로 전송해야 하는 순간에 매개변수에서 이를 전송하는 함수를 호출해야 합니다. 레이블의 파라메트릭 "본문"에 대한 상태 구조. 간단히 말해서, 이 핸들러는 proto-block의 값으로 Object의 매개변수를 초기화합니다. Process 와 Form 의 경우 유사한 원칙이 Object의 본문으로 값을 전송하는 데 적용되지만 구현은 다릅니다. 그러나 이벤트 를 처리하기 위해 값을 전송할 필요가 없습니다. 값을 확인할 필요가 있습니다. 즉, 조건 연산자가 핸들러로 적합하다는 의미입니다.
내 개념에는 많은 핸들러가 있으며 별도의 분류가 필요하지만 이것은 프레젠테이션을 너무 복잡하게 만들므로 조건부로 여러 그룹으로 나누어 피상적으로 만질 것입니다.
이것은 완전한 목록이 아니며 핸들러 유형의 이름은 임의적이지만 전문화의 구분은 일반적으로 다음과 같습니다.
핸들러 함수 이후에 개념에 추가되는 다음 항목은 " 모듈 "입니다. 생성된 프로토 블록은 어딘가에 저장되고 정렬되어야 한다고 가정하는 것이 논리적이며, 혼란을 피하고 핸들러가 개체의 증가하는 내용 내에서 쉽게 "방향"을 지정합니다. 따라서 우리는 "창고"를 만들거나 훨씬 더 아름답기 때문에 프로토 블록의 " 모듈 "을 만듭니다. 객체의 상태, 프로세스, 이벤트 및 형식에 대해 프로토 블록이 다음과 같은 자체 모듈이 생성됩니다.
네 번째 요점 - 서로 다른 유형의 프로토 블록 "바인딩"은 서로에 대한 "구조적 포함"을 기반으로 합니다. 첫 번째 부분에서 설명했습니다. 프로세스에는 상태가 포함됩니다. ... 이벤트에는 상태가 포함됩니다. ... 프로세스 포함 이벤트, ... 상태는 양식 등을 포함할 수 있습니다... 예를 들어, 별도의 모듈에서 이벤트 모델을 빌드하면 해당 조건의 계층 구조에는 "이벤트"에 저장된 이벤트가 포함됩니다. 모듈 및 이러한 이벤트는 차례로 상태 모듈에 저장된 상태를 포함합니다. 따라서 우리는 프로토 블록의 효율적인 저장 및 사용 순서를 생성할 뿐만 아니라 모듈 간의 링크를 통해 서로 연결함으로써 "구조적 포함"을 구현합니다. 임의로 또는 신중하게 연결을 변경하여 기존 블록에서 새로운 프로토 블록을 생성하고 객체의 "동작"에서 이벤트 또는 논리적 모델을 변경할 수 있습니다. 논리적 모델 수준에서 링크를 변경하면(다시 자체 모듈에 저장됨) 프로그램을 완전히 변경할 수 있으며 동시에 코드에서 아무 것도 다시 작성할 필요가 없습니다. 이것에서 나는 프로토 블록의 모듈식 분할의 장점을 봅니다.
모든 동안. 다음으로 이벤트 및 논리적 모델로 이동하여 구축 방법을 고려할 것입니다.
불분명하거나 흥미로운 것이 있으면 질문하십시오.
이 개념은 무엇을 위한 것입니까?
이 개념은 다음 수준의 프로그래밍으로 이동하려는 시도이며, 내 생각에는 사람이 아닌 컴퓨터 자체에 의한 기능 시스템의 "구축"(쓰기가 아님)이 될 것입니다. 프로그램은 프로그램을 만들 수 있습니다.
이제 github 코드에 대해 훈련된 신경망이 있지만 이것은 내가 의미하는 바가 아닙니다.
이 개념은 다음 수준의 프로그래밍으로 이동하려는 시도이며, 내 생각에는 사람이 아닌 컴퓨터 자체에 의한 기능 시스템의 "구축"(쓰기가 아님)이 될 것입니다. 프로그램은 프로그램을 만들 수 있습니다.
이제 github 코드에 대해 훈련된 신경망이 있지만 이것은 내가 의미하는 바가 아닙니다.
안녕 피터.
OOP 외에도 DDD( Domain-Driven Design )도 있습니다.
그냥 알아두세요.
안녕 피터.
OOP 외에도 DDD( Domain-Driven Design )도 있습니다.
그냥 알아두세요.
당신은 따뜻한 것과 부드러운 것을 혼동하고 있습니다.
당신은 따뜻한 것과 부드러운 것을 혼동하고 있습니다.
시그널 어딨어 형?
시그널 어딨어 형?