Qual è il miglior approccio al design decisionale?

Sono presenti Foo1 e Foo2 correlate (concettualmente, ovvero) o condividono semplicemente alcune funzionalità?

Se sono concettualmente correlati, andrei con una classe astratta.

Se condividono semplicemente la funzionalità, interrompo quella funzionalità e creo una classe separata. Puoi quindi utilizzare la composizione per creare Foo1 e Foo2 .

Come sempre, dipende.

Se tutte le istanze di Foo1 e Foo2 possono essere denominate logicamente FooParent , utilizzare l'ereditarietà.

Affinché la classe di utilità abbia un senso, dovrebbe essere qualcosa che può essere utilizzato su più progetti, pensate alle librerie di Apache su questo.

Tipicamente in questi scenari si desidera avere Foo1 e Foo2 essere composti da FooUtility .

Come hanno affermato gli altri utenti, è difficile rispondere alla domanda senza conoscere la relazione tra le classi. La risposta è, come sempre, dipende.

L'ereditarietà dovrebbe essere utilizzata solo se puoi dire "Foo1 è un FooParent". L'ereditarietà è uno strumento potente, ma può anche legare le mani lungo la strada.

Il GoF ha raccomandato "composizione sull'ereditarietà" - l'uso delle interfacce consente la massima flessibilità. Il rovescio della medaglia è che si può finire con il codice gonfiato se si dichiara un'interfaccia per ogni piccola responsabilità. Le interfacce generalmente descrivono cosa un oggetto fa invece di ciò che è (ereditarietà).

La teoria a parte, è la chiave di funzionalità comune a ciò che Foo1 e Foo2 fanno o fanno? O è un codice più standard che non ti piacerebbe dover scrivere ogni volta. Se fa parte del comportamento della classe, usa l'ereditarietà. In caso contrario, se è solo un boilerplate (codice di accesso ai dati, validazione o sicurezza), una classe di utilità sarebbe probabilmente la mia scelta.

Dalla tua domanda sento che le due classi Foo1 e Foo2 non hanno alcuna relazione commerciale (perché hai specificato che non hai bisogno di ereditarietà polimorfica).

quindi basandomi su questo ti suggerirei di usare qualche classe di Utility esterna piuttosto che aggiungere una super classe astratta. Poiché correlare due classi che non sono realmente correlate solo per condividere funzionalità comuni potrebbe compromettere / complicare le future espansioni del tuo progetto.

Ad esempio, se hai Foo11 e Foo12 che hanno una relazione commerciale con Foo1, sarebbe più semplice e logico usare il genitore comune Foo1Parent a quel punto.

Come hai detto -

... that share some common functionality. So far it does not seem like I need any polymorphic inheritance ...

Il che significa che puoi incapsulare la funzionalità comune. Dalla mia esperienza, la maggior parte delle volte, l'incapsulamento è migliore dell'ereditarietà.

class Myclass{
   private Common common;

}

Non sto dicendo che l'ereditarietà sia cattiva. Ha il suo posto.

Assicurati che il tuo design sia tale che ogni classe abbia responsabilità chiare che possono essere chiaramente descritte con il loro nome. Considerare quale modularizzazione produrrà il codice che è più facile da testare e modificare. Factoring qualsiasi codice comune a una classe chiamata Utilities è un odore di codice.