Mt4结束支持。 - 页 28

新评论
 

我不知道是否有人建议过，但为什么不把MT4中的所有内容转移到MT5中，那样大家就会继续前进。

 

George Merts:

他们先写出各部分，然后将它们组合成一个整体，往往发现各部分之间互不兼容--顺便说一下，这也解释了 "能够获得所有可用的变量 "的愿望。

不，不是的。这并不是说要获得所有可能的变量，只是你需要的那些变量。这些通常是不同函数的输入和输出变量。

在这里添加额外的边界会立即使代码的可读性 变得更加困难，并且当某些东西因为这些边界而在路上迷失时，会增加可能的错误。

当然可以理解的是，至少在某种程度上希望把OOP拉回来做一些有用的事情，但这种情况通常不是在编程领域，而是在商业领域，例如为了额外的编程时间，创造无休止的关于界面架构的讨论，以及类似工作时间的愉快消遣。

 
Vladimir:

原则上，是否有这样的例子？即使不是你的？我有深深的怀疑。在千分之二的年初，我不再计算我写的程序代码的调试和工作行数，因为它超过了一百万--它变得无趣了。而且我从来没有遇到过必须自己创建班级的情况，尽管我的任务种类和规模都非常多样化。当需要为几个人并行工作时，我不得不使用过程型变量，但不再是了。为什么会这样呢？

问题是，OOP只能应用于准备好的代码的包装，它只能在代码编写阶段阻止它。但如果没有这种需要，你也不需要OOP。

弗拉基米尔。

事实证明，OOP阻止了计算的自动平行化。如今，它应该被认为是一个非常严重的缺点，观点不适合OOP。

观点是在像Systemverilog这样的语言中。

 
Dmitry Fedoseev:

除了isNewBar()函数根本就不应该存在外，其他都没问题。有趣的是，在这样一件小事上有这么多的舞蹈。

这只是一个变量，它被简单地与条形图的时间相比较；如果所有的情况都是成功的，那么这个变量就被分配到最后的新条形图 的时间。否则，对所有案件只分配一次尝试。

这正是我的做法。
 
Andrei:

在这里添加额外的边界会立即使代码的可读性 变得更加困难，并且当某些东西因为这些边界而在途中迷失时，可能会增加错误。

这恰恰相反--边界允许你不去思考 "为什么是这个变量，它在这个案例中起什么作用，是否应该考虑到它？"。

用户只能访问他们需要考虑的内容，并且只能访问他们可以改变的内容。这些正是 "当某些东西在途中丢失时 "的错误--之所以出现，正是因为有太多可利用的东西，而某些东西 "在途中被遗忘"。对于 "截断的 "虚拟利益，这就更难做到了。

这里有一个最简单的例子：获得一个职位。仓位是指MT4中的未结订单或MT5中的未结头寸。

如果你有完全的权限，那么当选择一个位置时--用户必须记住哪些变量现在可以被读取，哪些变量目前无效，哪些变量他可以改变，哪些不能。

有了这个界面，事情就简单多了。你得到了它，它只有两个功能：得到组件的数量，和得到一个指向常量组件的指针。就这样了。有了这两个函数--你在物理上无法访问任何 "额外的变量"。

安德烈。

当然，我理解人们希望至少在某种程度上拖动OOP做一些有用的事情，但这种情况通常不在编程领域，而是在商业领域，比如额外的编程时间，无休止地讨论接口的结构和类似于办公时间的愉快消遣。

而你迟早会走到这一步。此外，封装可以用 "纯程序化 "的方式进行。但在OOP方法中，它更方便，因为你仍然可以 "自动 "得到继承和多态性。

 
Aleksey Altukhov:

我不知道是否有人建议过，但为什么不把MT4中的所有内容转移到MT5中，那样大家就会继续前进。

问题不仅仅是4中有些东西不在5中。而且这甚至不是OOP。

5几乎没有给交易员（不是程序员，不是软件交易员--只是交易员）任何好处。

自己的历史格式，禁止定制 - 但这两点已经吓跑了所有交易几何的人。而没有 "许多TFs"（没有年头，笑），每条杠上的 点数刻度会吸引他们。

一个简单的问题。格子 "显示的是什么？试图找出将导致你的建议是去自由职业，并订购任何你想要的东西。

MT是程序员的终端。这就是整个答案。

 
Andrei:

问题是，OOP只能适用于包装好的代码，在编写代码的阶段，它只能起到干扰作用。但如果没有这种必要性，在OOP中就没有必要。

不，不是的。这只是相反的方式。

接口是最初定义的，甚至是 "在编写代码阶段之前"。 实际上，接口对程序员来说都是同一个ToR。Freelance中的所有互动都是使用明确的ToR进行的。因此，虚拟接口是一种TOR，这是编程开始的地方。

据我所知，你只是错误地对待了OOP的本质。你先写一堆函数，然后你必须把它们 "挤 "进OOP设计中。但这是一个错误的方法。正确的方法是相反的--首先你要定义OOP-定义，即系统中各组件之间的那些基本接口集合。然后一个接一个地按照这些非常预定义的接口编写每个组件。

是的，有时候我们在写代码的时候会发现，接口没有提供什么。然后你开始..."哦......在程序性方法中--我可以访问所有这些，我做我需要的事情没有问题，但是现在--我怎么才能访问这些变量？"。这种情况发生在界面的设计阶段--有些东西没有被考虑在内。这是一个非常不愉快的情况--你要么必须增加一些额外的接口，要么改变现有的接口--这充满了错误。这种情况当然应该避免。

 
George Merts:

这里有一个最简单的例子：获得一个职位。仓位是指MT4中的未结订单或MT5中的未结头寸。

如果你有完全的权限，当选择一个位置时--用户必须记住哪些变量现在可以读取，哪些变量目前无效，哪些变量他可以改变，哪些不能。

有了这个界面，事情就简单多了。你得到了它，它只有两个功能：得到组件的数量，和得到一个指向常量组件的指针。就这样了。有了这两个函数--你在物理上不能访问任何 "额外的变量"。

事实恰恰相反。例如，用户经常需要知道内部变量，以便对模块进行质量测试，而情况并非如此。并发明了特殊的巧妙方法，以便事后获得这种权限。因此，原则上不存在多余的信息，不需要的人可以直接不使用它。

 
Andrei:

这恰恰相反。例如，用户往往需要知道内部变量，以便测试质量模块，而情况并非如此。而且他们在事后想出了特别巧妙的方法来获得这种权限。因此，没有不必要的信息，那些不需要的人干脆不使用它。

如果你需要 "狡猾的访问来获得它" - 这表明系统设计 不正确。

例如，如果我们写一个输入信号发生器--我们不应该获得有关信息，例如资金管理。

当然，在调试过程中，可能会出现这样的情况，比如说，没有进场 - 我们应该立即消除这种情况，当它发生时，因为资金管理禁止操作（比如，没有足够的保证金）。你又是如何从条目生成器中得知的呢？你没有--你没有权限。但在这种情况下--只需确保生成器设置了一个输入信号，而且工作正常即可。没有输入--由于其他一些原因，这在输入发生器之外。在这种情况下，找出原因确实比我们直接接触到资金管理的所有变量更难。但是，更危险的是，在正常的、例行的操作中--我们，有机会接触它们--会 "进入错误的地方"。

 
George Merts:

如果需要'棘手的访问获取'，则表明系统设计不佳。


发展首先是一个自然的思维过程。

在这个过程中，思想是自由的，甚至是自发形成的。

遵循OOP使得代码难以自由转换。

在自然的发展过程中，代码本身逐渐缩小和普及。

在自然过程中，这些功能并没有分解，相反，它们成长并联合成大块。

大区块可以解决广泛的任务。

OOP防止这些块的形成，使代码变得支离破碎。

OOP创造了复杂的访问方式，从而稳步增加了对变量的引用数量。

颗粒度的好处被制作一个连贯的机制的难度所抵消。


主要缺点：OOP迫使我们遵循将代码分割成若干个函数的方式。

人类更容易接受碎片化的代码，但碎片化是任何机制所不允许的。

1...212223242526272829303132333435...47
新评论