Mt4结束支持。 - 页 11

新评论
 

Vladimir:

也许是为了组织与用户的接口？这就是OOP的很多变体被设计出来的地方，Delphi中的一个可视化组件库。 所以，专家顾问和脚本的设计是为了在计算机上取代人类，这种界面直接与他们的目的相矛盾，它是不需要的。就是说，它是碍事的。就像笔刀中不必要的物品。或者在万能锤的钢柄末端装上钉子--不仅会划伤，而且会将重心从冲锋枪转移到手柄上。

在这一点上我不同意你的观点。

图形界面 对于那些明白全自动的EA远不如半自动的EA有效的自动交易商来说可能是必要的。从交易的角度来看，将自动交易和手动交易结合起来可以更加专业和有利可图。当人们意识到这一点时，他们的机器人肯定会需要一个接口。

 
Реter Konow:

1. graph_id比m_chart_id更容易被讲俄语的人阅读。


2.如果一个程序中有数百个变量，俄语提供了不可或缺的支持。


所有这些都可以通过实验来检验。


阅读和理解母语代码的速度总是会更快，记忆力也会更好。


你只需要搞清楚俄语中的变量命名规则。而不是 "variable_to_store_general_profit_position，只是：General_profit。


如果一个程序中有数百个变量，其中大部分可能可以通过结构来组合。另外，不要忘记使用功能。
许多变量根本没有意义，因为它们是计数器，是中间数据的临时储存器，被用在一堆括号后面。最重要的是，在所有的括号后面，我们可以再次使用相同的变量，但又是在括号里{....}。

或者最初用OOP编写。

 
Artyom Trishkin:

在我看来，他拒绝OOP的本质在于此。当然我可能是错的，但我通常觉得人。

在我看来，大多数非官方组织的问题是对 "限制合法权利 "的内部抵制。

一个老派的程序员习惯于在任何时候对任何数据、任何块、任何程序实体进行完全访问。而OOP方法意味着相反的情况--最大限度地限制权利，当你--可以访问非常小的一部分数据和程序操作。

在我的记忆中，我并不太喜欢它。早在Windows的早期，我记得我对受保护的内存访问非常反感--我不能访问我喜欢的地址，即使它在系统内核中又如何？我甚至可以想从一个程序中读出它，或者根本不改变它!我甚至编程了一个直接内存访问控制器，它将从 "禁止区域 "向 "允许区域 "发送数据，绕过系统限制。

但是，随着时间的推移，我真的很感激所有这些限制。"不必要的 "访问总是会变成错误。因此，将访问控制的工作--转移到编译器上是非常明智的。 在这里限制访问 原来是 "万无一失"，而不是 "侵犯你的权利"。如果你需要一个你没有的通道，那只能说明你设计的系统是错误的--如果你需要的话，你应该规定它。

而现在--相反，我总是尽可能地限制访问。在任何时候都应该只对那些必要的实体进行访问。所有其他实体都必须是无法进入的。这可以保护你不会因为访问了不该访问的地方而犯错，同时也让你习惯了一定的系统开发顺序，每一个操作都在一个地方进行，其他地方不受影响。

 
Mickey Moose:

例如，我讨厌以库的形式出现的嵌套，只是因为我不知道他们把什么放在那里，以及它能如何帮助我，多写一打函数更容易。

与我使用Re-Tag Konow的情况类似。

为什么呢？

许多地方都需要一个相同的函数--当你可以在库中拥有一切时，为什么要复制函数，而且不要用不必要的块来干扰主代码？

 
George Merts:

为什么呢？

许多地方都需要一个相同的函数--当你可以把所有的东西都放在库中时，为什么要复制函数，而不是用不必要的区块把主代码弄得一团糟？

我自己为这种情况建立了一个小型的函数数据库，当我需要的时候就会得到/添加它们。

想象一下，反编译一个1 mb的dll文件，阅读和思考他们放在里面的东西意味着什么。为什么有这么多额外的工作？
 
Реter Konow:

你很会找论据，尼古拉）。

祖母也是如此，吸收一切都没有问题。她只是下意识地不想让任何饰品把她安定的心绪拖入不必要的信息循环中。她是对的）。

彼得，原来你是个祖母。

 

你好

我也许能在这里得到一些帮助。我有个问题要问MT4的开发者。在哪里可以发声。如果在这个论坛上，那么在哪个主题中？还是其他地方？如果你知道，请告诉我。

 
Реter Konow:

在这一点上我不同意你的观点。

图形界面对于那些意识到完全自动化的EA远不如半自动化的EA有效的自动交易商来说可能是必要的。从交易的角度来看，将自动交易和手动交易结合起来可以更加专业和有利可图。当人们意识到这一点时，他们的机器人肯定会需要一个接口。

你完全支持那个说mql只应该有服务器访问功能的人，而其他一切通过拐杖的方式都应该由第三方开发工具来编程。不要偏离党的路线。要有连贯性--把你所有的发展都倾倒在mql上，做一个桥梁--比如在工作室--或者你要写画板的地方......。然后报告你对工厂的下一次胜利。

 
Mickey Moose:

例如，我讨厌以库的形式出现的嵌套，只是因为我不知道他们把什么放在那里，以及它能如何帮助我，多写一打函数更容易。

类似于Retrog Konow的情况。

嗯，能量守恒定律：如果没有它，一切都能正常工作，为什么还要反编译库和理解它呢？

P.S.

你看到我关于麋鹿的顶部了吗？

当你的代码开始溢出10，20，30，......。，10万行，然后回来告诉我你是如何以这样的量复制你的代码的。

 
George Merts:

在我看来，大多数非官方组织的问题是对 "限制合法权利 "的内部抵制。

一个老派的程序员习惯于在任何时候对任何数据、任何块、任何程序实体进行完全访问。而OOP方法意味着相反的情况--最大限度地限制权利，当你--可以访问非常小的一部分数据和程序操作。

在我的记忆中，我并不太喜欢它。早在Windows的早期，我记得我对受保护的内存访问非常反感--我不能访问我喜欢的地址，即使它在系统内核中又如何？我想让它从一个程序中读出来，或者根本不改变它!我甚至编程了一个直接内存访问控制器，它将把 "禁止 "区域的数据发送到 "允许区域"，绕过了系统限制。

但是，随着时间的推移，我真的很感激所有这些限制。"不必要的 "访问总是会变成错误。因此，将访问控制的工作--转移到编译器上是非常明智的。 在这里限制访问 原来是 "万无一失"，而不是 "侵犯你的权利"。如果你需要一个你没有的通道，那只能说明你设计的系统是错误的--如果你需要的话，你应该规定它。

而现在--相反，我总是尽可能地限制访问。在任何时候，只有需要被访问的实体应该是可用的。所有其他对象都必须是不可触及的。这可以保护你不会因为访问了不该访问的地方而犯错，同时也让你习惯了一定的系统开发顺序，每一个操作都在一个地方进行，其他地方不受影响。

你举了一个很好的例子，说明OOP可以排斥什么。

在我的情况下，情况有点不同。我开始学习OOP，但在某个阶段，我不再看到使用OOP的任何实际好处。时至今日，这一点仍未改变。这都是因为我形成了我的方法，把OOP推到了我的实践之外。

这种说法--访问限制是一种必要的保护，可以避免错误--我完全不能理解。如果变量名称在程序的不同部分重合，当然可以。但是，如果在一个数组中存在所有主要全局变量的共同全局内存，你就不需要限制，也不会有任何混淆了。

1...456789101112131415161718...47
新评论