Buona pratica di programmazione per classi figlio simili

Question

Buona pratica di programmazione per classi figlio simili

#1 da (2 voti)
#2 da (0 voti)

1

Sto sviluppando un'applicazione iOS, in cui devo disegnare alcuni pattern su una vista in base all'opzione selezionata dall'utente. Lascia che ti spieghi più chiaramente.

L'utente mostrerà il numero di immagini come opzioni tra cui scegliere.

Selezionando un'opzione, verrà disegnata una vista. Questa vista eredita da una classe che dice ParentClass dove ho impostato le proprietà comuni per le classi figlie.

ParentClass

@interface ParentClass : UIView

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

//common properties declared

@end

In questo momento, il mio approccio è l'uso di classi separate per ogni modello. Sovrascrivo drawRect: per motivi diversi. Ecco perché sto creando classi figlio separate per ciascuna.

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

Esistono molte classi figlio simili che hanno un'implementazione drawRect diversa. Nel controller principale, inizializzo la classe child pattern in base alla selezione utilizzando 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;
}

Il problema è che ho un sacco di opzioni, diciamo 50 - 100. La creazione di classi ereditate separate (50 - 100 .h e .m file) sarebbe un approccio davvero negativo secondo me ed è una cattiva pratica di programmazione.

Quindi quale modello dovrei seguire qui per ottimizzare il mio codice? Come dovrei creare le mie classi / modelli figlio? Quale sarà l'approccio migliore? Un'idea nella mia mente è quella di passare l'indice selezionato a spero che la mia domanda sia chiara .. Grazie.

Un'idea nella mia mente è creare una classe di pattern figlio singolo che abbia selezionato l'indice come proprietà. In base all'indice selezionato, implementerò il metodo drawRect: . Ma ci saranno molti casi if-else o switch.

object-oriented ios mvc

posta NightFury 20.02.2014 - 13:07

fonte

2 risposte

0

Sembra che tu stia confondendo le classi con gli oggetti. Una classe è un modello, con il codice incluso per implementare l'oggetto reale, mentre un oggetto è il valore effettivo. Ad esempio, crei una classe Letter, ma non crei una classe separata per ogni lettera dell'alfabeto. È necessario semplificare abbastanza drawRect in modo che possa essere calcolato dalla più piccola quantità di dati e codice. Quel dato e codice andrebbero nel tuo ChildDesign .

risposta data 20.02.2014 - 21:31

fonte

Leggi altre domande sui tag object-oriented ios mvc

Come organizzare i repository per una libreria divisa? Versione Pythonic delle interfacce Java

score 2 · Accepted Answer

Per rispondere a questa domanda, devi prima capire a livello di drawRect . A rigor di termini, se hai veramente una causa per differenziare le classi in base a drawRect , avere 50-100 classi figlio è ciò che dovresti fare. Tuttavia, è un po 'difficile credere che qualcosa non possa essere recuperato tra le implementazioni.

Ad esempio, diciamo che l'unica differenza tra queste classi è l'icona che viene disegnata nello spazio indicato da drawRect . A questo punto, non è drawRect che cambia tra una classe figlio e un'altra ma l'icona stessa. Pertanto, in quel caso, potresti semplicemente creare una "icona" di proprietà che, quando viene chiamata drawRect , disegna quell'icona nello spazio indicato.

È difficile immaginare una circostanza in cui ogni classe di figlio abbia realmente bisogno di una propria implementazione di drawRect , tuttavia non sto scontando esplicitamente la possibilità perché potrebbe essere il caso. Supponiamo che in una classe di figlio si disegna un triangolo mentre in un'altra si disegna un cerchio e in un'altra ancora si disegna un rettangolo. Se non è possibile generalizzare questo comportamento, sarebbe corretto implementare una classe figlio per ognuno. Tuttavia, anche se potresti generalizzare disegnando un'icona di un triangolo o un'icona di un cerchio, allora questo è già una ragione sufficiente per avere una classe che fa questo per te.

Più probabilmente nella tua circostanza, potresti probabilmente generalizzarlo in una classe monoparentale, o in mancanza, non più di una manciata di classi figlie per ogni opzione tipo . Cerca di ricordare che quando il codice è diverso, hai bisogno di una nuova classe, ma se i dati differiscono, hai solo bisogno di una nuova istanza.