1. 그래서 묻습니다. 커널에 21개의 라인을 꿰매었다면 이것은 그다지 좋지 않으며 그렇게 고칠 수 없습니다.
2. 내가 알기로는 이것은 자동 연결 코드와 커널 코드의 일부를 생성하는 자동 생성기입니다. 흥미로운 결정입니다.
1. 정확히. 생성자는 제한된 수의 요소를 가질 수 있습니다. 따라서 동적 테이블은 제한된 수의 행으로 구성되어야 하지만 동시에 무제한이어야 합니다. 유일한 해결책은 특별한 추가된 매개변수에 대한 배열 및 테이블 셀 을 통해 해당 값 스크롤 .
2. 네. 생성자는 제공한 코드를 기반으로 엔진용 커널을 생성합니다. + 연결 파일을 인쇄합니다. 그런 다음 엔진(DRIVE)에 커널을 배치합니다. 그 후 엔진은 원하는 GUI를 재생할 수 있습니다. 페어링 파일은 Expert Advisor에 연결되고 상호 작용을 시작합니다.
니콜라이, 객관적으로 이야기합시다. 이미 다루었던 CCCanvas 클래스를 예로 들어 보겠습니다. 그래서 나는 거기에서 모든 기능을 꺼내 들었다. 클래스 래퍼와 독립적으로 만들었습니다. 무엇이 더 나빠졌습니까? 그들과 함께 일하는 것이 더 쉬워졌습니다. 이 기능을 사용하여 애니메이션을 만들었습니다. 그 전에는 이 클래스로 애니메이션을 거의 본 적이 없었습니다.
그렇다면 왜 이 래퍼일까요?
캔버스에도 그림을 그립니다. 특정 함수를 호출하여 그릴 수 있습니다. 하지만. 당신은 돌고 돌고 돌고 돌립니다. 그래서 설명 - 왜?
예, 메가 편리하기 때문입니다. 그러나 직접 사용하기 전에는 이해하기가 매우 어렵습니다.
그리고 이것은 래퍼가 아니라 별도의 다기능 요소로 속성 및 매개 변수 목록의 가시성으로 인해 편집기에서 사용하기 편리할 뿐만 아니라 다른 프로그램에서 특정 모듈로 편집하여 사용하기에도 편리합니다.
Nikolai Semko : 예, 메가 편리하기 때문입니다. 그러나 직접 사용하기 전에는 이해하기가 매우 어렵습니다.
그리고 이것은 래퍼가 아니라 별도의 다기능 요소로 속성 및 매개 변수 목록의 가시성으로 인해 편집기에서 사용하기 편리할 뿐만 아니라 다른 프로그램에서 특정 모듈로 편집하여 사용하기에도 편리합니다.
편안하게 생각하는 방법을 모르겠습니다. 따라서 나에게는 불편합니다. 랩, 개체 방향을 나타냅니다. 필요할 때와 필요하지 않을 때 분류 ...
OOP 자체가 제공해야 하는 메커니즘 앞에 서 있다는 인상을 받습니다. 즉, 메커니즘은 무결성을 위해 노력해야 하므로 가장 적은 수의 블록에 대해 노력해야 합니다. 그리고 OOP는 어떤 이유로든 이러한 블록을 강제로 생성합니다. 이 때문에 메커니즘의 구조가 찢어지고 제대로 작동하지 않습니다. 그리고 그들은 더욱 악화됩니다.
Nikolai, 메가 메커니즘(Canvas 클래스보다 10배 더 큼)을 만들기 시작하면 OOP가 어디에서 어떻게 불편해지는지 이해하게 될 것입니다.
편안하게 생각하는 방법을 모르겠습니다. 따라서 나에게는 불편합니다. 랩, 개체 방향을 나타냅니다. 필요할 때와 필요하지 않을 때 분류 ...
OOP 자체가 제공해야 하는 메커니즘 앞에 서 있다는 인상을 받습니다. 즉, 메커니즘은 무결성을 위해 노력해야 하므로 가장 적은 수의 블록에 대해 노력해야 합니다. 그리고 OOP는 어떤 이유로든 이러한 블록을 강제로 생성합니다. 이 때문에 메커니즘의 구조가 찢어지고 제대로 작동하지 않습니다. 그리고 그들은 더욱 악화됩니다.
Nikolai, 메가 메커니즘(Canvas 클래스보다 10배 더 큼)을 만들기 시작하면 OOP가 어디에서 어떻게 불편해지는지 이해하게 될 것입니다.
Nikolai, OOP에 대한 당신의 사랑이 추상적인 이유를 제외하고는 거의 어떤 것으로도 정당화되지 않는다는 생각을 해본 적이 있습니까?
이 OOP를 사용하여 거대한 메커니즘을 만들었다면 왜 그렇게 많이 필요한지 분명할 것입니다. OOP가 필요한 이유를 구체적으로 입증해야 합니다. 그러나 상대적으로 작은 메커니즘을 만듭니다. 하나 또는 다른 접근 방식의 단점과 장점에 대한 결론을 도출하기에 충분한 코드가 없습니다. 그러나 당신은 여전히 OOP에 대해 이야기하고 있습니다. OOP는 단지 도구일 뿐이며 그 자체로는 의미가 없습니다. 즉, 수행할 메커니즘이 없으면 OOP가 필요하지 않습니다. 그리고 메커니즘이 있다면 생성 시 OOP가 필요할 정도로 심각해야 합니다.
대부분의 PLO 옹호자들은 진지한 행동을 하지 않습니다. 작은 품목만. 그러나 PLO에 대한 그들의 믿음은 흔들리지 않습니다. 훨씬 더 심각한 메커니즘을 만드는 다른 사람들은 OOP의 위대함에 대해 훨씬 덜 외칩니다. 일부는 비판적인 목소리를 내기도 합니다(몇 번이었습니다).
즉, 당신의 주장은 이론만이 아니라 실천에 의해 뒷받침되어야 합니다. 예를 들어, Anatoly를 사용하여 GUI 개발에서 OOP의 이점에 대해 논쟁할 수 있습니다. 왜냐하면 우리는 실제로 솔루션과 뉘앙스를 비교할 수 있기 때문입니다. 그러나 당신이 그것을 이해하지 못할 것이기 때문에 나는 당신과 함께 논쟁에서 돌아설 수 없습니다. 당신은 듣겠지만 이해하지 못할 것입니다(공격하지 않음). 그리고 반대로 Anatoly는 아주 잘 이해할 수 있습니다. 글로벌 메커니즘을 만드는 경험의 차이가 오해의 주요 원인입니다.
추신. 실무자로서 다음과 같이 말할 것 입니다. 접근 방식은 특정 프로그래머의 두뇌 잠재력을 극대화하는 방식이어야 합니다. 나 자신을 위해 그러한 접근 방식을 찾았습니다.
글쎄, 내가 큰 것을 게시하지 않는다고해서 내가 큰 것이 없다는 것을 의미하지는 않습니다. 나는 단지 작은 것들을 공유하고 있습니다.
나도 OOP 패러다임에 오랫동안 저항했다. 나는 아직 OOP가 없었을 때 프로그래밍을 배웠다. 그리고 OOP는 내가 대규모 프로젝트 의 절차적 코드에 질식하기 시작했을 때 강제적인 필수품이었습니다. 그리고 실제로 OOP의 모든 아름다움과 힘을 깨달았을 때 절차적 프로그래밍에서 잃어버린 시간에 대해 매우 유감스럽게 생각했습니다.
또 다른 문제가 있습니다. 제한된 핵심 요소 및 매개변수. 해결책이 무엇인지 압니다. 아직 하지 않았을 뿐입니다.
그게 내가 묻는 이유야. 커널에 21개의 라인을 꿰매었다면 이것은 그다지 좋지 않으며 그렇게 고칠 수 없습니다.
아니요. 이것은 생성자를 위해 작성된 외부 코드입니다. 그는 테이블을 재현합니다. 그런 다음 버튼을 클릭하면 모든 연결 파일과 엔진의 부트 커널이 인쇄됩니다. 그러면 모든 것이 작동합니다.
내가 알기로는 이것은 자동 연결 코드와 커널 코드의 일부를 생성하는 자동 생성기입니다. 흥미로운 결정입니다.
아직 확인하지 않았습니다.
나를 위해 작동합니다. 하지만 스톱이 발동될 때 행을 닫는 데 문제가 있는 것 같다. 때때로 행이 남아 있습니다. 이것은 내가 작성한 코드에서 마감된 주문을 감지하는 문제입니다. 여기 테이블은 쓸모가 없습니다.
1. 그래서 묻습니다. 커널에 21개의 라인을 꿰매었다면 이것은 그다지 좋지 않으며 그렇게 고칠 수 없습니다.
2. 내가 알기로는 이것은 자동 연결 코드와 커널 코드의 일부를 생성하는 자동 생성기입니다. 흥미로운 결정입니다.
1. 정확히. 생성자는 제한된 수의 요소를 가질 수 있습니다. 따라서 동적 테이블은 제한된 수의 행으로 구성되어야 하지만 동시에 무제한이어야 합니다. 유일한 해결책은 특별한 추가된 매개변수에 대한 배열 및 테이블 셀 을 통해 해당 값 스크롤 .
2. 네. 생성자는 제공한 코드를 기반으로 엔진용 커널을 생성합니다. + 연결 파일을 인쇄합니다. 그런 다음 엔진(DRIVE)에 커널을 배치합니다. 그 후 엔진은 원하는 GUI를 재생할 수 있습니다. 페어링 파일은 Expert Advisor에 연결되고 상호 작용을 시작합니다.
근거 없는 말을 하지 않기 위해 마지막으로 바로 그 "핵심"의 예를 들겠습니다. 보다 정확하게는 부트 파일입니다. 여러 코어가 있습니다.
KIB 코드를 기반으로 자동으로 인쇄됨을 알려드립니다. 그런 다음 엔진에 배치됩니다. 다음으로 엔진이 작동합니다.
니콜라이, 객관적으로 이야기합시다. 이미 다루었던 CCCanvas 클래스를 예로 들어 보겠습니다. 그래서 나는 거기에서 모든 기능을 꺼내 들었다. 클래스 래퍼와 독립적으로 만들었습니다. 무엇이 더 나빠졌습니까? 그들과 함께 일하는 것이 더 쉬워졌습니다. 이 기능을 사용하여 애니메이션을 만들었습니다. 그 전에는 이 클래스로 애니메이션을 거의 본 적이 없었습니다.
그렇다면 왜 이 래퍼일까요?
캔버스에도 그림을 그립니다. 특정 함수를 호출하여 그릴 수 있습니다. 하지만. 당신은 돌고 돌고 돌고 돌립니다. 그래서 설명 - 왜?
예, 메가 편리하기 때문입니다. 그러나 직접 사용하기 전에는 이해하기가 매우 어렵습니다.
편안하게 생각하는 방법을 모르겠습니다. 따라서 나에게는 불편합니다. 랩, 개체 방향을 나타냅니다. 필요할 때와 필요하지 않을 때 분류 ...
OOP 자체가 제공해야 하는 메커니즘 앞에 서 있다는 인상을 받습니다. 즉, 메커니즘은 무결성을 위해 노력해야 하므로 가장 적은 수의 블록에 대해 노력해야 합니다. 그리고 OOP는 어떤 이유로든 이러한 블록을 강제로 생성합니다. 이 때문에 메커니즘의 구조가 찢어지고 제대로 작동하지 않습니다. 그리고 그들은 더욱 악화됩니다.
Nikolai, 메가 메커니즘(Canvas 클래스보다 10배 더 큼)을 만들기 시작하면 OOP가 어디에서 어떻게 불편해지는지 이해하게 될 것입니다.
편안하게 생각하는 방법을 모르겠습니다. 따라서 나에게는 불편합니다. 랩, 개체 방향을 나타냅니다. 필요할 때와 필요하지 않을 때 분류 ...
OOP 자체가 제공해야 하는 메커니즘 앞에 서 있다는 인상을 받습니다. 즉, 메커니즘은 무결성을 위해 노력해야 하므로 가장 적은 수의 블록에 대해 노력해야 합니다. 그리고 OOP는 어떤 이유로든 이러한 블록을 강제로 생성합니다. 이 때문에 메커니즘의 구조가 찢어지고 제대로 작동하지 않습니다. 그리고 그들은 더욱 악화됩니다.
Nikolai, 메가 메커니즘(Canvas 클래스보다 10배 더 큼)을 만들기 시작하면 OOP가 어디에서 어떻게 불편해지는지 이해하게 될 것입니다.
당신의 말은 단 한 가지를 말해줍니다.
...
Nikolai, OOP에 대한 당신의 사랑이 추상적인 이유를 제외하고는 거의 어떤 것으로도 정당화되지 않는다는 생각을 해본 적이 있습니까?
이 OOP를 사용하여 거대한 메커니즘을 만들었다면 왜 그렇게 많이 필요한지 분명할 것입니다. OOP가 필요한 이유를 구체적으로 입증해야 합니다. 그러나 상대적으로 작은 메커니즘을 만듭니다. 하나 또는 다른 접근 방식의 단점과 장점에 대한 결론을 도출하기에 충분한 코드가 없습니다. 그러나 당신은 여전히 OOP에 대해 이야기하고 있습니다. OOP는 단지 도구일 뿐이며 그 자체로는 의미가 없습니다. 즉, 수행할 메커니즘이 없으면 OOP가 필요하지 않습니다. 그리고 메커니즘이 있다면 생성 시 OOP가 필요할 정도로 심각해야 합니다.
대부분의 PLO 옹호자들은 진지한 행동을 하지 않습니다. 작은 품목만. 그러나 PLO에 대한 그들의 믿음은 흔들리지 않습니다. 훨씬 더 심각한 메커니즘을 만드는 다른 사람들은 OOP의 위대함에 대해 훨씬 덜 외칩니다. 일부는 비판적인 목소리를 내기도 합니다(몇 번이었습니다).
즉, 당신의 주장은 이론만이 아니라 실천에 의해 뒷받침되어야 합니다. 예를 들어, Anatoly를 사용하여 GUI 개발에서 OOP의 이점에 대해 논쟁할 수 있습니다. 왜냐하면 우리는 실제로 솔루션과 뉘앙스를 비교할 수 있기 때문입니다. 그러나 당신이 그것을 이해하지 못할 것이기 때문에 나는 당신과 함께 논쟁에서 돌아설 수 없습니다. 당신은 듣겠지만 이해하지 못할 것입니다(공격하지 않음). 그리고 반대로 Anatoly는 아주 잘 이해할 수 있습니다. 글로벌 메커니즘을 만드는 경험의 차이가 오해의 주요 원인입니다.
추신. 실무자로서 다음과 같이 말할 것 입니다. 접근 방식은 특정 프로그래머의 두뇌 잠재력을 극대화하는 방식이어야 합니다. 나 자신을 위해 그러한 접근 방식을 찾았습니다.