MQL5中的OOP问题 - 页 51

新评论
 
Sergey Dzyublik:

1.事实证明，树形数据结构 都是来自邪恶的。
2.可怜的C++，class == private struct，怎么办，我们也许应该放弃结构和类。
3.这就对了：没有模式，没有通过指针排序，没有节省内存，特别是对大对象而言...
4.我们不应该忘记禁止使用接口和模板函数，否则你将不明白你正在处理的是什么对象--这是多么可怕的事情......

1.不，为什么不呢？如果你说的是树形（或链接列表）节点改变它们的状态，这只是一个安排访问该状态的问题。 就代码功能而言，用户不应该访问节点的状态。所有跨节点的迭代都应该通过访问树本身来完成： tree.NextNode(myNode) 或 tree.Parent(myNode)，而不是myNode.NextNode() 或 myNode.Parent()。

也就是说，被改变的状态不应该是公开的。

2.看，我采取了夏普结构，因为不可能采取参考/指针的方式。也就是说，一切都在编译器的控制之下。 如果没有这样的控制，你必须提供个人控制，例如，通过对类的适当命名。我们这样说吧。

class MyClass_mut; // mutable

class MyClass_immut; // 不变的

3, 4. 你错了，一切都可以实现 ) 你只是不应该认为所有对象的数据都必须通过堆栈复制。 在一般情况下，一个对象包含一个指向数据的内部指针。 这就像智能指针一样。 只有在可改变对象的情况下，这个指针必须更加智能)

 
Aleksey Mavrin:

德米特里，我向你保证，我也很乐意嘲笑你，好吧，我喜欢这个行业）但在这种情况下，你已经夸大了，甚至特别好笑。

你只是真的糊涂了--拍摄不等于物体复制，我已经向你指出了。

如果不清楚，让我举个例子为你解释--你有1000字节的对象，你需要200个快照，那么为什么要复制800个，特别是如果你有数百万个保存的快照。

p/s/ 而在一般情况下。难道人们没有意识到，模式只是解决一个基本的典型问题的初级例子。而事实上，这些任务并不简单，而是更加复杂。为了解决实际问题，这些模式是必要的，但往往不是纯粹的书本形式，而是适应特定的任务，可能相互结合，可能增加一些即兴创作，如果任务允许，有时表现为简化，反之则是实现 "加权"。

再说一遍，为什么需要封装和接口--如果你的智商低于Wasserman，或者你没有参加过真正的项目，可能就无法理解，因为项目的不同部分是由不同的人同时改变的，不遵循OOPD的基本原则就会在捕捉bug上付出巨大的代价。真的，为什么要为市场的专家顾问盖章而做这一切？）

你把解决编程任务的算法与所谓的、时下流行的、完全与OOP有关的"设计模式"混为一谈。而且你还混淆了很多其他的东西，阅读时也不专心。稍早我写道--使用结构。但是，如果你读过那篇文章，而我没有写过复制整个班级的功能，你就会明白，我们是成年人，没有必要用不必要的结构做额外的工作，而我们应该成熟地做所有的事情--只要提供复制整个班级的能力。

 
Aleksey Mavrin:

...

再说一遍，为什么需要封装和接口--如果你的智商低于Wasserman，或者你没有参加过真正的项目，这可能是无法理解的，因为一个项目的不同部分会同时被不同的人改变，不遵守OOPD的基本原则会带来巨大的捕捉错误的成本。真的，为什么要为市场上的专家顾问盖章而做这一切？）

.

谢尔盖-迪尤布利 克。

...
4.我不能忘记禁止使用接口和模板函数，否则你将不明白你正在处理的是什么对象--多么恐怖啊......

某时某地读到什么是接口，为什么需要接口。

-

哦，还有这个...你是否真的把保存一个对象的全部或部分字段的能力与撤销/重做功能混为一谈？让我们来谈谈Photoshop，你知道它是怎么做的。

-

而你们中的哪一个人都在给我发巧克力和电子邮件？

-

你到底有什么问题？我是否动摇了你对神圣模式的信仰基础？

 
一个自学成才的业余爱好者，除了mql，什么都没见过，教男人怎么写程序，进来看看很有意思)
 

正在翻阅这里的书柜。

很好的发现："人工智能和专家系统简介与BASIC中的插图 "1987年。 其中一章 "面向对象编程的概念"。

相信我--一切都没有改变......。

 
Maxim Kuznetsov:

正在翻阅这里的书柜。

很好的发现："人工智能和专家系统简介与BASIC中的插图 "1987年。 其中一章 "面向对象编程的概念"。

相信我--一切都没有改变......。

很多事情都变了，那时候还没有一个神圣的设计模式 的信徒的教堂。而那个时候，C++受害者俱乐部也还没有形成。

 
Dmitry Fedoseev:

很多事情都变了，那时候还没有神圣的设计模式的信徒的教堂。

那时候还没有圣人设计崇拜者的教堂。现在也不存在了，你可以在Runet上搜索，如果Runet上关于模式的问题非常少，说明它不作为一个群体存在，学生的 "书本 "问题不算数。

他们没有什么可读的，但当你想扩展一个项目 时，它是很方便的，一般来说，程序的结构最初是正确的。

 
Dmitry Fedoseev:

很多事情都变了，那时候还没有设计的圣母教堂。

"设计模式"只是一个协议，用同样的名字来称呼经常出现的东西。顺便说一下，这个词来自于建筑学（涉及到雕塑/桥梁/门户/门廊）。

有时类似的事情可以用类似的技术来解决，不一定总是这样......但在事物和方法的相似性上达成一致是很有用的，这样才能相互理解。

但当然，也有人说 "给傻子一个玻璃阴茎，他就会打碎那东西并割伤自己"。

 
Igor Makanu:

这种情况即使现在也不存在，你可以搜索runet，如果runet中关于模式的问题数量非常少，那么它就不作为一个质量存在，学生的 "书本 "问题不算数

没有什么可读的，但当你想扩展一个项目时，它很方便。

它们不包含任何东西。你研究过多少种模式？

 
Dmitry Fedoseev:

没有任何东西被嵌入其中。你研究过多少种模式？

什么叫 "研究"？

如果我读过几个论坛的描述，那么我就有几十个。

如果在MQL中应用，那么，一是策略可行，可以扩展，重构很容易--我可能会为测试人员扔掉所有不必要的东西，使其更快，或者直接去做演示--一般来说，它很方便，很实用

1...444546474849505152535455565758...96
新评论