Impone all'utente di estendere la classe o utilizzare la configurazione

Naviga le tue risposte
1

Che cosa è una pratica migliore: costringere l'utente ad estendere la classe astratta o a creare una classe con la configurazione? Per esempio. pseudocodice: 

ClassA{
 this.name
 this.weight
 this.height
 this.width

 constr(config){
  this.name = config.name
  this.weight = weight
  this.height = height
  this.width = width
 }
}

o 

abstract ClassA{
 this.name
 this.weight
 this.height
 this.width
}

ClassB extends ClassA{
 this.name = 'Item'
 this.weight = 12
 this.height = 11
 this.width = 14
}

Fino ad ora usavo la configurazione perché la maggior parte delle librerie utilizza questo metodo, ma cosa c'è di sbagliato nel secondo metodo? Recentemente ho scoperto che il metodo con estensione sta producendo codice più chiaro ma forse mi manca qualcosa?

    
posta Krzysiek Grzembski 30.08.2013 - 14:27
fonte

3 risposte

3

Favorisci la composizione sull'ereditarietà entra in gioco qui, anche se non mi piacerebbe se fosse possibile. Lascia che la classe si preoccupi di rappresentare se stessa, costruiscila con impostazioni predefinite sane e lascia che il suo consumatore si preoccupi di come popolare.

Oltre a ciò, si applicano gli argomenti generali per la composizione sull'ereditarietà.

    
risposta data 30.08.2013 - 15:18
fonte
2

con il tuo secondo esempio nella maggior parte delle lingue creerai nuovi campi in ClassB diversi da quelli in ClassA ( objB.name sarà diverso da ((ClassA)objB).name )

inoltre non dovresti forzare il tuo utente ad ereditare dalle classi se puoi evitarlo. Ciò è dovuto principalmente al fatto che gli utenti possono commettere errori e dimenticare di inizializzare un campo che lascia l'oggetto in uno stato illegale, o dimenticare di aggiornare l'implementazione quando un campo viene aggiunto / rimosso

tl; dr : vi sono meno possibilità di errori quando tutti i dettagli di implementazione di un componente si trovano in un unico punto

    
risposta data 30.08.2013 - 15:10
fonte
1

Quando si specifica solo una serie di impostazioni semplicistiche (cioè stringhe, numeri, booleani) l'ereditarietà non sembra essere la strada giusta per me; più istanze sarebbero inutili e, come affermato da Ratcher, le proprietà definite non sarebbero vincolanti con quelle del super-tipo. Per un numero molto basso di opzioni, direi argomenti del costruttore come il tuo primo esempio. Per numeri più alti, forse una configurazione XML, o anche un tipo di oggetto separato (XYZLibraryConfig).

Non che l'ereditarietà per la configurazione utente non abbia i suoi scopi, se l'utente è intenzionato a riempire un po 'di logica. In risposta alla preoccupazione di un cricchetto per l'estensione impropria, potrei spingere di più verso le interfacce, o le classi astratte che richiedono tutti gli spazi vuoti da compilare dall'utente; in modo tale che l'unico modo per rovinarlo sia se il cliente stesso genera un'eccezione o restituisce null nei metodi di cui è responsabile.

    
risposta data 30.08.2013 - 15:32
fonte

Leggi altre domande sui tag

Linee di codice che assumono troppa responsabilità [chiuso] È necessario utilizzare "-" o "+" prima di ogni dichiarazione di proprietà o metodo in Interface e perché?