Progettare una libreria che sia facile da usare: composizione o ereditarietà

4

Ho progettato una piccola libreria per il lavoro composta da alcune classi esposte. Questi possono essere pensati fondamentalmente come una classe server e client . Ma ora che sto scrivendo tutti i casi di test ed esempi, mi sto chiedendo se le classi dovrebbero essere usate in una classe o ereditate.

Conosco la teologia della composizione sull'ereditarietà ma allo stesso tempo mi vengono in mente le basi OOP: < a href="http://en.wikipedia.org/wiki/Has_a"> ha-a e è-a relazioni.

La mia domanda principale è più sensata e che renderebbe più semplice per i programmatori che usano la mia libreria?

Ho già preparato numerosi argomenti su SO e Programmer riguardo a questo argomento, nessuno in realtà ha preso di mira la mia domanda:

posta Austin Henley 15.07.2012 - 00:51
fonte

2 risposte

4

In primo luogo, qualsiasi classe che scrivi dovrebbe essere ereditabile / estensibile. C # sembra sigillare tutte le sue classi di sistema e quindi non mi mette fine ai problemi. L'ereditarietà è ingannevole, in particolare quando il programmatore della superclasse non sa di cosa avrà bisogno il programmatore della sottoclasse e il sottocluster non può modificare la superclasse. (E in alcuni casi non si può nemmeno guardare il codice della superclasse.) Ma l'ereditarietà può dare ai tuoi utenti finali un sacco di energia per il minimo sforzo da parte loro.

Altrimenti, andrei con la composizione. Spesso inizio con una classe base, la estendo in tutte le direzioni, quindi mi rendo conto che la classe base dovrebbe essere un'interfaccia. Se è tutto nel mio codice, questo non è un problema, ma le persone che usano la tua biblioteca rimarranno bloccate con la tua scelta. In Java ho finito con due classi che sembrano identiche per quanto riguarda le mie esigenze. Se potessi fare in modo che ognuno di loro implementasse la mia semplice interfaccia (aggiungendo "extends myInterface" - entrambi hanno già i metodi) sarei tutto pronto, ma devo trattarli come classi distinte, non correlate.

L'idea migliore potrebbe essere quella di fornire delle buone interfacce e implementazioni predefinite in modo che gli utenti finali possano fare tutto ciò che vogliono. Suppongo che il mio punto sia che gli utenti della tua biblioteca dovrebbero essere quelli che devono prendere la decisione sulla composizione e l'ereditarietà; il tuo compito è dare loro la possibilità.

    
risposta data 16.07.2012 - 16:42
fonte
7

I programmatori dovrebbero favorire la composizione sull'ereditarietà nelle lingue OO, periodo. A meno che la tua biblioteca non abbia una ragione convincente per rendere l'ereditarietà forzata più naturale / efficace, allora dovresti assumere che le persone consumeranno la tua biblioteca tramite la composizione.

Soprattutto come scrittore di librerie poiché cambiare una classe che viene ereditata causerà più errori (in generale) di quelli che vengono creati.

    
risposta data 15.07.2012 - 01:00
fonte

Leggi altre domande sui tag