我的方法。核心是引擎。 - 页 135

新评论
 
Реter Konow:

那里有一个不同的问题。核心要素和参数的限制。我知道解决方案应该是什么。我只是还没有机会去做。

这就是我问的原因。如果你把21条线缝在内核里，那就不是很好了，你不能随便修理它。

Reg Konow:

不是，是为构造函数编写的外部代码。这再现了该表。然后我点击按钮，所有的连接文件和引擎的启动内核都被打印出来。然后，一切都会好起来。

据我所知，它是一个自动生成器，生成自动连接代码和一些内核代码。这是一个有趣的解决方案。

 
Vasiliy Sokolov:

我还没有测试过。

这对我来说很有效。但在触发止损时关闭一行似乎有问题。有时，这一行仍然存在。这是我写的代码中检测平仓订单的问题。桌子与此无关。

 
Vasiliy Sokolov:

1.这就是我问的原因。如果你在内核里有21行，那就不好了，你不能就这样修复它。

2.我知道它是一个自动生成器，生成自动连接代码和一些内核代码。有趣的解决方案。

1.没错。在构造函数中可以规定有限数量的元素。因此，一个动态表必须由有限的行数组成，但同时又是不受限制的。解决办法只是为添加的参数创建特殊数组，并通过表格单元 滚动它们的值。

2.是的，构造器根据你引用的代码为引擎创建内核。+ 打印连接文件。然后，我把内核放入引擎（DRIVE）。之后，该引擎可以播放所需的GUI。接口文件连接到EA并开始与它互动。

 

为了不至于没有证据，我最后给你一个 "内核 "本身的例子。更确切地说，它是一个启动文件。有几个内核。

让我提醒你，它是自动打印的，基于KIB代码。然后放在发动机里。更进一步说，发动机与它一起工作。

附加的文件：
D_r7impg07d2r_x6q8.mqh  9272 kb
 
Реter Konow:

尼古拉，让我们来谈谈这个话题。以CCanvas类为例，我已经处理过了。所以，我把它的所有功能都拿出来了。使它们独立于类的包装器。现在的情况怎么会更糟呢？与他们一起工作变得更容易了。我用这些函数做了一个动画。在这之前，我几乎没有看到过这个类的动画。

那么，为什么要采用这种包装方式呢？

你也在画布上作画。你可以直接调用一个特定的函数并绘制。但是没有。你把一切都包了又包。那么请向我解释，为什么？

是的，因为它非常方便。但这是很难理解的，直到自己开始使用它。
而且它根本不是一个包装器，而是一个独立的多功能元素，它不仅可以在编辑器中使用，因为它的属性和参数列表是可见的，而且还可以作为一个特定的模块在其他程序中编辑和使用。
 
Nikolai Semko:
是的，因为它是巨大的舒适性。但在自己开始使用之前，这很难理解。
而且，它不是一个包装器，而是一个独立的多功能元素，不仅因为其属性和参数列表的可见性而方便在编辑器中使用，而且也方便在其他程序中作为一个特定的模块来编辑和使用。

我不能够以一种使我方便的方式来思考。因此，这对我来说并不方便。包围，描绘对象的方向。在必要和不需要的时候进行分类...

人们的印象是，OOP本身就挡在了它应该服务的机制前面。也就是说，该机制必须努力追求完整性，因此其区块的数量要最小。但OOP迫使这些块因任何原因而相乘。因此，机制的结构被打破，它们不能很好地工作。而他们的发展甚至更糟。


Nikolay，开始创建巨型机制（比Kanvas类大10倍），你会明白OOP在哪里以及如何变得不方便。

 
Реter Konow:

我不知道如何以一种让我舒服的方式思考。因此，对我来说，这是不舒服的。围绕着，描绘着对象的方向。在必要和不必要的时候进行分类...

人们的印象是，OOP本身就挡在了它应该服务的机制前面。也就是说，该机制必须努力追求完整性，因此其区块的数量要最小。但OOP迫使这些块因任何原因而相乘。因此，机制的结构被打破，它们不能很好地工作。而他们的发展甚至更糟。

Nikolay，开始创建巨型机制（比Kanvas类大10倍），你会明白OOP在哪里以及如何变得不方便。

你的话只说了一件事。


 
从前有一个很好的程序员，他为自己编程，不知道什么是悲伤，很开心，但他是OOP的大反对者。
几年过去了，我们的程序员老了，现在他觉得自己的时间到了，所以他给他的孙子和亲戚打电话说。
- 给我一台笔记本电脑，我就用OOP 做一个电子表格!
每个人都很惊讶，并说。
- 怎么会这样，你一辈子都在用你的平板电脑工作，没有OOP。发生了什么事？
而程序员回答说。
- 我会用OOP做一个电子表格，然后我就死了，这样就少了一个OOP的人。
 
Nikolai Semko:

...

尼古拉，你有没有想过，你对OOP的热爱，除了抽象的原因，几乎没有任何理由。

说，如果你用这种OOP创建巨大的机制，就会明白为什么你这么需要它。你会特别证明你为什么需要OOP。但是，你创造了相对较小的机制。那里没有足够的代码来得出关于这种或那种方法的缺点和优点的结论。但你还是一直在谈论OOP。而OOP只是一个工具，本身没有任何意义。也就是说，如果没有机制可言，OOP就没有必要。但是，如果有一个机制，它应该足够严肃，以至于在创建它时需要OOP。

大多数为OOP站台的人并没有认真做什么。他们只做小事。然而，他们对OOP的信念是不可动摇的。其他那些做得更严肃的机制的人就更不可能喊出OOP的伟大了。有些人甚至说出了批评的话（有几次）。

因此，你的论点需要有实践的支持，而不仅仅是理论。例如，我可以和Anatoly争论OOP在GUI开发中的好处，因为我们可以比较解决方案和它们在实践中的细微差别。但是，对于你，我无法部署我的论点，因为你不会理解它。你会的，但你不会理解它（无意冒犯）。相反，阿纳托利却能很好地理解它。创建全球机制的经验差异是造成误解的主要原因。

作为一个实践者，我要告诉你：方法必须是这样的，它将最大限度地发挥特定程序员的大脑潜力。我已经为自己找到了这样一种方法。

 
Реter Konow:


好吧，如果我不发表什么大东西，并不意味着我没有什么大东西。只是，我只分享小事。
我也抵制了很长时间的OOP范式，因为我学习编程的时候，OOP还不是一个东西。而OOP对我来说是一种被迫的需要，当时我刚开始在一个 大项目 的程序化代码中陷入困境。我为我在程序化编程中失去的时间感到遗憾，当时我在实践中理解了OOP的所有魅力和力量。
1...128129130131132133134135136137138139140141142...184
新评论