OOP在MQL5中会有需求吗？ - 页 2

新评论
 
Svinozavr >> :

你对什么感兴趣，是过程还是最终结果？)

我对这两者都感兴趣，但最终的结果不知为何更多。("......OOP给了你很多方法来减慢你的程序......" )

我不认为OOP能让我比程序性方法写得更快，而这将超过OOP的所有缺点。很明显，谁需要它--为他人写作的开发者。


让我给你打个比方：第一个人拿着一把刀，刻了一个花纹图案，而第二个人用同一把刀砍掉了他的半个手指。这有什么意义呢？任何工具都可以用来创造一个 "甜心 "和一个完全的流浪汉。这完全取决于程序员，他是一个工匠还是有天赋的火花。这是个题外话，但实质上--如果你喜欢FOP，那就进一步使用它。

 

在创建这个子项目时，我想看到赞成在项目中采用OOP的论点，以达到MT的目的。也许由于我的无知--我不是在调情--我没有看到他们。我现在也没有看到他们。

让我总结一下你们的帖子（顺便感谢你们所有人）。

1.项目实施的便利性和速度。

一个项目要有这么大的规模，才能感受到这种便利？让我看看为4创建的东西，用OOP来做会更方便。没有回答。

2.维护，升级。

还是那句话--项目的规模。

3.5是更快的，因为谁在乎如何编程。

好吧，这根本就不是一个论点。没有评论。

3.手感是OOP较慢的一个原因。

是的，我通常用手写程序，但如果我想使用OOP，我就背对着电脑。)))不，就算法而言，OOP会比程序式的慢。

------------

(耸耸肩）请理解，我并不反对OOP，我只是想自己找出它可能给我带来的MT任务--在创建指数、脚本、专家顾问方面。

好的。5日有一个帮助。谁能举例说明在5上使用OOP 编写的MT4标准的简单间接？你将能在那里看到。你也可以通过眼睛从文字、程序的可读性等方面估计延迟。

 
Svinozavr писал(а)>>

1.项目的便利和速度。

一个项目要有多大才能感受到这种便利？让我看看为4创建的东西，用OOP来做会更方便。没有回答。

2.维护，升级。

还是那句话--项目的规模。

1.对于了解基本原理的人来说，OOP是非常方便的。即使在最简单的应用中，你也能感觉到它。用OOP制作任何应用程序都更加方便。

2.只要不难理解，项目的规模并不是一个障碍。而且，如果一个程序是面向对象的，要理解它并不十分困难。一个例子是盛宝银行的终端。它是用C#编写的，这是一种面向对象的语言。每个dll包含大约20000行的代码。如果没有OOP，几乎不可能理解如此大量的信息，更不可能使其现代化。

 
5的问题不在于OOP。目前还不清楚如何从4中实施的大型先决条件中实现。图形对象的工作 是以 "癌症 "方式进行的。开发商已经承诺要改进它，但是.........到目前为止还没有感觉到任何改善。为玩具编程成为可能。
 
Svinozavr писал(а)>>

一个人要做多大的项目才能感受到这种便利？让我看看为4创建的东西，用OOP来做会更方便。没有回答。

可能nen的 ZUP会是一个好例子。那里面有很多棘手的东西。光是源代码的数量就令人肃然起敬（368Kb v82），更不用说内容了。
 
在5，没有人废除程序性编程。如果你不喜欢OOP，就用老方法写程序。 但他们在图形指标方面造成了一个巨大的问题。它们将很难实施。而对于程序员来说。而对于那些使用图形指标手动交易的人来说。普通交易员--而不是程序员--将不得不重新培训。而且不是每个人都能正确地做到这一点。
 
似乎MQ认为，只有用自动机器人进行交易。而5号文件正是面向机器人的。他们已经决定取消手工交易 这一类别。
 

他们的核心不再是OOP（尽管绝对的OOP实际上是无法使用的）。我们应该从一开始就创建抽象类，并使用继承和多态性来达到真正的对象。例如，为自定义指标 创建一个具有抽象方法和属性的抽象基类。最好是建立一个分层的类树：图形对象的树，用于处理账户，用于时间表和访问时间序列，等等。而对于预定义的程序和函数，只应留下需要速度的基本程序。然后，你可以从任何抽象的层面上扩展平台的能力，这将减少代码的大小，提高其可读性，并使其他程序员易于理解。而MT5已经在程序层面实现了相当复杂的东西（事实上整个平台已经可以使用了），我还没有看到至少通过指针访问创建的内部结构的描述符的可能性，这非常有局限性（从帮助中判断）。一般来说，对OOP的需求是值得怀疑的，有了这样的实现，它可以被限制在结构和动态放置上。OOP应该由一个广泛的类层次结构从下面支持。

 

需要1-3年的编程才能意识到，程序不是在写，而是在读。

又花了1-2年时间才意识到，程序不是为计算机而写，而是为人（特别是为自己）而写。

然后需要1-2年的时间才能注意到OOP和C++与人类的思维方式和构建人类语言的方法相矛盾。

又花了1-2年时间研究别人的代码，意识到最好的、最可靠的程序是用经典的Ce写的。

嗯，在那之后，阅读Dijkstra关于C++和OOP让他胃痛的采访就足够了。

在那之后（总共4-9年），"关于OOP "的问题根本就没有出现，这样的讨论只引起了一个放纵的微笑。

 
AlexEro >> :

而在那之后（总共4-9年），关于 "OOP "的问题根本就没有出现，这样的讨论只能唤起一个居高临下的微笑。

>> 我很同情。

123456789
新评论