MQL5中的OOP问题 - 页 49 1...424344454647484950515253545556...96 新评论 Dmitry Fedoseev 2020.05.16 20:37 #481 而这些疯狂的心理游戏的意义何在?模式的 "目的"(引号,因为......gladiolus)是"在不破坏封装的情况下,固定和保存对象的内部状态"(引号,因为引用)。但你不能没有setState()方法。那么,在这里,封装的节约在哪里呢?要为每个私有字段再写两个方法...是的......很酷,封装被保留了。 而且要诚实,你会在实践中使用这种方法吗?我怀疑这一点。在实践中,你将使它变得明确和透明--例如,一个具有相同字段集的结构和几种保存和恢复的方法。然后,封装将被真正保留下来,只有两个新的方法:保存状态和恢复。 Alexey Navoykov 2020.05.17 03:43 #482 Igor Makanu: 好的,我会保存它,我需要测试工作原理,也许这就是我所寻找的--为测试者和工作中的EA提供一个代码,它可以保存其状态,相反,在测试者中不要在 "额外的手势 "上浪费资源--这种模式的一部分可以由#ifdef -ami涵盖;) 我正试图理解这个带有守门员的crammer的含义,但我看不出有什么特别的用处。 事实上,通过创造副作用,这是不好的编程实践。 当你改变一个对象时,你会改变另一个。因此,代码变得纠缠不清,难以理解。 我认为,最好是努力实现代码的纯净。 有什么能阻止你简单地将一个对象复制到另一个对象中,然后再复制回来呢? 这本质上是同样的事情,只是更正确、更清晰。 如果这个单子同时拥有setters和getters(即允许改变它的状态和读取它),它就相当于在使用全局变量。 而每个程序员都知道,通过改变全局状态来工作是邪恶的。 但单子在某种程度上并不算 ) Igor Makanu 2020.05.17 07:02 #483 Alexey Navoykov: 我正在努力理解这个托管人的含义,但我看不出有什么特别的好处。 事实上,它通过产生副作用,是一种不好的编程实践。 当你改变一个对象时,你会改变另一个对象。因此,代码变得纠缠不清,难以理解。 我认为,最好是努力实现代码的纯净。 比较简单,我正在学习技术上的东西 我习惯于从有限状态机的角度来评估自动化系统的状况,我总是想保留系统状态的 "快照 "作为备用))))。 Alexey Navoykov 2020.05.17 08:21 #484 Igor Makanu: 我更习惯于从有限状态机的角度来评估一个自动化系统的状态,这总是让我希望能够保留一个系统状态的 "铸件 "作为备份))。 只是在我看来,这样的实现方式过于复杂和混乱了。 Igor Makanu 2020.05.17 08:31 #485 Alexey Navoykov: 目的很明确,只是在我看来,它太复杂和混乱了。 唉,人就是这样--在我得到我的踢腿和颠簸之前,我不太可能得到它))。 Dmitry Fedoseev 2020.05.17 09:29 #486 Igor Makanu: 唉,人就是这样--在我得到自己的磕磕碰碰之前,我不太可能得到它)))。 有人研究这些模式并没有错--这很好--大脑锻炼,等等,等等。但仔细一看,它原来是一些无间道的假货,一些把吸食者从现实中拉出来的备忘录,就像通过编写控制台应用程序来学习可视化的BASIC。 研究这些模式是很有趣的,如果只是从学习某人的蟑螂--它们在自然界是什么的角度来看。 而如果我们真的要接近保存一个对象的状态的任务,方法是使一个对象可以复制到另一个对象,无论喜欢哪一个,都是一个简单的方法或重载=重载。而在这之后,你可能不想再封装这个功能了。 Igor Makanu 2020.05.17 10:05 #487 Dmitry Fedoseev: 而如果我们真正对待保存一个对象的状态的任务,方法是使一个对象可以复制到另一个对象,无论喜欢哪一个,不管是通过一个方法还是通过一个重载=。而在这之后,你可能不想再封装这个功能了。 对于现实来说,任何技术系统都可以根据3个基本原则来设计。 - 符合最新标准 - 我们的祖先是这样建造的,没有必要重新发明轮子。 - 我们用粪便和树枝快速建造它,然后我们将重塑它。 ))) 开个玩笑,我有时间阅读和玩弄各种选项,我利用了这一点,也有机会在论坛上快速解释不清楚的地方;) Aleksey Mavrin 2020.05.17 19:57 #488 Alexey Navoykov: 我正在努力理解这个托管人的含义,但我看不出有什么特别的好处。 事实上,它通过产生副作用,是一种不好的编程实践。 当你改变一个对象时,你会改变另一个对象。因此,代码变得纠缠不清,难以理解。 我认为,最好是努力实现代码的纯净。 有什么能阻止你简单地将一个对象复制到另一个对象中,然后再复制回来? 这几乎是同样的事情,但更正确、更清晰。 如果这个单子同时具有设置器和获取器(即允许改变它的状态和读取它),它就相当于处理全局变量。 而每个程序员都知道,通过改变全局状态来工作是邪恶的。 但单子在某种程度上并不算 ) 我想这是一个从未与严肃的大型项目打过交道的程序员的典型观点吧? 请原谅我的直言不讳,但我看不出有什么其他的解释,可以说基本的做法不好 ) Aleksey Mavrin 2020.05.17 20:06 #489 Dmitry Fedoseev:有人研究这些模式并没有错,这很好--大脑锻炼,等等。然后,仔细观察,发现这是某种无间道的假象,某种引诱吸食者远离现实的备忘录,就像通过编写控制台应用程序来学习可视化的BASIC。研究这些模式是很有趣的,如果只是从学习某人的蟑螂--它们在自然界是什么的角度来看。而如果我们真的要接近保存一个对象的状态的任务,方法是使一个对象可以复制到另一个对象,无论喜欢哪一个,都是一个简单的方法或重载=重载。而除此之外,也许封装这一功能的愿望会消失。 Dmitry,在这种情况下,你可能混淆了模式Keeper和Prototype的一些任务,以及它们所有可能的组合和表现形式。第一个快照不一定要复制整个对象,不像Prototype那样。 是的,封装的需求主要表现在有很多人的大型项目 上。对于像这里的大多数任务的玩具,当然是过犹不及) Sergey Dzyublik 2020.05.17 20:45 #490 Alexey Navoykov: 1)我想弄清楚这个监护人的事情有什么意义,但我看不出有什么好处。 2)创造副作用本质上是一种不好的编程实践。 3)当你改变一个对象时,你会改变另一个对象。因此,代码变得纠缠不清,难以理解。 我认为,还是争取代码的纯洁性为好。 4)是什么阻止了你简单地将一个对象复制到另一个对象中,然后再将其复制回来? 本质上是一样的,但更正确和清晰。 如果这个单子同时拥有setters和getters(即允许改变它的状态和读取它),就相当于使用全局变量 工作。 而每个程序员都知道通过改变全局状态工作是邪恶的。 但单子在某种程度上并不算 ) 你不是属于 "他们安装的,我们不需要,这是你的...... "派吗???? 1.保管人,从设计上看,类似于他们在用可改变的内容打字时用来存储状态的模式,以便在这些改变不是一个而是几百个时回滚改变。例如,照片编辑器,文本编辑器... 写完后发现 -https://refactoring.guru/ru/design-patterns/memento 2.基本上,不知道和不了解这个主题来批评那里的东西是不好的做法... 3.你已经不理解的东西怎么会变得更加混乱和难以理解? 4.剩下的就看你自己了... 1...424344454647484950515253545556...96 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
而这些疯狂的心理游戏的意义何在?模式的 "目的"(引号,因为......gladiolus)是"在不破坏封装的情况下,固定和保存对象的内部状态"(引号,因为引用)。但你不能没有setState()方法。那么,在这里,封装的节约在哪里呢?要为每个私有字段再写两个方法...是的......很酷,封装被保留了。
而且要诚实,你会在实践中使用这种方法吗?我怀疑这一点。在实践中,你将使它变得明确和透明--例如,一个具有相同字段集的结构和几种保存和恢复的方法。然后,封装将被真正保留下来,只有两个新的方法:保存状态和恢复。
好的,我会保存它,我需要测试工作原理,也许这就是我所寻找的--为测试者和工作中的EA提供一个代码,它可以保存其状态,相反,在测试者中不要在 "额外的手势 "上浪费资源--这种模式的一部分可以由#ifdef -ami涵盖;)
我正试图理解这个带有守门员的crammer的含义,但我看不出有什么特别的用处。 事实上,通过创造副作用,这是不好的编程实践。 当你改变一个对象时,你会改变另一个。因此,代码变得纠缠不清,难以理解。 我认为,最好是努力实现代码的纯净。
有什么能阻止你简单地将一个对象复制到另一个对象中,然后再复制回来呢? 这本质上是同样的事情,只是更正确、更清晰。
如果这个单子同时拥有setters和getters(即允许改变它的状态和读取它),它就相当于在使用全局变量。 而每个程序员都知道,通过改变全局状态来工作是邪恶的。 但单子在某种程度上并不算 )
我正在努力理解这个托管人的含义,但我看不出有什么特别的好处。 事实上,它通过产生副作用,是一种不好的编程实践。 当你改变一个对象时,你会改变另一个对象。因此,代码变得纠缠不清,难以理解。 我认为,最好是努力实现代码的纯净。
比较简单,我正在学习技术上的东西
我习惯于从有限状态机的角度来评估自动化系统的状况,我总是想保留系统状态的 "快照 "作为备用))))。
我更习惯于从有限状态机的角度来评估一个自动化系统的状态,这总是让我希望能够保留一个系统状态的 "铸件 "作为备份))。
只是在我看来,这样的实现方式过于复杂和混乱了。
目的很明确,只是在我看来,它太复杂和混乱了。
唉,人就是这样--在我得到我的踢腿和颠簸之前,我不太可能得到它))。
唉,人就是这样--在我得到自己的磕磕碰碰之前,我不太可能得到它)))。
有人研究这些模式并没有错--这很好--大脑锻炼,等等,等等。但仔细一看,它原来是一些无间道的假货,一些把吸食者从现实中拉出来的备忘录,就像通过编写控制台应用程序来学习可视化的BASIC。
研究这些模式是很有趣的,如果只是从学习某人的蟑螂--它们在自然界是什么的角度来看。
而如果我们真的要接近保存一个对象的状态的任务,方法是使一个对象可以复制到另一个对象,无论喜欢哪一个,都是一个简单的方法或重载=重载。而在这之后,你可能不想再封装这个功能了。
而如果我们真正对待保存一个对象的状态的任务,方法是使一个对象可以复制到另一个对象,无论喜欢哪一个,不管是通过一个方法还是通过一个重载=。而在这之后,你可能不想再封装这个功能了。
对于现实来说,任何技术系统都可以根据3个基本原则来设计。
- 符合最新标准
- 我们的祖先是这样建造的,没有必要重新发明轮子。
- 我们用粪便和树枝快速建造它,然后我们将重塑它。
)))
开个玩笑,我有时间阅读和玩弄各种选项,我利用了这一点,也有机会在论坛上快速解释不清楚的地方;)
我正在努力理解这个托管人的含义,但我看不出有什么特别的好处。 事实上,它通过产生副作用,是一种不好的编程实践。 当你改变一个对象时,你会改变另一个对象。因此,代码变得纠缠不清,难以理解。 我认为,最好是努力实现代码的纯净。
有什么能阻止你简单地将一个对象复制到另一个对象中,然后再复制回来? 这几乎是同样的事情,但更正确、更清晰。
如果这个单子同时具有设置器和获取器(即允许改变它的状态和读取它),它就相当于处理全局变量。 而每个程序员都知道,通过改变全局状态来工作是邪恶的。 但单子在某种程度上并不算 )
我想这是一个从未与严肃的大型项目打过交道的程序员的典型观点吧? 请原谅我的直言不讳,但我看不出有什么其他的解释,可以说基本的做法不好 )
有人研究这些模式并没有错,这很好--大脑锻炼,等等。然后,仔细观察,发现这是某种无间道的假象,某种引诱吸食者远离现实的备忘录,就像通过编写控制台应用程序来学习可视化的BASIC。
研究这些模式是很有趣的,如果只是从学习某人的蟑螂--它们在自然界是什么的角度来看。
而如果我们真的要接近保存一个对象的状态的任务,方法是使一个对象可以复制到另一个对象,无论喜欢哪一个,都是一个简单的方法或重载=重载。而除此之外,也许封装这一功能的愿望会消失。
Dmitry,在这种情况下,你可能混淆了模式Keeper和Prototype的一些任务,以及它们所有可能的组合和表现形式。第一个快照不一定要复制整个对象,不像Prototype那样。
是的,封装的需求主要表现在有很多人的大型项目 上。对于像这里的大多数任务的玩具,当然是过犹不及)
1)我想弄清楚这个监护人的事情有什么意义,但我看不出有什么好处。
2)创造副作用本质上是一种不好的编程实践。
3)当你改变一个对象时,你会改变另一个对象。因此,代码变得纠缠不清,难以理解。 我认为,还是争取代码的纯洁性为好。
4)是什么阻止了你简单地将一个对象复制到另一个对象中,然后再将其复制回来? 本质上是一样的,但更正确和清晰。
如果这个单子同时拥有setters和getters(即允许改变它的状态和读取它),就相当于使用全局变量 工作。 而每个程序员都知道通过改变全局状态工作是邪恶的。 但单子在某种程度上并不算 )
你不是属于 "他们安装的,我们不需要,这是你的...... "派吗????
1.保管人,从设计上看,类似于他们在用可改变的内容打字时用来存储状态的模式,以便在这些改变不是一个而是几百个时回滚改变。例如,照片编辑器,文本编辑器...
写完后发现 -https://refactoring.guru/ru/design-patterns/memento
2.基本上,不知道和不了解这个主题来批评那里的东西是不好的做法...
3.你已经不理解的东西怎么会变得更加混乱和难以理解?
4.剩下的就看你自己了...