In questo articolo abbiamo parlato di una "caratteristica" di un buon programmatore, scrivere prima del codice predisposto al cambiamento e alle implementazioni future. Vediamo insieme qualche consiglio utile su come fare.
Premetto che questo metodo è strettamente personale e lo applico sulla maggior parte dei progetti su cui metto mano, spero possa essere d'aiuto a qualcuno.
Due classi simili? scrivi una interfaccia.
La cosa può essere banale ma scrivere e gestire una interfaccia per gestire due cose simili ti permette di risparmiare UNA MONTAGNA di lavoro aggiuntivo, al costo di qualche riga di codice in più alla prima stesura, garantisco.
Vi ricordate durante lo sviluppo del progetto SqlDocGen? più precisamente nella parte IV , tutti gli oggetti (tabelle, viste, trigger e stored procedure) implementavano l'interfaccia Commentable per condividerne le caratteristiche. Se un domani il software dovesse generare un'altro tipo di oggetto, basta implementare questa interfaccia e viene già risparmiata una parte del lavoro.
Naturalmente il "difficile" sta nell'utilizzare bene gli strumenti messi a disposizione dalla programmazione orientata agli oggetti OOP. Anche qui viene incontro un esempio facile facile, non fare mai riferimento esplicito alla classe che implementa una interfaccia, altrimenti in futuro dovrai mettere mano a quella parte di codice.
Ultima cosa prima di concludere: nel caso in cui una interfaccia non sia abbastanza si può sempre scrivere una classe astratta. Tutto questo per rispondere al design pattern Abstract Factory, su cui verrà dedicato un articolo su Programmazione Applicata.
Conclusione
Scrivere codice predisposto al cambiamento permette di risparmiare tempo sia in fase di sviluppo che in fase di post-rilascio del software, risparmio di tempo che, con i tempi che corrono, permette di avere margini più ampi nei lavori (spero). Fatemi sapere le vostre impressioni lasciando un commento oppure tramite la pagina ufficiale Facebook.
Nessun commento:
Posta un commento