Data Pull vs. Push OOP Approach

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 pull the necessary data from another objects.

Is there anything like a standard in OOP design, that I should prefer data pull by objects, versus data push into objects?

Can anyone experienced advise, whether one approach is better over the other from longer term viewpoint, or when the OOP structure/framework/diagram gets more complex?

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

I think the discussion here is kind of missing the crucial point about pulling and pushing and it is stuck on individual examples and cases.

Pushing : The advantage of pushing is that you know your data and you know what you are pushing. No component knows (or should not know) the data better than the component who owns the data, which will theoretically imply a better design and a more robust system.

Pulling : The only advantage I see in pulling approach is the component who pulls exactly knows when it should pull. It can initiate the conversation when it needs the data and no component knows (or should not know) when the data is needed than the component who needs it.

My conclusion on that is: whichever the component owns the transaction, it initiates the transaction. If you are retrieving data from an API, obviously the API client will own the transaction so will do a pull. If you are broadcasting a message than the broadcaster owns the transaction so it does a push.

As stated by other answers, neither push nor pull is better, but rather you should pick the one that best fits your design needs.

From here discussing whether an observer model should be push or pull based:

Who triggers the update?

The communication between the subject and its observers is done through the notify method declared in observer interface. But it can be triggered from either subject or observer object. Usually the notify method is triggered by the subject when it's state is changed. But sometimes when the updates are frequent the consecutive changes in the subject will determine many unnecessary refresh operations in the observer. In order to make this process more efficient the observer can be made responsible for starting the notify operation when it consider necessary.

For this pattern the determining characteristic is the frequency at which the data changes and then the corresponding rate at which the observers wish to receive that data. If the observers want the data at a slower rate than the subject generates the data (an example would be GPS on a phone, you don't need your position all the time, only when you have a specific use for it) then polling is more efficient. If the observers want the data as fast as the subject can produce it (a possible example would be a real-time stock ticker application), then push notifications are probably better.

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.

destination.Push(source)

• Destination knows what and how to get data from Source
• Destination must depend on Source, or
• else Source must implement a provided ISource interface and depend on the provider (might be the Destination package)
• The method has direct private access to Destination.

source.Pull(destination)

• Source knows what and how to put into destination
• Source must depend on Destination, or
• else Destination must implement a provided IDestination interface and depend on the provider (might be Source package)
• The method has direct private access to Source.

Select your solution by looking at the dependencies you want to have in your code.

If Source and Destination cannot depend on what's needed for the previous scheme, then you need the action to be performed by an external method that knows (depends on) both Source and Destination. It only has public access to both though.

If you need any virtual ISource to feed any IDestination then you need those interfaces to expose all the methods needed for an external method to perform the action.

If a single external method cannot perform the action on any ISource and any IDestination, then you might want to look at the Visitor pattern, the Visitor class performing all the particular actions on the specific Source1 and SourceX Destination1 and DestinationY.