我的方法。核心是引擎。 - 页 18

 
jdjahfkahjf:
让我猜猜,又是关于OOP的争论。

不,当我们在讨论休闲编程的时候,我把毯子拖到了OOP上,话题发起人还在坚持!他写道,所有的东西都可以放在脑子里--好吧,休闲编程))。

 

核心引擎

 
Igor Makanu:

休闲编程)))。

休闲编程 :)

 
jdjahfkahjf:

休闲编程 :)

也许你是对的,我记得这个词--几个月前在另一个论坛上有人自称是休闲程序员,我甚至试图澄清它可能意味着什么,我对休闲这个词的认识只与安卓游戏--"祖玛 "有关,结果发现它是一个随机编程的程序员--从偶尔到偶尔))

 
Vasiliy Sokolov:

OOP是一种非常灵活的方法论,所以它没有任何像 "内核 "概念那样的先验观念。然而,这里所说的内核模型完全可以用OOP来构建。因此,这种说法并不完全正确。

不,OOP与此完全没有关系。内核是Unix,我们围绕内核组装一切;shell是像Windows一样的一切,我们剥去多余的东西,用其余的东西工作。一般来说,这是关于一个操作系统。

 
jdjahfkahjf:

卡伊恩编程 :)

Cajual,别担心。

 
Реter Konow:

OOP让我反感的是写代码的僵硬格式。正如你所看到的,我倾向于制作大型的数据表格,并发现它非常实用。在OOP中,我必须遵守一堆规则,我个人认为这很有局限性。

简而言之,我用不同的OOP来编程。我自己的。规则很少,自由度很大。功能本身被堆积成大块,而数据被组织在内核中。我甚至没有专门思考过他们的结构。一切都在自行发展。在直觉的层面上。

彼得,这些规则是你自己需要的。这就是为什么他们要 "僵化 "你。这样,你就不会不小心搞砸,陷入你不应该陷入的东西。事实上,OOP风格是 "道路规则"--当然,它们限制了司机。而在一个有三个院子的村子里--没有人看他们,这更容易和更快(更有效率)。然而,在一个大城市,情况恰恰相反--正是交通规则促成了最有效的交通连接。 这与AOP的情况相同。它们是允许你以最有效的方式建立大型复杂系统的规则。

在你的系统中--只是还没有任何变化,它的使用非常有限,不需要修改。这就是为什么你可以把它放在你的脑子里。如果系统得到了用户,需要修改,那也没关系--缺乏控制和封装会有相当大的压力。

其他方面--没有区别,OOP和你的风格(如前所述,你也有程序化风格--也有同样的缺陷--全局变量,缺乏类型控制,等等)在其他方面都很接近。

为了捍卫你的风格,你需要证明唯一的一点--把整个系统保存在一个巨大的全局数组中,可以任意访问,比把程序分解成一堆嵌套在继承链中的小部分,具有多态的访问,并通过封装隐藏。

顺便说一句,论坛上有一些人不喜欢继承权--我想他们可能支持你。

 

相对于Peter的方法,使用OOP 的另一个好处是。在OOP中,程序员不需要基类的源代码,也不需要了解它是如何工作的。 为了扩展或改变基类的功能,只需创建这个类的继承者即可。

如果你使用彼得的方法,程序员需要了解所有的长代码,如果没有源代码,你将不得不从头开始写。

 
Georgiy Merts:

其他方面--没有区别,OOP和你的风格(正如已经提到的,你有一个程序化风格--也有同样的缺点--全局变量,缺乏类型控制,等等)在其他方面很接近。

我可能是错的,而且我懒得去搜,但是程序性风格意味着一个程序(函数)的逻辑完整性--从源头上 "拧开 "它并在其他代码中使用它,即内置的MQL函数将数据作为参数并返回结果....。而在这里,Piotr已经双脚落地,))))。- 通过全局声明的变量进行交换,降低了代码的可移植性,并允许出现难以跟踪的错误;)

 

好的。就说我被说服了吧。

  1. OOP对于一个程序员团队在一个大型项目 上的工作是必要的。
  2. OOP对程序进行组织和结构化。
  3. OOP提供了很多工具来提高编程能力。

原则上,我对这一切已经了解了很久。我也同意这一点。然而,与此同时,我更喜欢我自己的方法。为什么?

有一个特别的原因。

方案开发。

//---------------------------------------

采用OOP和我的方法,程序的开发速度会有多快?哪种方法更有利于机制的增长和复杂化?

我的结论是,我的方法+代码中的母语(60%为俄语,40%为英语),给程序带来了最大的快速增长

准确地说,这种快速增长正是我所需要的。不挖掘细节。而不仅仅是在每一行代码上徘徊。这不是一个专业的方法。

我希望这个程序能够迅速发展,变得更加复杂。该机制将被创建,以履行分配给它们的职能。快速和简单。

这样,你就可以用几行代码来增加新的功能。

我的方法在解决这一特殊任务方面优于OOP。