结构规则。 学习如何构建方案，探索可能性、错误、解决方案等。 - 页 3

新评论
 
Urain:

来吧，我根本没有任何模型，然后我开始用程序，然后转到对象模型。

而一般来说，默认情况下，MQ给了我们一个基于事件的模型。我们最初得到的是一切发生的事件。

我们是在谈论mq5吗？

所以我们说的是同一件事。

 
MetaDriver:
来自名为 "错误、缺陷、问题"的分支。

设计之初的一个非常典型的问题：如何在程序中组织（结构化）事件处理，以便它（程序）可以进一步发展，同时将已经完成的事情的返工降到最低。

你想讨论选择吗？

这是一个更为全球性的问题，它不仅仅是组织一个合格的活动模式。这在很大程度上取决于语言本身。不幸的是，MQL5的语言手段是上世纪80年代的水平。现代编程标准已经远离了最初的OOP编程原则。今天，分解优于继承，多态性由接口级的横向非层次链接来保证，代码重用由丰富的标准库集合、分解式设计和透明地将第三方程序集纳入项目来保证。
 
C-4:
一般来说，这是一个更具全球性的问题，不仅仅是组织一个好的活动模式。这在很大程度上取决于语言本身。不幸的是，MQL5的语言手段是上世纪80年代的水平。现代的编程标准已经远离了最初的OOP编程原则。如今，分解优于继承，多态性由接口级的横向非层次链接来保证，代码重用由丰富的标准库集合、分解设计和透明地将第三方构建纳入项目来保证。
你认为哪种语言是榜样（在现代性和实用性方面）？
 
Urain:

是否有任何文献资料，比如说？

特别是在这个话题上。

 
Urain:
你认为哪种语言是榜样（在现代性和可用性方面）？

Java/C#

这甚至不是因为我的偏见（尽管我不是没有偏见），而是因为这些语言是编程技术长期发展的最终产物。它们是在我们这个时代创造的，是基于前人的经验。

 

在编写一个大型项目 之前，最好是建立一个明确的既定基础设施来支持项目。

  • 一个备份和安全系统。
  • 一个版本控制系统。
  • 项目的文件系统（如果项目是自我记录的，那就很好）。
  • 一个针对单个模块和整个项目的测试系统。
 
Urain:

是否有任何文献资料，比如说？

当然是有的。

// 关于文学：让我们分享文学资源。 但我们不要忘记，现场交流有时比书本（甚至是好书）更有效地促进学习。

--

这本书一度非常有帮助（90年代初）。

B.Liskov, J.Gatag."在软件开发中使用抽象和规范"。

从中，我很好地学习了面向对象编程的要点，这不是把程序切割成方便的 "立方体 "的额外可能性--这只是一个额外的附带便利。 主要的一点是数据抽象。

sanyooooook:
你用面向对象的方式思考，我用功能化的方式思考 )
让我用几句话解释一下。

1.程序（算法）抽象是函数式编程的一个特点。 抽象的实体是程序（函数）。它允许将执行一个动作或计算的请求与它的实施分开。功能代码被隔离成一个单独的块（程序、函数），这个代码通过形式/实际参数的解耦来引用（这是程序性方法的本质和主要特征）。当需要改变计算或行动的方式（算法）时（如写入文件），程序能够保持不变。

但是，如果一个程序需要改变任何基本的数据结构（例如全局数组），它就需要重写很多处理这些数据的程序。-- 这是程序化编程风格的一个基本限制。

2）数据抽象--将基本数据结构（连同对它们的基本操作）封装成独立的实体（"类"），遵守基本规则：永远不要直接引用它们（封装的数据），而只能通过同一类别的功能，专门为它们创建（"接口"）。 因此，实现了数据存储形式与处理这些数据的方式的抽象。有一个前所未有的机会（在程序性编程中）--开发一个程序而不用事先担心数据表示的方式。 由于数据是通过一个标准的不变的接口访问的，你可以在 项目开发的任何阶段 改进数据表示的方式，这种改变不需要改变项目的其他部分。 在程序性编程中，这是不可能的--基本数据结构严格决定了它们的处理方式。

 
sanyooooook:

在编写程序之前，也有人教我在纸上画草图，这是一种简化的algo语言，但我一直不习惯它。

现在，没有一个正常的程序员会画方框图。这都是理论上的废话，是为教育学童而设计的，但不适合在实际项目 中工作。
 
C-4:
现在，没有一个正常的程序员会画流程图。这些都是理论上的废话，旨在教育学童，但不适合在实际项目中工作。
我同意，流程图很烂，但对于开发来说，我还是用纸，画各种人等，把抽象的东西可视化。这就是为什么编辑部对我来说很拥挤（他们有一切的标准）。
 
Urain:

我在纸上画画，这对我来说更方便，有时需要多达50张纸，直到出现一个清晰的结构。当然，你可以使用特殊的编辑器，但他们中的每一个对我来说都是不舒服的（有限的），不可能实现幻想的飞行，总之他们拖慢了工作。

而如果在项目 中间，甚至接近项目 结束时，客户会突然改变，你的清晰结构会发生什么。

  • 原始要求的5%。
  • 原始要求的10%。
  • 原始要求的25%。

这是一个很好的测试，看看你的项目对变化的准备程度和适应能力。在实践中，你总是要处理初始需求的变化。因此，最好从 "提供一切 "的范式完全转向 "任务-解决方案 "的范式。

12345678910...20
新评论