We use option 3 sometimes…

Option 3 i.e “Getting a stub just before the method call” is essentially “setter” injection in a factory.

We have different grades of dependency. Mandatory references will always be injected via ctor. Optional references will be usually ” setter” injected – e.g. diagnostics. Also, an arguable advantage is of using this approach is the code is simple to read!

He briefly mentions that TOOD conflicts with OOD – from my experience thats a huge understatement. Usually, using IOC + SRP etc means code is easier to test – but this makes the code much more complex – e.g. at the high level of the domain you may sometimes end up with classes that have a ridiculous number of dependencies. 100% TOOD + 100% OOD != solved problem. In my opinion fully abiding by OOD means TOOD is broken or vice versa – you cant have the best of both worlds, you must instead trike a happy medium. In my experience finding the happy medium can be challenging!

Additional notes:
Wouldnt it be so much easier if c# had virtual methods by default!
Really like InternalsInvisibleTo, may adopt this

There was a question about how to configure a table view – here is a nice guide http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/TableView_iPhone/CreateConfigureTableView/CreateConfigureTableView.html

Regarding custom table view cells loaded from nib files, here is a sample http://iphone.galloway.me.uk/iphone-sdktutorials/custom-uitableviewcell/ . The trick is that you can set up the view controller of the custom cell to be the same class as the table view’s controller and bind the cell view to an outlet of the controller – that way your code does not get fragmented into more classes/controllers.