我的方法。核心是引擎。 - 页 18 1...111213141516171819202122232425...184 新评论 Igor Makanu 2018.12.06 21:52 #171 jdjahfkahjf:让我猜猜,又是关于OOP的争论。不,当我们在讨论休闲编程的时候,我把毯子拖到了OOP上,话题发起人还在坚持!他写道,所有的东西都可以放在脑子里--好吧,休闲编程))。 Maxim Kuznetsov 2018.12.06 22:17 #172 核心引擎 jdjahfkahjf 2018.12.06 22:22 #173 Igor Makanu:休闲编程)))。休闲编程 :) Igor Makanu 2018.12.06 22:28 #174 jdjahfkahjf:休闲编程 :)也许你是对的,我记得这个词--几个月前在另一个论坛上有人自称是休闲程序员,我甚至试图澄清它可能意味着什么,我对休闲这个词的认识只与安卓游戏--"祖玛 "有关,结果发现它是一个随机编程的程序员--从偶尔到偶尔)) Алексей Тарабанов 2018.12.06 23:07 #175 Vasiliy Sokolov:OOP是一种非常灵活的方法论,所以它没有任何像 "内核 "概念那样的先验观念。然而,这里所说的内核模型完全可以用OOP来构建。因此,这种说法并不完全正确。不,OOP与此完全没有关系。内核是Unix,我们围绕内核组装一切;shell是像Windows一样的一切,我们剥去多余的东西,用其余的东西工作。一般来说,这是关于一个操作系统。 Алексей Тарабанов 2018.12.06 23:08 #176 jdjahfkahjf:卡伊恩编程 :)Cajual,别担心。 Georgiy Merts 2018.12.07 05:57 #177 Реter Konow:OOP让我反感的是写代码的僵硬格式。正如你所看到的,我倾向于制作大型的数据表格,并发现它非常实用。在OOP中,我必须遵守一堆规则,我个人认为这很有局限性。 简而言之,我用不同的OOP来编程。我自己的。规则很少,自由度很大。功能本身被堆积成大块,而数据被组织在内核中。我甚至没有专门思考过他们的结构。一切都在自行发展。在直觉的层面上。彼得,这些规则是你自己需要的。这就是为什么他们要 "僵化 "你。这样,你就不会不小心搞砸,陷入你不应该陷入的东西。事实上,OOP风格是 "道路规则"--当然,它们限制了司机。而在一个有三个院子的村子里--没有人看他们,这更容易和更快(更有效率)。然而,在一个大城市,情况恰恰相反--正是交通规则促成了最有效的交通连接。 这与AOP的情况相同。它们是允许你以最有效的方式建立大型复杂系统的规则。 在你的系统中--只是还没有任何变化,它的使用非常有限,不需要修改。这就是为什么你可以把它放在你的脑子里。如果系统得到了用户,需要修改,那也没关系--缺乏控制和封装会有相当大的压力。 其他方面--没有区别,OOP和你的风格(如前所述,你也有程序化风格--也有同样的缺陷--全局变量,缺乏类型控制,等等)在其他方面都很接近。 为了捍卫你的风格,你需要证明唯一的一点--把整个系统保存在一个巨大的全局数组中,可以任意访问,比把程序分解成一堆嵌套在继承链中的小部分,具有多态的访问,并通过封装隐藏。 顺便说一句,论坛上有一些人不喜欢继承权--我想他们可能支持你。 Vitalii Ananev 2018.12.07 06:57 #178 相对于Peter的方法,使用OOP 的另一个好处是。在OOP中,程序员不需要基类的源代码,也不需要了解它是如何工作的。 为了扩展或改变基类的功能,只需创建这个类的继承者即可。 如果你使用彼得的方法,程序员需要了解所有的长代码,如果没有源代码,你将不得不从头开始写。 Igor Makanu 2018.12.07 07:28 #179 Georgiy Merts:其他方面--没有区别,OOP和你的风格(正如已经提到的,你有一个程序化风格--也有同样的缺点--全局变量,缺乏类型控制,等等)在其他方面很接近。我可能是错的,而且我懒得去搜,但是程序性风格意味着一个程序(函数)的逻辑完整性--从源头上 "拧开 "它并在其他代码中使用它,即内置的MQL函数将数据作为参数并返回结果....。而在这里,Piotr已经双脚落地,))))。- 通过全局声明的变量进行交换,降低了代码的可移植性,并允许出现难以跟踪的错误;) Реter Konow 2018.12.07 08:55 #180 好的。就说我被说服了吧。 OOP对于一个程序员团队在一个大型项目 上的工作是必要的。OOP对程序进行组织和结构化。OOP提供了很多工具来提高编程能力。原则上,我对这一切已经了解了很久。我也同意这一点。然而,与此同时,我更喜欢我自己的方法。为什么? 有一个特别的原因。 方案开发。 //--------------------------------------- 采用OOP和我的方法,程序的开发速度会有多快?哪种方法更有利于机制的增长和复杂化? 我的结论是,我的方法+代码中的母语(60%为俄语,40%为英语),给程序带来了最大的快速增长。 准确地说,这种快速增长正是我所需要的。不挖掘细节。而不仅仅是在每一行代码上徘徊。这不是一个专业的方法。 我希望这个程序能够迅速发展,变得更加复杂。该机制将被创建,以履行分配给它们的职能。快速和简单。 这样,你就可以用几行代码来增加新的功能。 我的方法在解决这一特殊任务方面优于OOP。 1...111213141516171819202122232425...184 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
不,当我们在讨论休闲编程的时候,我把毯子拖到了OOP上,话题发起人还在坚持!他写道,所有的东西都可以放在脑子里--好吧,休闲编程))。
核心引擎
休闲编程)))。
休闲编程 :)
休闲编程 :)
也许你是对的,我记得这个词--几个月前在另一个论坛上有人自称是休闲程序员,我甚至试图澄清它可能意味着什么,我对休闲这个词的认识只与安卓游戏--"祖玛 "有关,结果发现它是一个随机编程的程序员--从偶尔到偶尔))
OOP是一种非常灵活的方法论,所以它没有任何像 "内核 "概念那样的先验观念。然而,这里所说的内核模型完全可以用OOP来构建。因此,这种说法并不完全正确。
不,OOP与此完全没有关系。内核是Unix,我们围绕内核组装一切;shell是像Windows一样的一切,我们剥去多余的东西,用其余的东西工作。一般来说,这是关于一个操作系统。
卡伊恩编程 :)
Cajual,别担心。
OOP让我反感的是写代码的僵硬格式。正如你所看到的,我倾向于制作大型的数据表格,并发现它非常实用。在OOP中,我必须遵守一堆规则,我个人认为这很有局限性。
简而言之,我用不同的OOP来编程。我自己的。规则很少,自由度很大。功能本身被堆积成大块,而数据被组织在内核中。我甚至没有专门思考过他们的结构。一切都在自行发展。在直觉的层面上。彼得,这些规则是你自己需要的。这就是为什么他们要 "僵化 "你。这样,你就不会不小心搞砸,陷入你不应该陷入的东西。事实上,OOP风格是 "道路规则"--当然,它们限制了司机。而在一个有三个院子的村子里--没有人看他们,这更容易和更快(更有效率)。然而,在一个大城市,情况恰恰相反--正是交通规则促成了最有效的交通连接。 这与AOP的情况相同。它们是允许你以最有效的方式建立大型复杂系统的规则。
在你的系统中--只是还没有任何变化,它的使用非常有限,不需要修改。这就是为什么你可以把它放在你的脑子里。如果系统得到了用户,需要修改,那也没关系--缺乏控制和封装会有相当大的压力。
其他方面--没有区别,OOP和你的风格(如前所述,你也有程序化风格--也有同样的缺陷--全局变量,缺乏类型控制,等等)在其他方面都很接近。
为了捍卫你的风格,你需要证明唯一的一点--把整个系统保存在一个巨大的全局数组中,可以任意访问,比把程序分解成一堆嵌套在继承链中的小部分,具有多态的访问,并通过封装隐藏。
顺便说一句,论坛上有一些人不喜欢继承权--我想他们可能支持你。
相对于Peter的方法,使用OOP 的另一个好处是。在OOP中,程序员不需要基类的源代码,也不需要了解它是如何工作的。 为了扩展或改变基类的功能,只需创建这个类的继承者即可。
如果你使用彼得的方法,程序员需要了解所有的长代码,如果没有源代码,你将不得不从头开始写。
其他方面--没有区别,OOP和你的风格(正如已经提到的,你有一个程序化风格--也有同样的缺点--全局变量,缺乏类型控制,等等)在其他方面很接近。
我可能是错的,而且我懒得去搜,但是程序性风格意味着一个程序(函数)的逻辑完整性--从源头上 "拧开 "它并在其他代码中使用它,即内置的MQL函数将数据作为参数并返回结果....。而在这里,Piotr已经双脚落地,))))。- 通过全局声明的变量进行交换,降低了代码的可移植性,并允许出现难以跟踪的错误;)
好的。就说我被说服了吧。
原则上,我对这一切已经了解了很久。我也同意这一点。然而,与此同时,我更喜欢我自己的方法。为什么?
有一个特别的原因。
方案开发。
//---------------------------------------
采用OOP和我的方法,程序的开发速度会有多快?哪种方法更有利于机制的增长和复杂化?
我的结论是,我的方法+代码中的母语(60%为俄语,40%为英语),给程序带来了最大的快速增长。
准确地说,这种快速增长正是我所需要的。不挖掘细节。而不仅仅是在每一行代码上徘徊。这不是一个专业的方法。
我希望这个程序能够迅速发展,变得更加复杂。该机制将被创建,以履行分配给它们的职能。快速和简单。
这样,你就可以用几行代码来增加新的功能。
我的方法在解决这一特殊任务方面优于OOP。