Good Programming Practice for similar child classes

Question

I am developing an iOS application, in which I have to draw some patterns on a view based on option selected by user. Let me explain you more clearly.

User will be shown number of images as options to choose from.

On selecting an option, a view will be drawn. This view is inheriting from a class say ParentClass where I have set up common properties for child classes.

ParentClass

@interface ParentClass : UIView

-(ImagePlaceHolder *) imageHolderTouched:(CGPoint) position;

//common properties declared

@end

Right now, my approach is use of separate classes for each pattern. I override drawRect: for different patterns. So that's why I am creating separate child classes for each.

ChildDesign

@interface ChildDesign : ParentClass

@end

@implementation CollageDesign

- (id)initWithFrame:(CGRect)frame
{
    self = [super initWithFrame:frame];
    if (self) {
        // Initialization code
        [self drawViews];
    }
    return self;
}

-(void) drawRect:(CGRect)rect
{
//different implementation for different classes
}

@end

There are many similar child classes just having different drawRect implementation. In main controller, I initialize pattern child class based on selection using switch case.

ParentClass collView;

switch (selectedOptionIndex) {
            case 1:
                collView = [[ChildDesign alloc] initWithFrame:newframe];
                break;
            case 2:
                collView = [[ChildDesign2 alloc] initWithFrame:newframe]; //similar other classes
                break;
            case 3:
                collView = [[ChildDesign3 alloc] initWithFrame:newframe];
                break;
}

Problem is that I have got alot of options, say 50 - 100. Creating separate inherited classes (50 - 100 .h and .m files) would be really bad approach in my opinion and is bad programming practice.

So What pattern should I follow here to optimize my code? How should I create my child classes/ patterns? What will be best approach? An idea in my mind is to pass selected index to I hope my Question is clear.. Thanks.

An idea in my mind is to create single child pattern class having selected index as a property. Based on selected index, I will implement drawRect: method. But there will be lot of if-else or switch cases.

Answer 1

In order to answer this, you must first understand at the level of drawRect. Strictly speaking, if you genuinely have cause to differentiate classes according to drawRect, then having 50-100 child classes is what you should do. However, it is a little hard to believe that something can't be salvaged between implementations.

For instance, say the only difference between these classes is the icon that gets drawn in the space indicated by drawRect. At this point, it isn't drawRect that changes between one child class and another but the icon itself. Therefore, in that case, you could simply create a property "icon" which, when drawRect is called, will draw that icon in the indicated space.

It is difficult to imagine a circumstance in which each child class would genuinely need to have its own implementation of drawRect, however I'm explicitly not discounting the possibility because it could be the case. Suppose in one child class, you draw a triangle while in another you draw a circle, and in another still, you draw a rectangle. If you cannot generalize this behavior, then you'd be correct to implement a child class for each one. However, even if you could generalize by drawing an icon of a triangle or an icon of a circle, then that is already reason enough to have one class which does this for you.

More than likely in your circumstance, you could probably generalize it into a single parent class, or lacking that, no more than a handful of child classes for each option type. Try to remember that when the code differs, you need a new class, but if the data differs, you only need a new instance.

Answer 2

This sounds like you're confusing classes with objects. A class is a template, with the code included to implement the actual object, while an object is the actual value. For instance you would create a Letter class, but wouldn't create a separate class for every letter of the alphabet. You need to simplify drawRect enough so that it can be calculated from the smallest amount of data and code. That data and code would go into your ChildDesign.