views:

481

answers:

2

I have a fundamental question related to Cocoa frameworks design patterns.

What's the difference between delegate and data source?

Both of them could use @protocols declaration, but some classes or frameworks are using delegate, and some others are using data source.

All I can understand from UI/NSTableView is the delegate respond to UI-related events, while the data source is purely related to the data. But, I don't know any data source implementations outside the UI classes of Cocoa.

Note: The delegate I mentioned in this question is not always related to UI events. The data source question has been answered.

+4  A: 

The datasource supplies the data, the delegate supplies the behavior.

In MVC, datasource is in the model layer and the delegate is in the control layer.

Actually, on second thought, the datasource is usually controller that is lower down, closer to the model. I don't think I've ever used a model object as my datasource.

kubi
+7  A: 

The delegate and datasource patterns are largely independent, and orthogonal:

The delegate pattern is very common in Cocoa and allows a delegate (any instance implementing the informal delegate protocol prior to OS X 10.6, or the formal delegate @protocol in 10.6 and later) to modify the behavior of an object instance. This pattern is often used instead of subclassing: instead of subclassing a class to change its behavior, you supply a delegate that responds to the appropriate methods. Classes that use delegates send messages to their delegate at contracted events. The API between class and delegate is defined by the class and is different for each class that uses the pattern, but the API generally consists of messages asking the delegate how to handle a particular event. One advantage of the delegate pattern over subclassing is that a class may implement multiple delegate protocols, allowing its instances to act as delegate for multiple classes. Similarly, an object instance can be the delegate for multiple other objects (hence most delegate APIs pass the object as the first argument to each message in the API). The delegate pattern is not as common in other UI frameworks (though Qt does use the delegate pattern in its Model/View framework), and is not the same as .Net/CLR delegates which are essentially typed function pointers.

The data source pattern is often used by NSView sub-classes in Cocoa that have complex state data such as NSBrowser, NSTableView, NSOutlineView, etc. The data source protocol defines an API that instances of these (and other) classes may use to get the data to display in the view. Although the NSController and Cocoa Bindings architectures have replaced many uses of the data source pattern, it's still common and very powerful. Like the delegate pattern described above, part of its power comes from an object being able to act as the data source for multiple data-source-using instances (and possibly even instances of multiple classes that have different data source protocols). The data source pattern is used commonly in other UI frameworks, such as Qt (in the Model/View framework where the model is analogous to the data source) and WPF/Silverlight (where the data source might be more closely analogous to the view model).

Barry Wark
Okay, a very comprehensive explanation. My understanding right now is data source don't respond to events. In the case of Cocoa classes, it only provides a way to implement what data to be displayed in a certain view.I'm just not sure why the concept of data source is never used outside UI-related classes of Cocoa frameworks.
Jesse Armand
@Jesse Just to be clear, neither delegates nor data sources respond directly to UI events (i.e. an `NSEvent` passed to the app via the run loop). An object may ask a delegate how to respond to an event (either an `NSEvent` type event or any other message from an other object).Data sources aren't used outside of UI classes because they're not needed; the model of MVC is its own data source.
Barry Wark
Ok, sorry if you misunderstood. I didn't mean to say that delegate always respond to UI events. My primary concern was the "flexibility" of the term data source to be used outside UI classes. I agree and I never found any need for that outside UI classes.
Jesse Armand