Data Pull vs. Push OOP Approach

Question

When I design my system from scratch, I often face a dilemma whether my object should push information into another objects OR whether the objects should

Answer 1

From my perspective... As a desktop application developer using mvc, there is a delicate balence where by you push data when available to your model objects, then based on logic in the model (timers/ asynchronous events/ notifications) then the data is pushed out to the controllers and in turn to the view... The ui interactions can go either way depending on preference, they can fire a refresh or update message which tells the controller it needs to do something, or it can specifically push data into the controller and often in turn the model.

Of course this is simplified and confounded by real world scenarios but just having enough wherewithal to intend to do it a particular way can go a long way.

Answer 2

The word push/pull is relative. There will be a pusher who has data and there will be a puller who needs data. If we actually store the data in a neutral place and not inside push-er/pull-er, many possibilities raise that suits a given problem at time.One updates the data when he has it(send notification if necessary) and the other pulls the data at his convenience. Many design patterns, MVC, Observer, Command, etc fall in place to handle the scenario.

Answer 3

First, the general guideline clearly is: objects are data and behavior. This encourages less getters and so less pulls by providing methods which do something with the internal data.

Alone "push is better" (in the accepted answer) can't quite work as a push-operation in some class can require a new pull at the pushed object. Instead the best practice should be adding the push operation where it fits the abstraction best. This can even lead to a new more abstract class / composition of classes (see Object-Oriented Design Heuristics, Riel, 1996, p. 37 f.).

Answer 4

According to tell dont ask, push is better - or more OO. You don't want to query object for data so you can do something, you want object to do it, because he's the one who knows his data.

Related article about evil getters

Answer 5

It should not be any different in OOP (there may be something i have missed) but a pull approach is better.

The reason I say this is because of the recent trends in design patterns. Domain Driven Design and CQRS being some of the very prominent, they promote loose coupling which is a very good thing.

A object shouldn't care what another object does with it's data, it is not it's responsibility so to speak. The object should only make the data available and then the ones needing the data should fetch/pull it from that object. Look at event driven design.

It makes the object independent of the other objects and makes it more portable (don't have to change where it pushes to, since it will get pulled from).

TL;DR I would recommend pull'ing over pushing.

NOTE: all these different design patterns dosen't exclude each other, but coexist.

Answer 6

Usually 'pulling data' means you're doing an ajax call and running a callback upon its successful response. This isn't bad, but it can be overly intensive if you're checking for data updates and are thus doing it on an interval.

But in the context of an online web application, an alternative to this is push with long polling. Since long polling isn't terribly different from the first method, I propose you do the following:

Create a long polling method that pulls data from a a semi public push url endpoint (aka a webservice for pubsub), and then update everything that needs to be updated via using a publisher-subscriber design pattern in your client. That way your updates are more decoupled from the data source.

Here's a white paper that was written on this topic by IBM. http://www.ibm.com/developerworks/library/specification/ws-pubsub/