Never Subclass Components
Only subclass CKCompositeComponent
. (If you need to perform advanced layout by overriding computeLayoutThatFits:
you may subclass CKComponent
directly, but this should be rare.)
- Subclassing is difficult to reason about. There is no
final
keyword in Objective-C, so any method can be overridden in a subclass. It’s impossible to read a superclass and know what is and isn’t overridden somewhere. - Subclassing makes refactoring the superclass difficult. If the superclass is refactored to rename or remove a method, every subclass must be inspected to see if they were overriding the method. This is often skipped or forgotten, leading to silent bugs.
For example, imagine that we’re adding a new “highlighted” card component. It should look just like a regular card component, but have a yellow background color. Don’t do this:
@implementation HighlightedCardComponent : CardComponent
- (UIColor *)backgroundColor
{
// This breaks silently if the superclass method is renamed.
return [UIColor yellowColor];
}
@end
Instead, make CardComponent
take the color as a parameter and then subclass CKCompositeComponent
to create your highlighted component:
@implementation HighlightedCardComponent : CKCompositeComponent
+ (instancetype)newWithArticle:(CKArticle *)article
{
return [super newWithComponent:
[CardComponent
newWithArticle:article
backgroundColor:[UIColor yellowColor]]];
}
@end