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

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.

Answer 2

The answer depends on your architecture goals, in other words there is no general solution.

In a client server architecture you likely will have a layered system on the backend where objects pull state from other objects. That means only certain "services" will in the end update the state of an object. Example: creating a new object, updating a field of an object etc. (Like adding a new order item to the total order).

In monolithic desktop application it might be completely different. You likely use "Model-View-Controller" variations and observer patterns etc. In this case you push info e.g. to the UI.

Answer 3

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.

Answer 4

From a design perspective, the data pull is always a better approach. The reason being that whatever information needs to be fetched, you're better off making functions in classes that returns those values instead of pushing information, which is not wrong but may complicate the outputs hierarchy when you are using polymorphism and advanced OOP concepts. Hope this answers your question.

Answer 5

@kamil-tomsik What do you think on a client server model, where you have hundreds of client who are observers, but they don't need same data, so if you push you have to send them all the data you want to share, but some of them, don't need it. Isn't it slow down the communication?

Answer 6

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.