OOP与程序化编程 - 页 35 1...282930313233343536373839404142...48 新评论 Georgiy Merts 2017.08.15 17:23 #341 Andrei: 小心,我们说的不是内部MT变量,我们说的是你已经隔离的内部对象变量,防止在调试和编写代码时读取其值的可能性......这就是我要说的--当你调试一个EA时--你不需要MT的内部变量吗? 同样,在这种情况下,对于交易处理器对象--如果你正在调试,例如,在你的TS中下订单的方法--为什么你要访问交易处理器的内部变量? Georgiy Merts 2017.08.15 17:24 #342 Комбинатор: 安德烈甚至比彼得或桑桑尼茨更有临床经验,你这是在浪费你的时间。年轻人需要接受教育。 此外,也许我的对手们所说的有一个合理的理由。如果我有,比如说,像彼得这样的记忆,我可能也不会去理会巴解组织。 Andrei01 2017.08.15 17:24 #343 George Merts:在其他地方也是如此--如果需要一些数据--那么这个块就必须提供相应的接口。 这就是我的意思...而不是仅仅看到所需变量的值,你必须考虑如何给它附加一个合适的接口,然后再把它解开。:)它看起来像一个为受虐狂而设的编程活动 :) Georgiy Merts 2017.08.15 17:27 #344 Andrei:是的......你不禁要问,这里面有什么呢 :)我们的想法是要有一个足够的编程语言,以最小的手势方便调试和编写代码,但这里我们有一个完全相反的情况...... 这不是一个'相反的情况'。诚然,OOP需要一些额外的工作。然而,这在支持和系统修改的便利性方面得到了补偿。 在这里,再次回到贸易处理器--它是在许多TS中编写和使用的。这是它的内部结构与TS的隔离,只通过一个虚拟接口工作,可以不考虑里面有什么变量,它们等于什么。如果检测到错误,它们将在处理器内部,有必要在一个真正的类中修复它们,而不影响TS类。如果错误是在TS本身,它不会影响交易处理器的变量。 封装实际上是一种非常有用的技术。 Ihor Herasko 2017.08.15 17:28 #345 Andrei:是的......你不禁要问,这里面到底有什么呢 :)我们的想法是要有一个足够的编程语言,以最小的手势方便调试和编写代码,但这里我们有一个完全相反的情况...... 调试恰恰是通过每个类的责任划分来促进的:每个类对自己的变量集负责。其他阶层无权改变他们的价值观。因此,大多数问题在编译阶段就已经被消除了。而从程序的任何地方访问变量,可以比作一艘船上的一打方向盘。 СанСаныч Фоменко 2017.08.15 17:30 #346 George Merts:年轻人需要接受教育。 此外,也许我的对手所说的也有合理的依据。比如说,如果我有彼得这样的记忆力,我也不会去理会OOP。1.通过使用OOPs,你的顾问的利润率提高了多少?2.你的顾问的利润率因使用OOP而下降了多少? Georgiy Merts 2017.08.15 17:32 #347 Andrei:这就是我的意思...而不是仅仅看到所需变量的值,你必须考虑如何给它附加一个合适的接口,然后再把它解开。:)它看起来像一个为受虐狂而设的编程活动 :)你看,在这个问题上,彼得给你看了他的一个结构,不是最大的那个。 你能轻易地弄明白吗? 这种非常的 "受虐狂 "恰恰允许你,首先,不进入工作代码,不破坏它。其次,它允许你立即设计 系统结构,以便你能在程序的相应块中提供必要的数据。 是的,的确,有些情况下,你突然意识到几乎不可能得到所需的数据。它们隐藏在几个虚拟界面后面。然而,这种情况清楚地表明,系统最初的设计是错误的,它没有规定传输这种数据。这种情况确实非常令人不快。我们要么匆忙地以附加接口的形式建立 "拐杖",要么重组整个系统。 嗯......这促使程序员更仔细地思考系统结构。 Maxim Kuznetsov 2017.08.15 17:36 #348 Andrei: 如果你在讨论的本质上少一些情感和反思性,多一些具体性--你就不值得了。:)这个讨论已经没有实质内容了。你从根本上说是在忽悠和装糊涂。 如果版主认为最后几页与主题和一般的编程无关而将其关闭--这将是一个罕见的情况,我将支持他的行动。 Georgiy Merts 2017.08.15 17:36 #349 СанСаныч Фоменко:1.通过使用OOPs,你的EA的利润率提高了多少?2.使用OOP后,你们顾问公司的失败率降低了多少?1.不知道是多少。盈利能力并不取决于OOP。2.在我看来,是一个数量级的(十倍)。但OOP的主要收获是在代码支持方面。现在我非常快地弄清了我一年或更久以前写的代码。我清楚地记得,我是如何理解我早期的ANSI C程序的,纯粹是程序化风格。这就更难了。 СанСаныч Фоменко 2017.08.15 17:37 #350 Ihor Herasko: 调试恰恰是通过每个类的责任划分来促进的:每个类对自己的变量集负责。其他阶层无权改变他们的价值观。因此,大多数问题在编译阶段就已经被消除了。而从程序的任何地方访问变量,可以比作船上的一打方向盘。我不明白为什么我在工作中从来没有遇到过这样的事情。为什么在一个不太大的程序中,一个开发者会出现变量访问定界的问题?会有100个开发人员,每个人都在编写100个函数。理论上,它可以被发明出来。但实际上,编程发展到OOP已经有近40年的时间了,堆积如山的代码已经写完了,从来没有听说过类似的事情。 1...282930313233343536373839404142...48 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
小心,我们说的不是内部MT变量,我们说的是你已经隔离的内部对象变量,防止在调试和编写代码时读取其值的可能性......
这就是我要说的--当你调试一个EA时--你不需要MT的内部变量吗?
同样,在这种情况下,对于交易处理器对象--如果你正在调试,例如,在你的TS中下订单的方法--为什么你要访问交易处理器的内部变量?
安德烈甚至比彼得或桑桑尼茨更有临床经验,你这是在浪费你的时间。
年轻人需要接受教育。
此外,也许我的对手们所说的有一个合理的理由。如果我有,比如说,像彼得这样的记忆,我可能也不会去理会巴解组织。
在其他地方也是如此--如果需要一些数据--那么这个块就必须提供相应的接口。
这就是我的意思...而不是仅仅看到所需变量的值,你必须考虑如何给它附加一个合适的接口,然后再把它解开。:)
它看起来像一个为受虐狂而设的编程活动 :)
是的......你不禁要问,这里面有什么呢 :)我们的想法是要有一个足够的编程语言,以最小的手势方便调试和编写代码,但这里我们有一个完全相反的情况......
这不是一个'相反的情况'。诚然,OOP需要一些额外的工作。然而,这在支持和系统修改的便利性方面得到了补偿。
在这里,再次回到贸易处理器--它是在许多TS中编写和使用的。这是它的内部结构与TS的隔离,只通过一个虚拟接口工作,可以不考虑里面有什么变量,它们等于什么。如果检测到错误,它们将在处理器内部,有必要在一个真正的类中修复它们,而不影响TS类。如果错误是在TS本身,它不会影响交易处理器的变量。
封装实际上是一种非常有用的技术。
是的......你不禁要问,这里面到底有什么呢 :)我们的想法是要有一个足够的编程语言,以最小的手势方便调试和编写代码,但这里我们有一个完全相反的情况......
调试恰恰是通过每个类的责任划分来促进的:每个类对自己的变量集负责。其他阶层无权改变他们的价值观。因此,大多数问题在编译阶段就已经被消除了。而从程序的任何地方访问变量,可以比作一艘船上的一打方向盘。
年轻人需要接受教育。
此外,也许我的对手所说的也有合理的依据。比如说,如果我有彼得这样的记忆力,我也不会去理会OOP。
1.通过使用OOPs,你的顾问的利润率提高了多少?
2.你的顾问的利润率因使用OOP而下降了多少?
这就是我的意思...而不是仅仅看到所需变量的值,你必须考虑如何给它附加一个合适的接口,然后再把它解开。:)
它看起来像一个为受虐狂而设的编程活动 :)
你看,在这个问题上,彼得给你看了他的一个结构,不是最大的那个。
你能轻易地弄明白吗?
这种非常的 "受虐狂 "恰恰允许你,首先,不进入工作代码,不破坏它。其次,它允许你立即设计 系统结构,以便你能在程序的相应块中提供必要的数据。
是的,的确,有些情况下,你突然意识到几乎不可能得到所需的数据。它们隐藏在几个虚拟界面后面。然而,这种情况清楚地表明,系统最初的设计是错误的,它没有规定传输这种数据。这种情况确实非常令人不快。我们要么匆忙地以附加接口的形式建立 "拐杖",要么重组整个系统。 嗯......这促使程序员更仔细地思考系统结构。
如果你在讨论的本质上少一些情感和反思性,多一些具体性--你就不值得了。:)
这个讨论已经没有实质内容了。你从根本上说是在忽悠和装糊涂。
如果版主认为最后几页与主题和一般的编程无关而将其关闭--这将是一个罕见的情况,我将支持他的行动。
1.通过使用OOPs,你的EA的利润率提高了多少?
2.使用OOP后,你们顾问公司的失败率降低了多少?
1.不知道是多少。盈利能力并不取决于OOP。
2.在我看来,是一个数量级的(十倍)。但OOP的主要收获是在代码支持方面。现在我非常快地弄清了我一年或更久以前写的代码。我清楚地记得,我是如何理解我早期的ANSI C程序的,纯粹是程序化风格。这就更难了。
调试恰恰是通过每个类的责任划分来促进的:每个类对自己的变量集负责。其他阶层无权改变他们的价值观。因此,大多数问题在编译阶段就已经被消除了。而从程序的任何地方访问变量,可以比作船上的一打方向盘。
我不明白为什么我在工作中从来没有遇到过这样的事情。为什么在一个不太大的程序中,一个开发者会出现变量访问定界的问题?会有100个开发人员,每个人都在编写100个函数。理论上,它可以被发明出来。但实际上,编程发展到OOP已经有近40年的时间了,堆积如山的代码已经写完了,从来没有听说过类似的事情。