Question

I have created a class, Metrics that is designed to be subclassed to customize behavior. In order to make this more robust, the init method of Metrics calls a method named setup that does nothing by default. If subclasses want to customize behavior during initialization (which they commonly do) they can override this method. Since the default implementation does nothing, there’s no need to remember to call [super setup].

I like the way that this works so far, it’s robust and easy to use. The problem I have now is that there are times when the setup method requires some additional property to be set. An example:

@implimentation Metrics

- (id)initWithFrame:(CGRect)frame {
  self = [super initWithFrame:frame];
  if (self) {
    // Do all the required initialization
  }
}

@end

@interface SubclassOfMetrics : Metrics {}

@property (assign) CGFloat width;

@end

@implimentation SubclassOfMetrics

- (void)setup {
  // This method is indirectly called as a result of the superclass initialization
  // The code here depends on the `width` property being set
}

@end

The problem I have is that setup is called before the property width can be set. What options do I have here? I can work around this by not initializing my Metrics class in the init method. I can do it explicitly after I have set the properties I need to set. I’m not of fan of this, as it requires me to perform actions in a certain order and remember to setup. Do I have any other options?

Edit: The root of problem is really that the initialization of the Metrics class does a lot of calculations. The results of those calculations will depend on the properties being set in a subclass, so I need a way to get those properties set before the superclass is done initializing.

Answer 1

I set the iVars before initializing the superclass.

- (id)initWithFrame:(CGRect)frame andMetricWidth:(CGFloat)inWidth {
  _width = inWidth

  self = [super initWithFrame:frame];
  if (self) {
  }

  return self;
}

I intentionally set the iVar directly to avoid any potential side-effects from using the property syntax. I haven’t fully thought through how this would work with objects under ARC, but it works just fine with primitives.