Questa è una domanda piuttosto vaga, ma è qualcosa a cui non ho mai pensato di aver trovato una risposta soddisfacente quando ho letto sulla corretta progettazione.
Generalmente, quando si apprende la programmazione orientata agli oggetti, l'astrazione, il factoring, ecc., il santo graal del design - e il motivo per cui affermano sempre che stai usando le tecniche di sviluppo in questione - è che renderà il tuo programma "facile per cambiare "," manutenibile "," flessibile "o uno qualsiasi dei sinonimi utilizzati per esprimere un concetto dal suono produttivo. Marcando ivars privati, suddividendo il codice in molti piccoli metodi autonomi, mantenendo le interfacce generali, si presume che si possa ottenere la possibilità di modificare il programma con facilità e grazia.
Per modifiche relativamente piccole, questo ha funzionato bene per me. Le modifiche alle strutture di dati interne utilizzate da una classe per aumentare le prestazioni non sono mai state una grande difficoltà e non hanno nemmeno modifiche all'interfaccia utente, indipendente dall'API, come la riprogettazione di un sistema di inserimento di testo o la revisione della grafica per un elemento di gameplay .
Tutti questi cambiamenti sembrano intrinsecamente autosufficienti. Nessuno di essi comporta modifiche al comportamento o alla progettazione del componente del programma che viene modificato, per quanto riguarda il codice esterno interessato. Che tu stia scrivendo proceduralmente o in uno stile OO, con funzioni grandi o piccole, queste sono semplici modifiche da apportare anche se hai solo un design discreto.
Tuttavia, ogni volta che le modifiche diventano grandi e pelose, ovvero le modifiche all'API, nessuno dei miei preziosi "modelli" viene mai in soccorso. Il grande cambiamento rimane grande, il codice interessato rimane influenzato e molte ore di lavoro di generazione di bug si trovano davanti a me.
Quindi, la mia domanda è questa. Quanto è grande il cambiamento che la progettazione corretta pretende di essere in grado di facilitare? C'è qualche ulteriore tecnica di progettazione, a me sconosciuta o che non sono riuscita a implementare, che rende davvero semplice la modifica appiccicosa, o è quella promessa (che ho sentito pronunciare da tanti paradigmi diversi) semplicemente una buona idea, completamente disconnesso dalle verità immutabili dello sviluppo del software? C'è uno "strumento di cambiamento" che posso aggiungere al mio toolbelt?
In particolare, il problema che sto affrontando mi ha portato ai forum è questo: ho lavorato sull'implementazione di un linguaggio di programmazione interpretato (implementato in D, ma non è rilevante), e ho deciso che le mie chiusure ' gli argomenti dovrebbero essere basati su parole chiave, piuttosto che posizionali come sono attualmente. Ciò richiede la modifica di tutto il codice esistente che chiama funzioni anonime, che, fortunatamente, è piuttosto piccolo perché sono all'inizio nello sviluppo della mia lingua (< 2000 linee), ma sarebbe enorme se avessi preso questa decisione in una fase successiva . In una situazione del genere, c'è un modo in cui, con la giusta lungimiranza nel design, avrei potuto rendere questa modifica più facile, o sono certi (la maggior parte) cambiamenti intrinsecamente di vasta portata? Sono curioso di sapere se questo è in qualche modo un fallimento delle mie capacità progettuali - se lo fosse, sarei molto desideroso di migliorarle con il materiale di lettura necessario se c'è un modo per migliorare la gravità del problema.
Per essere chiari, non sono affatto scettico su OOP o su altri pattern comunemente in uso. Per me, tuttavia, le loro virtù sono nella scrittura originale, piuttosto che nel mantenimento, delle basi di codice. L'ereditarietà consente di astrarre bene schemi ripetitivi, il polimorfismo consente di separare il codice in base alla funzione comprensibile (quale classe) piuttosto che all'effetto macchina (il ramo dell'istruzione switch ) e le funzioni piccole e autonome ti permettono di scrivere in un piacevole stile "dal basso verso l'alto". Tuttavia, sono scettico nei confronti delle loro affermazioni di flessibilità.