CiSharpe ha scritto:
Quindi per rendere un programma "robusto", si agisce sempre sui metodi, in modo da evitare quante più eccezioni possibili.
Diciamo che il termine "robusto" è un po' troppo generico e astratto se riferito a un programma, perché non è chiaro a cosa si fa riferimento: si parla dell'accuratezza con cui si prevengono e risolvono i bug? si parla di come il programma sia affidabile e poco incline a crashare? si parla di sicurezza interna e protezione rispetto ai dati e alle istruzioni?
E' un termine che escluderei sostituendolo con qualcosa di più specifico, giusto per essere chiari sull'aspetto verso il quale si sta ponendo l'attenzione.
Detto questo, le eccezioni non sono da evitare. E' come dire che si dovrebbe evitare una multa: certo, dal punto di vista di un trasgressore sono una scocciatura, ma è una garanzia per gli altri che magari non si trovano il passo carrabile occupato dall'auto di un estraneo. Le eccezioni sono uno strumento che nasce per segnalare una condizione tale per cui il programma non può proseguire: può essere gestita oppure no, e ciò può essere fatto bene oppure male. Se si costruisce una libreria, fare uso delle eccezioni è opportuno. Chi la usa per sviluppare applicazioni può decidere di intercettarle e dare un messaggio significativo all'utente, o creare un programma resiliente tentando di risolvere il problema, o ignorarlo. In ogni caso, sollevare 1, 10, 100 eccezioni non renderà un programma né più né meno robusto di altri (se la gestione predefinita interviene, presenta il messaggio e consente la prosecuzione del programma stesso, senza terminarlo).
Mi pare che si stia buttando nel calderone concetti ed elementi della programmazione che vanno prima approfonditi e su cui è necessario maturare una certa esperienza, poi sarà sicuramente possibile specularci e filosofeggiarci sopra.
CiSharpe ha scritto:
La mia era un domanda puramente didattica, nel senso, è possibile relazionare le classi come si fa con i database?
Anche qui, dipende dal database: non tutti sono esclusivamente SQL e basati sul modello E/R.
Oltre a questo, non è detto che riprodurre un modello E/R precisamente sia proficuo nello sviluppo di una applicazione, tant'è vero che esistono molteplici tool di
ORM per rendere la struttura rigida del database fruibile dal linguaggio di programmazione.
CiSharpe ha scritto:
Esempio, condizione fondamentale: "Non avere un oggetto Carrello se non esiste un oggetto Utente istanziato e l'oggetto Carrello deve essere referenziato solo all'interno dell'oggetto Utente"
La creazione degli oggetti è sempre possibile. E' chiaro che se nel costruttore della classe
Carrello inserisco come parametro l'
Utente di riferimento e lo rendo obbligatorio (sollevo eccezione se
null), sarà necessario per forza avere un utente prima di poter creare il
Carrello.
Detto in altri termini, in questo modo l'associazione con un utente è fondamentale per poter creare il carrello, in quanto la creazione del carrello presuppone di passare come parametro l'utente a cui esso appartiene.
Quindi l'istanza del
Carrello non deve essere referenziato all'interno dell'
Utente, bensì il contrario.
E' bene precisare che qui si sta discutendo di "legami" tra oggetti che vengono instaurate in base all'uso di specifici costrutti (o pattern): non ci sono parole chiave per configurare le classi in modo da sapere con quali altre classi possono entrare in contatto o che relazioni ci saranno poi tra gli oggetti, ma tutto dipende da come il codice viene scritto.
Ad ogni modo, come già dicevo nel messaggio precedente, questo tipo di "forzature" sarei molto restio a implementarle, poiché comporta la creazione di gerarchie complesse dove invece di aver diversi oggetti che si referenziano e che contengono ciascuno le informazioni di competenza, arrivo invece ad avere una "radice" tra l'altro probabilmente errata la quale costituisce un percorso obbligato da fare per accedere e ottenere tutte le restanti informazioni che sono all'interno (ad esempio, nello scenario che proponi, devo disporre dell'oggetto utente per poter accedere a un carrello al suo interno, e non ne vedo lo scopo).
Ciao!