Ogni volta che mi veniva richiesto di costruire un progetto, sono sempre riuscito a costruirlo, non progettando un piano o un progetto, ma dopo aver scritto una lezione che era necessaria, che ha arricchito l'intero progetto, costruendo dal basso verso l'alto. Ora so che questo non è il modo corretto di creare software, ma non è facile per me avvolgere la mia mente su ciò che viene chiamato Objected Oriented Analysis and Design. Riesco più facilmente a capire il design procedurale top-down, poiché consiste semplicemente nel suddividere i compiti in sotto-attività, cose che hanno la loro controparte nel codice, nelle funzioni. Ma l'analisi e il design orientato agli oggetti non riesco a capire facilmente, perché non capisco come si possa sapere di quali classi avranno bisogno e in che modo interagiranno, a meno che non sappiano come li codificheranno.
Per una volta che introduciamo il concetto di classi e oggetti nel processo di progettazione, non possiamo più progettare dall'alto in basso, perché non stiamo più distruggendo i nostri problemi in quelle cose che possono essere implementate come procedure. Invece, in base a ciò che ho letto sull'argomento, dobbiamo determinare quali classi sono necessarie e creare vari artefatti in Unified Modeling Language, che possiamo usare quando implementiamo il software. Ma questo tipo di processo di progettazione non lo capisco. Come si fa a sapere di quali classi avranno bisogno e in che modo interagiranno, a meno che non abbiano già concepito l'intero sistema?
Questo è il mio problema. Non capisco come progettare un sistema orientato agli oggetti, anche se capisco i concetti di programmazione orientata agli oggetti, e posso usare quei concetti in qualsiasi linguaggio di programmazione orientata agli oggetti che conosco. Quindi ho bisogno di qualcuno che mi spieghi quale processo semplice posso usare per progettare sistemi orientati agli oggetti in un modo che abbia senso per me.
