Ogni volta che mi veniva richiesto di costruire un progetto, riuscivo sempre a costruirlo, non prima di escogitare un piano o un progetto, ma dopo aver scritto una classe che era necessaria, completando 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 testa in quello che viene chiamato Analisi e progettazione orientate agli oggetti. Riesco più facilmente a comprendere la progettazione procedurale top-down, poiché consiste semplicemente nel suddividere le attività in sotto-attività, cose che hanno la loro controparte nel codice, funzioni. Ma l'analisi e la progettazione orientate agli oggetti non riesco a capire facilmente, perché non capisco come si possa sapere quali classi avranno bisogno e come interagiranno, a meno che non sappiano come le codificheranno.
Per una volta introduciamo il concetto di classi e oggetti nel processo di progettazione, non possiamo più progettare dall'alto verso il basso, perché non stiamo più suddividendo i nostri problemi in quelle cose che possono essere implementate come procedure. Invece, secondo quanto ho letto sull'argomento, dobbiamo determinare quali classi sono necessarie e creare vari artefatti in Unified Modeling Language, che possiamo quindi utilizzare quando implementiamo il software. Ma questo tipo di processo di progettazione non capisco. Perché come si può sapere di quali classi avranno bisogno e come interagiranno, a meno che non abbiano già concepito l'intero sistema?
Questo è quindi 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 questi concetti in qualsiasi linguaggio di programmazione orientata agli oggetti che conosco. Pertanto ho bisogno di qualcuno che mi spieghi quale semplice processo posso usare per progettare sistemi orientati agli oggetti in un modo che abbia senso per me.
