Overriding properties of child view controller vs setting them via parent view controller

If you want to modif开发者_Go百科y the default behaviour of a View Controller by changing the value of one of its properties, is it considered better form to

1. instantiate the class and set its property directly, or

2. subclass it and override the property?

With the former it would become the parent View Controller's responsibility to configure its children, whereas with the latter the children would effectively configure themselves.

EDIT: Some more information:

The class I am referring to is FetchedTableViewController, a subclass of UITableViewController that I made to display the results of a Core Data fetch operation.

There are two places I want to display the results of a fetch, and they each have different fetch requests.

I'm trying to decide whether it's better to create a subclass for each one, and override the fetchRequest property, or make it the responsibility of the parent controller to set the fetchRequest property for its children.

---

From your description, this sounds like a place where you should be providing your own init:

- (id)initWithParamterINeed: (BOOL)aParameter;
{
    if (( self = [super initWithNibName: @"MyNibName" bundle: nil] )) {
        parameter = aParameter;
    }
    return self;
}

---

Generally speaking, Cocoa is designed to minimize subclassing (hence the wide use of delegates). That said, UIViewController is a class designed specifically TO be subclassed. Since it's better to keep code 'local', I'd recommend subclassing.