数据拉动与推动OOP方法

Question

当我从头开始设计我的系统时,我经常面临一个两难的境地:我的对象是否应该将信息推送到另一个对象中,或者对象是否应该从另一个对象中提取必要的数据.

在OOP设计中是否有类似标准的东西,我更喜欢按对象的数据拉动,而不是数据推入对象？

任何人都可以提出建议吗,从长期角度来看,或者当OOP结构/框架/图表变得更复杂时,一种方法是否优于另一种方法？

Answer 1

根据告诉不要问,推动更好 - 或更多OO.您不希望查询对象的数据,因此您可以执行某些操作,您希望对象执行此操作,因为他是了解其数据的人.

关于邪恶吸气剂的相关文章

Answer 2

正如其他答案所述,推或拉都不是更好,而是你应该选择最适合你设计需求的那种.

从这里讨论观察者模型是基于推拉还是拉动:

谁触发更新？

主体及其观察者之间的通信是通过观察者界面中声明的notify方法完成的.但它可以从主题或观察者对象触发.通常,当状态发生变化时,主体会触发notify方法.但有时当更新频繁时,主题的连续变化将决定观察者中的许多不必要的刷新操作.为了使该过程更有效,观察者可以在认为必要时负责启动通知操作.

对于这种模式,确定特征是数据改变的频率,然后是观察者希望接收该数据的相应速率.如果观察者希望数据的速度低于主体产生的数据(例如手机上的GPS,你不需要你的位置,只有当你有特定的使用时),然后轮询是更高效.如果观察者想要数据的速度与主体能够产生的速度一样快(可能的例子是实时股票报价应用程序),那么推送通知可能会更好.

Answer 3

我认为这里的讨论有点遗漏了关于拉动和推动的关键点,它被困在个别的例子和案例上.

推送:推送的优势在于您了解自己的数据并且知道自己在推动什么.没有任何组件比拥有数据的组件更了解(或不应该知道)数据,理论上这意味着更好的设计和更强大的系统.

拉动:我在拉动方法中看到的唯一优势是拉动的组件确切知道何时应该拉动.它可以在需要数据时启动对话,并且没有组件知道(或不应该知道)何时需要数据而不是需要数据的组件.

我的结论是:无论组件拥有什么交易,它都会启动交易.如果您要从API检索数据,显然API客户端将拥有该事务,因此将进行拉动.如果您正在广播消息而不是广播公司拥有该交易,那么它就会推送.

Answer 4

在 OOP 中应该没有什么不同（我可能遗漏了一些东西）但是拉式方法更好。

我之所以这么说，是因为最近设计模式的趋势。领域驱动设计和CQRS是其中一些非常突出的，它们促进了松散耦合，这是一件非常好的事情。

一个对象不应该关心另一个对象如何处理它的数据，可以这么说，这不是它的责任。该对象应该只使数据可用，然后需要数据的人应该从该对象中获取/拉出它。看看事件驱动设计。

它使对象独立于其他对象并使其更具便携性（不必更改它推到的位置，因为它会被拉出）。

TL; DR 我建议拉过推。

注意：所有这些不同的设计模式并不相互排斥，而是共存。