OO Software Architecture - classe base da cui tutto eredita. Cattiva / buona idea?

La vera domanda è: perché l'architetto vuole che tutto erediti dalla base? Qual è l'utilità di farlo?

Se è per qualcosa come le interfacce di serializzazione, allora potrebbe avere senso se hai bisogno di una funzione di serializzazione generale. Ma assicurati di aver effettivamente bisogno di OGNI classe nel sistema per avere quella funzionalità. Se non lo fai, finisci per gonfiare inutilmente ogni classe, e finirai per dover implementare (o spegnere) funzionalità in classi in cui tale funzionalità non ha senso.

Non avrei MAI implementato la mia 'uber-base' come questa in un sistema, perché non riesco a concepire alcuna funzionalità o interfaccia che vorrei in OGNI OGGETTO OVUNQUE nel mio sistema. L'unica cosa che posso pensare che potrebbe essere utile è qualcosa di simile a contenitori eterogenei, ma non sono mai stato in una situazione in cui volevo un contenitore completamente eterogeneo - generalmente voglio un insieme di classi, non solo qualsiasi cosa casuale sotto il sole per andare nei miei contenitori.

A meno che l'architetto non riesca a dimostrare perché vogliono questa uber-base, lo lascerei fuori.

Che cosa intendi quando dici "oggetto grande"? Impronta di memoria? Questo non dovrebbe essere un problema.

Se i metodi sono statici (è questo che intendi per "classe statica"?), fanno parte della classe, non di ogni istanza. Ma anche se si tratta di metodi di istanza, non dovrebbero influire sull'impronta di memoria di un oggetto.

Se intendi "oggetto grande" come in "contenenti molti metodi che usi raramente", allora ... sì, potrebbe essere un problema. La classe base condivisa dovrebbe probabilmente contenere solo metodi che sono realmente condivisi.

La domanda è: cosa miri esattamente a raggiungere con questa architettura? .NET Framework ha una classe Object condivisa, come menzionato da superM, ma successivamente la gerarchia è piatta, con la maggior parte delle classi che ereditano direttamente (anche se implicitamente) da Object .

Il fatto che ogni classe erediti da una singola classe base potrebbe creare un oggetto grande a seconda di ciò che viene inserito nella classe base. Ma il vantaggio di questo è che tutto il tipo di utilità di funzioni può essere inserito nella classe base e questo offrirà un'implementazione uniforme.

Non sono sicuro che tale architettura abbia un nome, ma questo è esattamente ciò che Microsoft ha fatto (eccetto che non tutti i metodi nella classe base sono statici). In C #, ad esempio, ogni tipo è ereditato dalla classe Object . Quindi ogni tipo ha metodi come Equals(...) , GetHashCode() ecc. In molte applicazioni MVC esiste un controller di base, che viene ereditato da tutti i controller.

Questo approccio ha molti vantaggi. Eccone alcuni:

• interfaccia comune per tutti gli oggetti
• un insieme di funzioni obbligatorie, che ora ogni oggetto avrà
• flessibilità: nuove funzionalità comuni possono essere facilmente aggiunte
• ecc.

Lo svantaggio è che potrebbero esserci oggetti che non avranno mai bisogno di questi metodi, ma che comunque li erediteranno. Sebbene questi svantaggi possano essere facilmente ignorati.

My immediate thought was that every object in any class will inherit all the methods in Base which would create a large object.

Questo non è corretto. Il riferimento al tipo genitore è un puntatore aggiuntivo nel peggiore dei casi. Se il tipo base ha solo metodi o membri statici, non aggiungerà nulla al sottotipo quando è istanziato.

Could this cause problems for a large system? The whole architecture is hierarchical.. the 'tree' is much bigger than this really.

Le gerarchie dell'ereditarietà profonda sono un odore di codice, certo. Avere una classe base comune spesso è fastidiosa perché ci sono pochissime cose che si applicano a tutto e si comportano allo stesso modo. Porta spesso a perdite di astrazioni e violazione del Principio di sostituzione di Liskov.

Where Base is a static class.

Questo sembra un po 'strano. Se la classe base è essenzialmente vuota dalla prospettiva di un membro dell'istanza, viene eseguita in una varietà di altri problemi. A quel punto specificare una variabile di quel tipo ti consente di non fare quasi nulla, che è ... controproducente.

Una classe base static consentirà l'utilizzo di tutte le funzioni pubbliche e protette e i membri di tale classe base ovunque attraverso la gerarchia dell'oggetto, senza fare riferimento a un nome di classe specifico (o spazio dei nomi). Ciò significa che avrai solo funzioni e membri globali in tutto il tuo sistema, che "disabilita" alcune delle idee principali sull'orientamento agli oggetti. Otterrai un'architettura molto migliore quando trasferirai questi metodi statici in classi di utilità separate e li raggrupperai in modo tematico. Altrimenti, una tale classe base potrebbe facilmente diventare una "classe di Dio" , che è un noto anti-modello.

IMHO l'intera cosa avrebbe senso in una certa misura solo se tu

• non aggiungere funzioni o membri alla classe di base statica

• richiede un contenitore generico di tipo misto per gli oggetti e non hai alcun supporto per la lingua incorporato per questo

Risposta breve:

Sembra che il design sia difettoso.

Non riesco a immaginare come ogni classe nel dominio della soluzione abbia una "sia una relazione" con una singola classe, eccetto che ereditino tutti da Object, ma questa è un'altra cosa.

Se ci mostri alcuni nomi di classi reali in quell'albero, sono sicuro che sarà ovvio.