来自一个 "傻瓜 "的问题 - 页 128 1...121122123124125126127128129130131132133134135...277 新评论 TheXpert 2012.04.03 10:42 #1271 mql5: 我们不会忘记;) 你最好用多重继承来代替运算符重载。这将是更有用的。 Ilyas 2012.04.03 10:58 #1272 TheXpert: 与其说是重载运算符,不如说是多重继承。这将是更有用的。 不幸的是,这并不是计划中的。目前,我们只考虑从结构中继承类的可能性。 Vladimir Kustikov 2012.04.03 11:36 #1273 TheXpert: 你最好实现多重继承而不是运算符重载。这将是更有用的。写得很好--让它发生吧 :)这正是多重继承的作用。一周前,我参加了 "多重继承与聚合 "的讨论,聚合获得了令人信服的胜利。 TheXpert 2012.04.03 11:47 #1274 Vladix:一周前参加了 "多重继承与聚合 "的讨论,聚合获得了令人信服的胜利。嗯,是的,为每个实现类写一公里的封装代码要好得多,也更有效率。而且速度也快得多。特别是在接口有十几个的情况下。但请把链接扔给我,我将在闲暇时研究它。 Vladimir Gomonov 2012.04.03 12:00 #1275 mql5: 不幸的是,这并不是计划中的。目前,我们只考虑从结构中继承类的可能性。 而且,指向结构的指针不一定非得是动态的--主要是索引阵列 可以被排序,而不是结构本身。 // 在许多情况下,用类代替结构是不可取的。它们是经济的(没有虚拟方法表),包含 "坚实 "的数据。 Документация по MQL5: Основы языка / Переменные www.mql5.com Основы языка / Переменные - Документация по MQL5 Vladimir Kustikov 2012.04.03 12:02 #1276 TheXpert:是的,为每个实现类写一公里的封装代码要好得多,也更有效率。但请把链接扔给我,我将在闲暇时研究它。关于包装器--我同意,但大多数情况下,它也作为一个前端或适配器,即它修改了聚合类的接口。我不能给你链接,那是一个内部的Skype讨论,大约有三十个感兴趣的人。 TheXpert 2012.04.03 12:18 #1277 Vladix:关于包装器--我同意,但更多的时候,它也是作为一个façade或适配器,即它修改了被聚合的类的接口。这取决于你如何看待它。可以说,这种情况下的聚合是一个拐杖,因为从逻辑和编码的角度来看,多重继承更透明和方便。我可以给你一个例子,说明你们公司是如何处理菱形等级制度的吗? Vladimir Kustikov 2012.04.03 12:49 #1278 TheXpert:这取决于你如何看待它。你可以说,在这种情况下,聚合是一个拐杖,因为多继承在逻辑上和编码上都更透明和方便。你能举个例子说明你的公司是如何处理菱形层次结构的吗?如果我没弄错的话,层次结构只是使用多重继承的一个产物。你能举出任何现实生活中遇到的需要建立和实施菱形层次结构的例子吗? Mykola Demko 2012.04.03 12:56 #1279 Vladix:如果我没弄错的话,菱形层次结构只是使用多重继承的一个产物。你能举出你生活中遇到的需要建立和实施菱形层次结构的例子吗?一个人有一条胳膊、一条腿和各种器官,它们是由细胞构成的,而细胞是由原子构成的,原子的集合是有限的,但它们的集合是巨大的。所有的器官都有不同的用途,但他们都是人。人们是不同的,可以有不同的职业等。那些我们从一个细胞遗传的集合开始,那些汇聚成一个类别,然后又分化成器官,又汇聚成人类的一个类别,又分化成职业。 TheXpert 2012.04.03 13:19 #1280 Vladix:如果我没弄错的话,菱形层次结构只是使用多重继承的一个产物。不,它是设计的 产物。这并不取决于语言工具的使用。你能举出一些现实生活中的例子,说明你何时需要建立和实施菱形层次结构?一开始没有,但我已经不止一次地使用它。而且实际上没有任何选择。如果你问我,写拐杖包装纸本身就是一个有分量的论据。 1...121122123124125126127128129130131132133134135...277 新评论
我们不会忘记;)
与其说是重载运算符,不如说是多重继承。这将是更有用的。
你最好实现多重继承而不是运算符重载。这将是更有用的。
写得很好--让它发生吧 :)这正是多重继承的作用。
一周前,我参加了 "多重继承与聚合 "的讨论,聚合获得了令人信服的胜利。
一周前参加了 "多重继承与聚合 "的讨论,聚合获得了令人信服的胜利。
嗯,是的,为每个实现类写一公里的封装代码要好得多,也更有效率。而且速度也快得多。
特别是在接口有十几个的情况下。
但请把链接扔给我,我将在闲暇时研究它。
不幸的是,这并不是计划中的。目前,我们只考虑从结构中继承类的可能性。
而且,指向结构的指针不一定非得是动态的--主要是索引阵列 可以被排序,而不是结构本身。
// 在许多情况下,用类代替结构是不可取的。它们是经济的(没有虚拟方法表),包含 "坚实 "的数据。
是的,为每个实现类写一公里的封装代码要好得多,也更有效率。
但请把链接扔给我,我将在闲暇时研究它。
关于包装器--我同意,但大多数情况下,它也作为一个前端或适配器,即它修改了聚合类的接口。
我不能给你链接,那是一个内部的Skype讨论,大约有三十个感兴趣的人。
关于包装器--我同意,但更多的时候,它也是作为一个façade或适配器,即它修改了被聚合的类的接口。
这取决于你如何看待它。可以说,这种情况下的聚合是一个拐杖,因为从逻辑和编码的角度来看,多重继承更透明和方便。
我可以给你一个例子,说明你们公司是如何处理菱形等级制度的吗?
这取决于你如何看待它。你可以说,在这种情况下,聚合是一个拐杖,因为多继承在逻辑上和编码上都更透明和方便。
你能举个例子说明你的公司是如何处理菱形层次结构的吗?
如果我没弄错的话,层次结构只是使用多重继承的一个产物。
你能举出任何现实生活中遇到的需要建立和实施菱形层次结构的例子吗?
如果我没弄错的话,菱形层次结构只是使用多重继承的一个产物。
你能举出你生活中遇到的需要建立和实施菱形层次结构的例子吗?
一个人有一条胳膊、一条腿和各种器官,它们是由细胞构成的,而细胞是由原子构成的,原子的集合是有限的,但它们的集合是巨大的。
所有的器官都有不同的用途,但他们都是人。人们是不同的,可以有不同的职业等。
那些我们从一个细胞遗传的集合开始,那些汇聚成一个类别,然后又分化成器官,又汇聚成人类的一个类别,又分化成职业。
如果我没弄错的话,菱形层次结构只是使用多重继承的一个产物。
不,它是设计的 产物。这并不取决于语言工具的使用。
你能举出一些现实生活中的例子,说明你何时需要建立和实施菱形层次结构?
一开始没有,但我已经不止一次地使用它。而且实际上没有任何选择。
如果你问我,写拐杖包装纸本身就是一个有分量的论据。