巴解组织的间接费用 - 页 3

[Andrei01]

George Merts:

1.例如，你需要一个对象的数组。

你可以按程序来做，也可以基于CArrayObj和CObjest来做。 当你需要改变行为的时候，问题就开始了，比如说，增加或删除对象，或对它们进行排序。在OOP中，对指针数组本身的支持以及与之相关的工作都包含在基础对象中。修改实际包含在数组中的后裔对象不会影响任何东西。在程序化风格中--修改实际包含在数组中的真实对象--通常会影响到更多的地方，至少因为我们要考虑对象的大小变化。这将更容易导致错误。

2.跨平台--以OOP方式组织也更方便。当请求时，例如，一个交易头寸 - 我们得到一个界面，不管我们在什么平台上工作 - 界面提供虚拟功能，在上面你可以得到所有订单（MT4）或头寸（MT5）的所有数据，而且，从专家的角度来看 - 没有区别。专家顾问不需要知道他/她在什么平台上工作。

3.好吧，"在程序化编程中完成 "就是 "编写对象-程序"，也就是在数据和程序之间建立一些联系，在OOP中代表对象。

4.然后我们有，比如说，一些种类的订单，它们有很多共同点。建立一个对象COrderInfo是合理的，它将是基础对象，它的继承人将代表不同种类的订单。在这一点上，交易处理器（我有TradeProcessor类）将自动支持该订单，该订单已被传递给它，由那些处理该订单所需的程序来处理。

5.在交叉链接最少的地方更容易抓到虫子。这是通过封装和多态性来保证的。我们要求交易头寸接口（CTALPositionI），所有与代表该头寸的真实类（CMT4PositionInfo,CMT5PositionInfo）的连接都只通过该接口进行，这只是有助于更容易地纠正错误，而不是直接与返回交易头寸数据的真实函数合作。

1.为了什么？

为什么同一个函数不能在不同的平台上进行编译？

它的目的是通过结构类型来打包函数的文本，以便通过类比来处理作为类成员的函数，使处理更加方便。原则上不需要为此目的创建任何对象。

4.更合理的做法是将其设置成一个单一的函数，而不是通过接口将几个对象和不必要的连接相乘。

5.此外，所有这些环节都应该进行编程，然后通过接口等进行跟踪，这些地方的错误可能难以捕捉。这种占领从一开始就是不必要的，毫无意义的。

[Georgiy Merts]

Andrei:

1.例如，为了什么？

2.为什么同一个函数不能在不同的平台上编译，这样你就不必为它创建接口？

我的意思是按结构类型打包函数文本，以便更方便地访问，类似于把一个函数作为类成员来处理。原则上，不得为此目的创建任何对象。

4.做一个带有设置的单一功能，而不是通过接口将几个对象和不必要的连接相乘，是比较聪明的做法。

5.此外，所有这些环节都应该进行编程，然后通过接口等进行跟踪，这些地方的错误可能难以捕捉。这种占领从一开始就是不必要的，毫无意义的。

1.嗯，CTradePosition类 本质上是一个未结订单的列表。而对他们来说，有一个接口、一个基类和实际的类，将是非常有用的。

2.只有一个接口。对于所有的平台。而在OOP的情况下，我们并没有真正考虑到我们在哪里工作。我们不必考虑依赖平台和依赖秩序的事情。

而在这个包装中，对象和功能的区别是什么？这就是我要说的--这本质上是同一件事。在对象的情况下--自动构造函数也被添加，然而，在默认情况下--它是空的。

4.确切地说，这种非常 "带有设置的单一功能 "是问题的根源。因为通常有很多设置。而且他们不是分散在阶级层次的不同层面，而是集中在这一职能中。但是界面允许你把所有在特定环境下不使用的设置 "排除在外"--这对理解代码和错误的可能性及其检测有很好的效果。 这正是OOP的主要优势--所有的功能都 "分散 "在不同层次的对象中，当使用这一部分或那一部分时--其他功能不会受到干扰。另一方面，在一个带有设置的单一功能中，所有的功能都是可用的，即使是多余的。这通常是问题的来源，因为你可能不小心把变量弄混了。 主要的缺点是，在这样一个单一的函数中检测错误要困难得多。

5.在任何情况下，都需要这些环节，而且必须对它们进行编程--事实上，它们是单一功能中的相同设置。例如，在我的例子中--在一个单一的函数中，我们可以访问平台的差异，不同的订单类型，位置表示的差异--所有这些都必须被考虑到。而当有一个接口时--一切都被 "切断 "了--只有在接口中定义的东西才能被考虑到。

这就是封装的意义，限制从一个代码块到另一个代码块的访问。相反，你建议有 "一个大的通用功能，有最大的设置"，这样，任何能使用这个功能的人都有最大的可能性。相反，正确的方法是尽可能地限制用户，如果程序的一个块需要另一个块的功能--它应该只具有这个功能，而不是多一点。 这是一个更稳定和无错误的代码的关键。

[Andrei01]

George Merts:

1.嗯，CTradePosition类 本质上是一个未结订单的列表。订单可以是不同的，对它们来说，有一个接口、一个基类和真正的类是非常方便的。

而将订单保持在数组结构中，或者在MT4中实现的方式有什么问题？

[Georgiy Merts]

Andrei:

将订单保持在数组结构中或如MT4中实现的那样，有什么问题吗？

因为每个用户在访问这个阵列时都有太多的权限和太多不必要的信息。

在我看来，正确的做法是只给用户他们需要的那部分功能--只是通过使用预先约定的接口来访问订单。

[Andrei01]

George Merts:

每个用户在访问这个阵列时有太多的权利和太多的不必要的信息。

在我看来，正确的做法是只给用户他们需要的那部分功能--只是通过使用预先约定的接口来访问订单。

你可以为订单创建自己的数据类型，不需要任何接口、对象和其他不必要的构思，这些构思会造成不必要的错误和不稳定。

[Georgiy Merts]

Andrei:

你可以为订单创建自己的数据类型，不需要任何接口、对象和其他不必要的构思，这些构思会造成不必要的错误和不稳定。

我的经验表明，你确实需要这样做。

我大约在五年前走了这条路，那时是在MT4上。(不是因为我不知道OOP，而是因为我太懒了，懒得去理会接口和继承，尤其是当时MT4和MT5在MQL的实现上有很大的不同）。 这让我明白了它的谬误。 这不是 "智慧"，而是相当合理的限制，是一种 "傻瓜"。如果你总是记得数百个变量中的每一个负责什么--你就不需要封装了。我不记得了，我更喜欢在一个程序的每个区块中尽可能少的实体可用。

当MT4出现OOP时--我立即开始将我所有的开发转化为基于接口的单一形式。

[Andrei01]

George Merts:

1.我的实践表明，这的确是必要的。这使我明白了它的谬误。

2.我不记得了，我更喜欢在每块软件中尽可能少地访问实体。

1.从来没有解释过它的作用和谬误是什么。由于这是一种特殊的数据类型，你可以在那里按照你的意愿设置访问。这个例子显然是一个不幸的选择。

2.以程序员会在那里犯错为借口，拒绝他访问自己程序中的数据，显然是错误的想法，因为他将不得不创造各种错综复杂的变通方法来允许程序员访问，并在途中创造出不稳定的代码，并可能出现很多的错误。这就像禁止司机触摸方向盘，然后发明变通办法--接口，然后他就可以代替方向盘操纵汽车了。

[Georgiy Merts]

Andrei:

2.禁止程序员在他们的程序中访问他们的数据，借口是他据说会在那里搞破坏--这显然是错误的想法，因为这样你就必须创造各种复杂的变通办法来让程序员访问，而且沿途会产生不稳定的代码和一堆可能的错误。这就像禁止司机触摸方向盘，然后发明变通办法--接口，然后他就可以代替方向盘操纵汽车了。

没有。就在代码的任何地方--只有在那个地方需要的东西才可以用--如果可能的话，其他的东西都应该被切断。

在你和司机的情况下--这意味着禁止司机在汽车停放时触摸方向盘是合理的。因此，他不会在汽车停放时试图转动车轮--事实上，在那个时候，例如车轮定位传感器可以连接到车轮上，而司机抓住车轮会导致设置这些角度的错误。

这个想法是，在任何给定的时刻，只有程序在那一刻需要的功能是可用的，其他的都会被关闭。我长期以来一直相信，这是犯错最少的方法。

[Andrei01]

George Merts:

没有。就在代码的任何地方--只有在那个地方需要的东西才可以用--如果可能的话，其他的东西都应该被修剪掉。

这个想法是，在每个时刻，只有那些在那一刻需要的功能可以供程序使用，其余的都必须被锁定。很久以前我就知道，这是犯错最少的方法。

不断地纠结于禁止什么和允许什么显然是非常不合逻辑的要求，当然，除非程序员在写代码时喝醉了，不控制自己可能写出一堆他不理解的代码。我认为这不会帮助酗酒的程序员避免代码中的错误，而清醒的人首先就不需要它。

[Georgiy Merts]

Andrei:

不断地担心禁止什么和允许什么显然是一个非常不合逻辑的要求，当然，除非程序员在喝醉的时候坐下来写代码，并且无法控制自己，他可以写出很多他不理解的代码。我认为这不会帮助酗酒的程序员避免代码中的错误，而清醒的人首先就不需要它。

这是一个非常合乎逻辑的要求，很多人都来了。

你不需要它--嗯...不要使用OOP。