La risposta generale è prenderla caso per caso. Per alcune attività di modellazione si possono avere gerarchie in cui le classi base sono utilizzabili. Quelli relativi alla GUI vengono in mente come candidato principale. Uno ha una classe Button, che ti dà un pulsante standard. Ma uno ha anche una classe SubmitButton, che è derivata da Button, e rende il pulsante tutto alla moda, ma ha ancora bisogno dei comportamenti di Button. Quindi, ha senso usare l'uno o l'altro, a seconda delle circostanze, e non preoccuparsi di NonSubmitButtons.
D'altro canto, una gerarchia di classi di connessioni per diversi database non consentirebbe tale utilizzo. Avresti la tua classe Connection, che è derivata da MySQLConnection, PostgresConnection, ecc. Non ha senso costruire una connessione generica - solo per lavorare con uno.
Penso che il tuo caso ricada nel primo caso, piuttosto che nel secondo caso.
D'altra parte, si potrebbe abbandonare completamente il concetto di una gerarchia di classi se la situazione si aggrava. Ad esempio, se si desidera rappresentare i file archiviati, i file memorizzati su server remoti, i file in stile procfs ecc., È necessaria una gerarchia piuttosto grande. Se un file potrebbe essere uno dei precedenti, avresti rapidamente una gerarchia complessa: cose come FileWithIntegrityAndOnARemoteServer sembra piuttosto brutto. Per casi come questo, è possibile memorizzare le proprietà extra come proprietà effettive della classe. Per ogni file, le proprietà sono facoltative, ma per i file con controlli di integrità, la proprietà appropriata è presente ecc. È un'istanza della composizione idea di ereditarietà .