Question

I often get confused with when to use DataSource Pattern and when to use the Properties for providing configuration information to objects.

I have two ways to do this,

Generally I keep a lot of properties in the Object’s class that has to be configured and a method that resets the object and continues with the new properties.

And the for the Object which is configuring the other object, I keep a method that with the name configureXYZ:WithValues: , which resets the properties and calls the reset method of the object to be configured.

This I have seen with MPMoviePlayerController, that we have to set properties.

and Other way is how tableView works, all the configuration information comes from datasource methods.

Can anyone throw more light on which way is preferred in which scenario.

Because Its often I feel tempted to use design patterns and make the code look stylish but I wanted to know when do we actually need these.
I am absolutely clear with delegate pattern and have to use it on regular basis.
DataSource was one thing I was never clear with.

Answer 1

When designing a class, the key factor you should consider when deciding between using a delegate or properties is how often the values can change. Properties work best if you will set the values one time and they should never change again. Delegates (of which datasource is just an example) work best if the values might change over time or change due to conditions.

For example, in UITableView, the number of rows is highly dynamic. It could change for many reasons outside of the control of the table view. What the rows even represent is highly dynamic. They might be data; they might be menu options; they might be pieces in a game. UITableView doesn’t try to guess or control any of that. It moves it to a delegate (datasource) where potentially very complex decisions could be made.

MPMoviePlayerController has a few controls that mean very specific things and should almost never change (particularly once the movie starts playing). Basically you set the thing up, hit play and walk away. In that case, a delegate would likely be overkill.

There are many cases that are in the middle, and either way may be ok. I would encourage developers to consider delegation first, and then if it doesn’t make sense go with properties. This isn’t because delegation is always the right answer, but more because most C++- or Java-educated developers don’t think in terms of delegation, so should make a conscious effort to do so.

Some other thoughts along these lines:

• When using properties, it is ideal if they are configured at initialization time and are thereafter immutable. This solves a great number of problems.

• If you find yourself needing a lot of properties, delegation is probably better and often simpler.

• Delegate notification methods (somethingDidHappen:) are often better implemented as blocks. (Blocks are relatively new in ObjC. Many delegate-based Apple interfaces are moving to blocks, but you’ll see a real mix out there for historical reasons.)

• The difference between “delegate” and “datasource” is that a delegate manages behavior, while a datasource provides data. They are typically implemented identically.