结构规则。 学习如何构建方案,探索可能性、错误、解决方案等。 - 页 3 12345678910...20 新评论 Alexandr Bryzgalov 2013.07.22 14:13 #21 Urain:来吧,我根本没有任何模型,然后我开始用程序,然后转到对象模型。而一般来说,默认情况下,MQ给了我们一个基于事件的模型。我们最初得到的是一切发生的事件。我们是在谈论mq5吗?所以我们说的是同一件事。 Vasiliy Sokolov 2013.07.22 14:16 #22 MetaDriver: 来自名为 "错误、缺陷、问题"的分支。 设计之初的一个非常典型的问题:如何在程序中组织(结构化)事件处理,以便它(程序)可以进一步发展,同时将已经完成的事情的返工降到最低。 你想讨论选择吗? 这是一个更为全球性的问题,它不仅仅是组织一个合格的活动模式。这在很大程度上取决于语言本身。不幸的是,MQL5的语言手段是上世纪80年代的水平。现代编程标准已经远离了最初的OOP编程原则。今天,分解优于继承,多态性由接口级的横向非层次链接来保证,代码重用由丰富的标准库集合、分解式设计和透明地将第三方程序集纳入项目来保证。 Mykola Demko 2013.07.22 14:21 #23 C-4: 一般来说,这是一个更具全球性的问题,不仅仅是组织一个好的活动模式。这在很大程度上取决于语言本身。不幸的是,MQL5的语言手段是上世纪80年代的水平。现代的编程标准已经远离了最初的OOP编程原则。如今,分解优于继承,多态性由接口级的横向非层次链接来保证,代码重用由丰富的标准库集合、分解设计和透明地将第三方构建纳入项目来保证。 你认为哪种语言是榜样(在现代性和实用性方面)? Vasiliy Sokolov 2013.07.22 14:24 #24 Urain:是否有任何文献资料,比如说?特别是在这个话题上。 Vasiliy Sokolov 2013.07.22 14:30 #25 Urain: 你认为哪种语言是榜样(在现代性和可用性方面)?Java/C#这甚至不是因为我的偏见(尽管我不是没有偏见),而是因为这些语言是编程技术长期发展的最终产物。它们是在我们这个时代创造的,是基于前人的经验。 Vasiliy Sokolov 2013.07.22 14:45 #26 在编写一个大型项目 之前,最好是建立一个明确的既定基础设施来支持项目。一个备份和安全系统。一个版本控制系统。项目的文件系统(如果项目是自我记录的,那就很好)。一个针对单个模块和整个项目的测试系统。 Vladimir Gomonov 2013.07.22 14:51 #27 Urain:是否有任何文献资料,比如说?当然是有的。 // 关于文学:让我们分享文学资源。 但我们不要忘记,现场交流有时比书本(甚至是好书)更有效地促进学习。--这本书一度非常有帮助(90年代初)。B.Liskov, J.Gatag."在软件开发中使用抽象和规范"。从中,我很好地学习了面向对象编程的要点,这不是把程序切割成方便的 "立方体 "的额外可能性--这只是一个额外的附带便利。 主要的一点是数据抽象。sanyooooook: 你用面向对象的方式思考,我用功能化的方式思考 ) 让我用几句话解释一下。 1.程序(算法)抽象是函数式编程的一个特点。 抽象的实体是程序(函数)。它允许将执行一个动作或计算的请求与它的实施分开。功能代码被隔离成一个单独的块(程序、函数),这个代码通过形式/实际参数的解耦来引用(这是程序性方法的本质和主要特征)。当需要改变计算或行动的方式(算法)时(如写入文件),程序能够保持不变。 但是,如果一个程序需要改变任何基本的数据结构(例如全局数组),它就需要重写很多处理这些数据的程序。-- 这是程序化编程风格的一个基本限制。2)数据抽象--将基本数据结构(连同对它们的基本操作)封装成独立的实体("类"),遵守基本规则:永远不要直接引用它们(封装的数据),而只能通过同一类别的功能,专门为它们创建("接口")。 因此,实现了数据存储形式与处理这些数据的方式的抽象。有一个前所未有的机会(在程序性编程中)--开发一个程序而不用事先担心数据表示的方式。 由于数据是通过一个标准的不变的接口访问的,你可以在 项目开发的任何阶段 改进数据表示的方式,这种改变不需要改变项目的其他部分。 在程序性编程中,这是不可能的--基本数据结构严格决定了它们的处理方式。 Alib.ru - Заказ книги у BS-ivanhoe www.alib.ru Vasiliy Sokolov 2013.07.22 14:58 #28 sanyooooook:在编写程序之前,也有人教我在纸上画草图,这是一种简化的algo语言,但我一直不习惯它。 现在,没有一个正常的程序员会画方框图。这都是理论上的废话,是为教育学童而设计的,但不适合在实际项目 中工作。 Mykola Demko 2013.07.22 15:06 #29 C-4: 现在,没有一个正常的程序员会画流程图。这些都是理论上的废话,旨在教育学童,但不适合在实际项目中工作。 我同意,流程图很烂,但对于开发来说,我还是用纸,画各种人等,把抽象的东西可视化。这就是为什么编辑部对我来说很拥挤(他们有一切的标准)。 Vasiliy Sokolov 2013.07.22 15:06 #30 Urain:我在纸上画画,这对我来说更方便,有时需要多达50张纸,直到出现一个清晰的结构。当然,你可以使用特殊的编辑器,但他们中的每一个对我来说都是不舒服的(有限的),不可能实现幻想的飞行,总之他们拖慢了工作。而如果在项目 中间,甚至接近项目 结束时,客户会突然改变,你的清晰结构会发生什么。原始要求的5%。原始要求的10%。原始要求的25%。这是一个很好的测试,看看你的项目对变化的准备程度和适应能力。在实践中,你总是要处理初始需求的变化。因此,最好从 "提供一切 "的范式完全转向 "任务-解决方案 "的范式。 12345678910...20 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
来吧,我根本没有任何模型,然后我开始用程序,然后转到对象模型。
而一般来说,默认情况下,MQ给了我们一个基于事件的模型。我们最初得到的是一切发生的事件。
我们是在谈论mq5吗?
所以我们说的是同一件事。
来自名为 "错误、缺陷、问题"的分支。
设计之初的一个非常典型的问题:如何在程序中组织(结构化)事件处理,以便它(程序)可以进一步发展,同时将已经完成的事情的返工降到最低。
你想讨论选择吗?
一般来说,这是一个更具全球性的问题,不仅仅是组织一个好的活动模式。这在很大程度上取决于语言本身。不幸的是,MQL5的语言手段是上世纪80年代的水平。现代的编程标准已经远离了最初的OOP编程原则。如今,分解优于继承,多态性由接口级的横向非层次链接来保证,代码重用由丰富的标准库集合、分解设计和透明地将第三方构建纳入项目来保证。
是否有任何文献资料,比如说?
特别是在这个话题上。
你认为哪种语言是榜样(在现代性和可用性方面)?
Java/C#
这甚至不是因为我的偏见(尽管我不是没有偏见),而是因为这些语言是编程技术长期发展的最终产物。它们是在我们这个时代创造的,是基于前人的经验。
在编写一个大型项目 之前,最好是建立一个明确的既定基础设施来支持项目。
是否有任何文献资料,比如说?
当然是有的。
// 关于文学:让我们分享文学资源。 但我们不要忘记,现场交流有时比书本(甚至是好书)更有效地促进学习。
--
这本书一度非常有帮助(90年代初)。
B.Liskov, J.Gatag."在软件开发中使用抽象和规范"。
从中,我很好地学习了面向对象编程的要点,这不是把程序切割成方便的 "立方体 "的额外可能性--这只是一个额外的附带便利。 主要的一点是数据抽象。
你用面向对象的方式思考,我用功能化的方式思考 )
1.程序(算法)抽象是函数式编程的一个特点。 抽象的实体是程序(函数)。它允许将执行一个动作或计算的请求与它的实施分开。功能代码被隔离成一个单独的块(程序、函数),这个代码通过形式/实际参数的解耦来引用(这是程序性方法的本质和主要特征)。当需要改变计算或行动的方式(算法)时(如写入文件),程序能够保持不变。
但是,如果一个程序需要改变任何基本的数据结构(例如全局数组),它就需要重写很多处理这些数据的程序。-- 这是程序化编程风格的一个基本限制。
2)数据抽象--将基本数据结构(连同对它们的基本操作)封装成独立的实体("类"),遵守基本规则:永远不要直接引用它们(封装的数据),而只能通过同一类别的功能,专门为它们创建("接口")。 因此,实现了数据存储形式与处理这些数据的方式的抽象。有一个前所未有的机会(在程序性编程中)--开发一个程序而不用事先担心数据表示的方式。 由于数据是通过一个标准的不变的接口访问的,你可以在 项目开发的任何阶段 改进数据表示的方式,这种改变不需要改变项目的其他部分。 在程序性编程中,这是不可能的--基本数据结构严格决定了它们的处理方式。
在编写程序之前,也有人教我在纸上画草图,这是一种简化的algo语言,但我一直不习惯它。
现在,没有一个正常的程序员会画流程图。这些都是理论上的废话,旨在教育学童,但不适合在实际项目中工作。
我在纸上画画,这对我来说更方便,有时需要多达50张纸,直到出现一个清晰的结构。当然,你可以使用特殊的编辑器,但他们中的每一个对我来说都是不舒服的(有限的),不可能实现幻想的飞行,总之他们拖慢了工作。
而如果在项目 中间,甚至接近项目 结束时,客户会突然改变,你的清晰结构会发生什么。
这是一个很好的测试,看看你的项目对变化的准备程度和适应能力。在实践中,你总是要处理初始需求的变化。因此,最好从 "提供一切 "的范式完全转向 "任务-解决方案 "的范式。